From mattias.tobiasson at oracle.com Tue Apr 1 10:11:44 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Tue, 1 Apr 2014 03:11:44 -0700 (PDT) Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Message-ID: Hi Mandy, I have moved the common code to a new utility class. The shell script tests work as they are, they do not fail. The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 bug: https://bugs.openjdk.java.net/browse/JDK-8030628 Mattias ----- Original Message ----- From: mandy.chung at oracle.com To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net Cc: leonid.mesnik at oracle.com Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Hi Mattias, On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: > Hi, > I have updated the patch to include all failing tests for this bug. > > The tests currently fail because their GC options collide with GC options from the test framework. > The fix will launch the tests in a separate JVM with controlled GC options. > > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 Thanks for updating other failing tests. I think we are not sure when the proper configuration support is in place and this temporary solution to allow the tests to run is reasonable. It'd be better to refactor the common code to launch the test with all GC configurations shared by jdk/test/java/lang/management/MemoryMXBean tests. There are other shell tests that can be removed if the corresponding java tests are modified to use your utility class. It's probably out of the scope of this fix. Do you have cycles to clean them up as well? They probably fail in VM nightlies like the ones you fixed if it overrides with a different GC. LowMemoryTest2.sh MemoryManagementParallelGC.sh MemoryManagementConcMarkSweepGC.sh MemoryManagementSerialGC.sh PendingAllGC.sh Mandy > Mattias > > > ----- Original Message ----- > From: mattias.tobiasson at oracle.com > To: mandy.chung at oracle.com > Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com > Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mandy, > I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. > > I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. > > I did not notice that there are more tests in the same dir. I will change them too. > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com > Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > Have you discussed with Jon Gibbons about the jtreg @requires support? > I thought it was partly motivated by the requirement to specify a test > to run in different collector. > > The reason why these regression tests explicitly specifies different GC > flags was to increase the coverage and ensure to catch regression early > during development cycle. At that time, the VM nightly testing rotates > the test execution with different GC configuration that delayed to catch > a regression that occurs in one collector while the nightly testing is > testing another collector. For integration, I don't recall if different > collectors are tested rather than default. It may be time to revisit > the test execution with different collectors. If the verification of > different collectors is well covered in nightly, perhaps these tests no > longer need one @run per each collector. > > There are other regression tests that specifies the -XX:+UseXXGC flag in > the @run tag. It makes sense to modify them in the same patch (perhaps > at least tests under test/java/lang/management). > > Mandy > > On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >> Hi, >> Could you please review this test fix. >> >> The test fails because it specifies its own GC command line options, for example: >> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >> >> When the framework also specifies GC version, then the test will fail with this log: >> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >> >> The solution is to run the test in a separate JVM with controlled GC options. >> The test will be run multiple times. >> First with the command line specified from the framework, without test specific GC options. >> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >> >> Mattias >> From jaroslav.bachorik at oracle.com Tue Apr 1 10:35:05 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Apr 2014 12:35:05 +0200 Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing In-Reply-To: References: Message-ID: <533A9659.4040905@oracle.com> Hi Mattias, /test/lib/testlibrary/jdk/testlibrary/Utils.java; Line 130 You should move the pattern compilation out of the method body. It makes sense to precompile the pattern and then use the compiled version only. The rest looks fine. Cheers, -JB- On 1.4.2014 12:11, Mattias Tobiasson wrote: > Hi Mandy, > I have moved the common code to a new utility class. > > The shell script tests work as they are, they do not fail. > The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. > Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. > > We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. > > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net > Cc: leonid.mesnik at oracle.com > Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: >> Hi, >> I have updated the patch to include all failing tests for this bug. >> >> The tests currently fail because their GC options collide with GC options from the test framework. >> The fix will launch the tests in a separate JVM with controlled GC options. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > > Thanks for updating other failing tests. I think we are not sure when > the proper configuration support is in place and this temporary solution > to allow the tests to run is reasonable. > > It'd be better to refactor the common code to launch the test with all > GC configurations shared by jdk/test/java/lang/management/MemoryMXBean > tests. > > There are other shell tests that can be removed if the corresponding > java tests are modified to use your utility class. It's probably out > of the scope of this fix. Do you have cycles to clean them up as well? > They probably fail in VM nightlies like the ones you fixed if it > overrides with a different GC. > > LowMemoryTest2.sh > MemoryManagementParallelGC.sh > MemoryManagementConcMarkSweepGC.sh > MemoryManagementSerialGC.sh > PendingAllGC.sh > > Mandy > >> Mattias >> >> >> ----- Original Message ----- >> From: mattias.tobiasson at oracle.com >> To: mandy.chung at oracle.com >> Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com >> Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mandy, >> I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. >> >> I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. >> >> I did not notice that there are more tests in the same dir. I will change them too. >> >> Mattias >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com >> Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mattias, >> >> Have you discussed with Jon Gibbons about the jtreg @requires support? >> I thought it was partly motivated by the requirement to specify a test >> to run in different collector. >> >> The reason why these regression tests explicitly specifies different GC >> flags was to increase the coverage and ensure to catch regression early >> during development cycle. At that time, the VM nightly testing rotates >> the test execution with different GC configuration that delayed to catch >> a regression that occurs in one collector while the nightly testing is >> testing another collector. For integration, I don't recall if different >> collectors are tested rather than default. It may be time to revisit >> the test execution with different collectors. If the verification of >> different collectors is well covered in nightly, perhaps these tests no >> longer need one @run per each collector. >> >> There are other regression tests that specifies the -XX:+UseXXGC flag in >> the @run tag. It makes sense to modify them in the same patch (perhaps >> at least tests under test/java/lang/management). >> >> Mandy >> >> On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >>> Hi, >>> Could you please review this test fix. >>> >>> The test fails because it specifies its own GC command line options, for example: >>> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >>> >>> When the framework also specifies GC version, then the test will fail with this log: >>> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >>> >>> The solution is to run the test in a separate JVM with controlled GC options. >>> The test will be run multiple times. >>> First with the command line specified from the framework, without test specific GC options. >>> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >>> >>> Mattias >>> > From shanliang.jiang at oracle.com Tue Apr 1 13:43:53 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 01 Apr 2014 15:43:53 +0200 Subject: RFR: 8038940 c.s.j.r.i.ClientNotifForwarder$LinearExecutor prone to data races Message-ID: <533AC299.6000209@oracle.com> Hi, When ClientNotifForwarder starts, its first communication with ServerNotifForwarder is to get clientSequenceNumber, then starts LinearExecutor to execute the fetching job. If reconnection happens during this communication, a new thread will be started by the reconnection to do fetching job too, that's why the test got "java.lang.IllegalArgumentException: More than one command " I have verified the class ClientNotifForwarder to make sure no other place would start a new job. It is difficult to have a regression test to reproduce this bug, it is all related to an internal function. I had to add code temporally into the implementation to make the reconnection happen during this first communication, in order to reproduce the bug and to verify the fix. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038940/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8038940 Thanks, Shanliang From daniel.fuchs at oracle.com Tue Apr 1 14:15:19 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 01 Apr 2014 16:15:19 +0200 Subject: jmx-dev RFR: 8038940 c.s.j.r.i.ClientNotifForwarder$LinearExecutor prone to data races In-Reply-To: <533AC299.6000209@oracle.com> References: <533AC299.6000209@oracle.com> Message-ID: <533AC9F7.1040605@oracle.com> Hi Shanliang, Looks good! -- daniel On 4/1/14 3:43 PM, shanliang wrote: > Hi, > > When ClientNotifForwarder starts, its first communication with > ServerNotifForwarder is to get clientSequenceNumber, then starts > LinearExecutor to execute the fetching job. If reconnection happens > during this communication, a new thread will be started by the > reconnection to do fetching job too, that's why the test got > "java.lang.IllegalArgumentException: More than one command " > > I have verified the class ClientNotifForwarder to make sure no other > place would start a new job. > > It is difficult to have a regression test to reproduce this bug, it is > all related to an internal function. I had to add code temporally into > the implementation to make the reconnection happen during this first > communication, in order to reproduce the bug and to verify the fix. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038940/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038940 > > Thanks, > Shanliang From mandy.chung at oracle.com Tue Apr 1 22:23:24 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 01 Apr 2014 15:23:24 -0700 Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing In-Reply-To: References: Message-ID: <533B3C5C.7050201@oracle.com> Hi Mattias, On 4/1/14 3:11 AM, Mattias Tobiasson wrote: > Hi Mandy, > I have moved the common code to a new utility class. Thanks for the refactoring. Looks much better. Nit: RunUtil.java line 64 - you can use diamond operator. No need to generate a new webrev. > > The shell script tests work as they are, they do not fail. > The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. > Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. > We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. Can you file a bug to replace the shell script tests with the new RunUtil class? @requires could be done independent with the shell script test conversion. thanks Mandy > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net > Cc: leonid.mesnik at oracle.com > Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: >> Hi, >> I have updated the patch to include all failing tests for this bug. >> >> The tests currently fail because their GC options collide with GC options from the test framework. >> The fix will launch the tests in a separate JVM with controlled GC options. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > Thanks for updating other failing tests. I think we are not sure when > the proper configuration support is in place and this temporary solution > to allow the tests to run is reasonable. > > It'd be better to refactor the common code to launch the test with all > GC configurations shared by jdk/test/java/lang/management/MemoryMXBean > tests. > > There are other shell tests that can be removed if the corresponding > java tests are modified to use your utility class. It's probably out > of the scope of this fix. Do you have cycles to clean them up as well? > They probably fail in VM nightlies like the ones you fixed if it > overrides with a different GC. > > LowMemoryTest2.sh > MemoryManagementParallelGC.sh > MemoryManagementConcMarkSweepGC.sh > MemoryManagementSerialGC.sh > PendingAllGC.sh > > Mandy > >> Mattias >> >> >> ----- Original Message ----- >> From: mattias.tobiasson at oracle.com >> To: mandy.chung at oracle.com >> Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com >> Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mandy, >> I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. >> >> I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. >> >> I did not notice that there are more tests in the same dir. I will change them too. >> >> Mattias >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com >> Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mattias, >> >> Have you discussed with Jon Gibbons about the jtreg @requires support? >> I thought it was partly motivated by the requirement to specify a test >> to run in different collector. >> >> The reason why these regression tests explicitly specifies different GC >> flags was to increase the coverage and ensure to catch regression early >> during development cycle. At that time, the VM nightly testing rotates >> the test execution with different GC configuration that delayed to catch >> a regression that occurs in one collector while the nightly testing is >> testing another collector. For integration, I don't recall if different >> collectors are tested rather than default. It may be time to revisit >> the test execution with different collectors. If the verification of >> different collectors is well covered in nightly, perhaps these tests no >> longer need one @run per each collector. >> >> There are other regression tests that specifies the -XX:+UseXXGC flag in >> the @run tag. It makes sense to modify them in the same patch (perhaps >> at least tests under test/java/lang/management). >> >> Mandy >> >> On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >>> Hi, >>> Could you please review this test fix. >>> >>> The test fails because it specifies its own GC command line options, for example: >>> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >>> >>> When the framework also specifies GC version, then the test will fail with this log: >>> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >>> >>> The solution is to run the test in a separate JVM with controlled GC options. >>> The test will be run multiple times. >>> First with the command line specified from the framework, without test specific GC options. >>> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >>> >>> Mattias >>> From joe.darcy at oracle.com Wed Apr 2 01:20:35 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Apr 2014 18:20:35 -0700 Subject: JDK 9 RFR of 8039027: Fix serial lint warnings in jconsole and jstat Message-ID: <533B65E3.6090903@oracle.com> Hello, With the serial warnings cleanup of the JDK drawing to completion, please review the patch below which addresses some lingering issues in jconsole and jstat. Thanks, -Joe diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/Tab.java --- a/src/share/classes/sun/tools/jconsole/Tab.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/Tab.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,6 +28,7 @@ import java.awt.*; import javax.swing.*; + at SuppressWarnings("serial") // JDK implementation class public abstract class Tab extends JPanel { private String name; private Worker worker; diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/inspector/XOperations.java --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -39,6 +39,7 @@ import sun.tools.jconsole.JConsole; import sun.tools.jconsole.Messages; + at SuppressWarnings("serial") // JDK implementation class public abstract class XOperations extends JPanel implements ActionListener { public final static String OPERATION_INVOCATION_EVENT = diff -r b6997dd0667e src/share/classes/sun/tools/jconsole/inspector/XTable.java --- a/src/share/classes/sun/tools/jconsole/inspector/XTable.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XTable.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -33,6 +33,7 @@ import javax.swing.table.DefaultTableModel; import javax.swing.table.TableCellRenderer; + at SuppressWarnings("serial") // JDK implementation class public abstract class XTable extends JTable { static final int NAME_COLUMN = 0; static final int VALUE_COLUMN = 1; diff -r b6997dd0667e src/share/classes/sun/tools/jstat/ParserException.java --- a/src/share/classes/sun/tools/jstat/ParserException.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jstat/ParserException.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,6 +31,7 @@ * @author Brian Doherty * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public class ParserException extends Exception { public ParserException() { diff -r b6997dd0667e src/share/classes/sun/tools/jstat/SyntaxException.java --- a/src/share/classes/sun/tools/jstat/SyntaxException.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/tools/jstat/SyntaxException.java Tue Apr 01 18:20:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -36,6 +36,7 @@ * @author Brian Doherty * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public class SyntaxException extends ParserException { private String message; From joe.darcy at oracle.com Wed Apr 2 06:39:39 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 01 Apr 2014 23:39:39 -0700 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp Message-ID: <533BB0AB.8010802@oracle.com> Hello, *fingers crossed* The patch below should be the last change needed to fully clear the JDK 9 jdk repo of serialization warnings. Thanks, -Joe diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -45,7 +45,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class abstract public class Enumerated implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -44,6 +44,7 @@ * The class defines an abstract representation of a host. * */ + at SuppressWarnings("serial") // JDK implementation class abstract class Host extends SimpleNode implements Serializable { public Host(int id) { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -45,6 +45,7 @@ * * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpPdu implements SnmpDefinitions, Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -47,6 +47,7 @@ * * @since 1.5 */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpScopedPduPacket extends SnmpPdu implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -34,7 +34,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpUnsignedInt extends SnmpInt { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -38,7 +38,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpValue implements Cloneable, Serializable, SnmpDataTypeEnums { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -59,6 +59,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMib extends SnmpMibAgent implements Serializable { /** diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -59,7 +59,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibAgent implements SnmpMibAgentMBean, MBeanRegistration, Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -41,7 +41,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibEntry extends SnmpMibNode implements Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -49,7 +49,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibGroup extends SnmpMibOid implements Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -53,7 +53,7 @@ *

This API is a Sun Microsystems internal API and is subject * to change without notice.

*/ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibNode implements Serializable { // --------------------------------------------------------------------- diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -84,7 +84,7 @@ * @see com.sun.jmx.snmp.agent.SnmpTableSupport * */ - + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpMibTable extends SnmpMibNode implements NotificationBroadcaster, Serializable { diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -80,6 +80,7 @@ * @see com.sun.jmx.snmp.agent.SnmpMibTable * */ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpTableSupport implements SnmpTableEntryFactory, // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 // SnmpTableCallbackHandler { diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpListTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -43,6 +43,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization whwn needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpListTableCache extends SnmpTableCache { diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -49,6 +49,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization whwn needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpNamedListTableCache extends SnmpListTableCache { /** diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpTableCache.java --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 09:12:51 2014 -0700 +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 23:36:42 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -45,6 +45,7 @@ *

NOTE: This class is not synchronized, subclasses must implement * the appropriate synchronization when needed.

**/ + at SuppressWarnings("serial") // JDK implementation class public abstract class SnmpTableCache implements Serializable { /** From Alan.Bateman at oracle.com Wed Apr 2 07:31:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:31:06 +0100 Subject: JDK 9 RFR of 8039027: Fix serial lint warnings in jconsole and jstat In-Reply-To: <533B65E3.6090903@oracle.com> References: <533B65E3.6090903@oracle.com> Message-ID: <533BBCBA.9010301@oracle.com> On 02/04/2014 02:20, Joe Darcy wrote: > Hello, > > With the serial warnings cleanup of the JDK drawing to completion, > please review the patch below which addresses some lingering issues in > jconsole and jstat. This looks okay too. -Alan From Alan.Bateman at oracle.com Wed Apr 2 07:32:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Apr 2014 08:32:16 +0100 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <533BBD00.9090103@oracle.com> On 02/04/2014 07:39, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to > fully clear the JDK 9 jdk repo of serialization warnings. > > Thanks, > > -Joe This looks okay too. -Alan From shanliang.jiang at oracle.com Wed Apr 2 08:01:58 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 02 Apr 2014 10:01:58 +0200 Subject: RFR: 6815126 intermittent SimulResumerTest.java failure In-Reply-To: <53395A48.6090308@oracle.com> References: <53343A96.4040201@oracle.com> <53344887.1000004@oracle.com> <5336A3A8.5000501@oracle.com> <533934D3.9020102@oracle.com> <53394CBE.7000002@oracle.com> <53395A48.6090308@oracle.com> Message-ID: <533BC3F6.50007@oracle.com> Hope to get reviewed and to push this fix: 1) this is a fix for a bug labeled with "svc-nightly" 2) The current test must be useful. Yes the test could not be 100% sure to test the bug JDK-6751643, but with its 2*10000 resume repeatings it would have big chance to hit the bug conditions, the failure the patch to fix happened exactly in the condition the bug JDK-6751643 could happen. 3) there is possibly someway to realize the synchronization logic between the thread invoking the operations and the thread resuming, I could see to add code into the method "resume" to do waiting for this test, but I could not see an easy and practical way to do that. 4) we can create a new bug to fix this synchronization issue if necessary. Thanks, Shanliang shanliang wrote: > Jaroslav Bachorik wrote: >> Thanks Shanliang, it is clear now. >> >> The patch will get rid off the IOOBE but I have my doubts about what >> the test actually tests. It is supposed to make sure that certain >> operations will not throw NPE when the debugged thread is resumed >> (from a concurrent debugger thread) before the operation has managed >> to finish. However, there seems to be no synchronization logic >> between the thread invoking the operations and the thread resuming >> the paused debugged thread, relying only on hitting this condition by >> chance. >> >> This test seems to be a good candidate for a thorough revision/rewrite. > Not sure how to make the checking happen during a "resuming" window, > the test creates 2 threads and each repeats "resume"10000 times, and > one another thread repeats checking with 100ms sleeping time, just > hoping some checking would fail into a resuming window. > > Shanliang >> >> -JB- >> >> On 31.3.2014 11:26, shanliang wrote: >>> Erik Gahlin wrote: >>>> I also like to understand better. >>> Possibly my previous reply was not clear enough or I missed something >>> there. >>> >>> The test was to test JDK-6751643 as I cited in the last mail, here is >>> the info from JDK-6751643 to which this test was developed: >>> ------ >>> This bug can only occur if a debugger has multiple threads and calls >>> any >>> of the following methods in one thread while simultaneously resuming >>> the >>> same debuggee thread in a different debugger thread. Debuggers >>> shouldn't >>> do this because it is a race condition and the result returned by these >>> methods will vary depending upon just where in the processing of these >>> methods the resume takes effect. EG, the frameCount() method could >>> return 6 in a case where the debuggee has already been resumed and >>> there >>> are no frames. >>> ------ >>> >>> To reproduce the bug, test did mainly 2 things by different threads: >>> 1) received vm events and resumed vm, this was done by thread >>> "Thread-1" >>> in the class TestScaffold which registered a listener and called the >>> following method: >>> /** >>> * Events handled directly by scaffold always resume (well, almost >>> always) >>> */ >>> public void eventSetComplete(EventSet set) { >>> // The listener in connect(..) resumes after receiving our >>> // special VMDeathEvent. We can't also do the resume >>> // here or we will probably get a VMDisconnectedException >>> if (!containsOurVMDeathRequest(set)) { >>> traceln("TS: set.resume() called"); >>> set.resume(); >>> } >>> } >>> >>> 2) called the method "check" in the class SimulResumerTarg, to see >>> whether a NullPointerException was thrown, the thread name was "test >>> resumer" (better to named as "checking thread"?) >>> >>> So one thread was doing resume, another thread was doing check at same. >>> I added the code to see the different values of frames.size() at >>> line 185: >>> for (i=0; i<10:i++) { >>> System.out.println("---frames.size(): "+frames.size()); >>> Thhread.sleep(200); >>> } >>> >>> if printing out frames, sometime we could see one more frame: >>> ------------------ java.lang.Thread.yield()+-1 in thread >>> instance of >>> SimulResumerTarg(name='Thread 2', id=109) >>> >>> >>> Shanliang >>>> >>>> I looked at this failure before and I couldn't see what was wrong, not >>>> in the test or product. >>>> >>>> Erik >>>> >>>> Jaroslav Bachorik skrev 3/27/14 4:49 PM: >>>>> On 27.3.2014 15:49, shanliang wrote: >>>>>> Hi, >>>>>> >>>>>> The call >>>>>> thr.frames(0, frames.size() - 1); >>>>>> suffers a synchronization issue, the size may be changed after >>>>>> frames.size() returns. >>>>> >>>>> Any idea why there is a synchronization issue? The code seems to be >>>>> intended to run only when a breakpoint is hit and the target thread >>>>> is suspended. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-6815126/00/ >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6815126 >>>>>> >>>>>> Shanliang >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Apr 2 08:09:32 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Apr 2014 10:09:32 +0200 Subject: RFR: 6815126 intermittent SimulResumerTest.java failure In-Reply-To: <533BC3F6.50007@oracle.com> References: <53343A96.4040201@oracle.com> <53344887.1000004@oracle.com> <5336A3A8.5000501@oracle.com> <533934D3.9020102@oracle.com> <53394CBE.7000002@oracle.com> <53395A48.6090308@oracle.com> <533BC3F6.50007@oracle.com> Message-ID: <533BC5BC.3030305@oracle.com> Hi Shanliang, I'm fine with the proposed fix, although not a reviewer. On 2.4.2014 10:01, shanliang wrote: > Hope to get reviewed and to push this fix: > > 1) this is a fix for a bug labeled with "svc-nightly" > > 2) The current test must be useful. Yes the test could not be 100% sure > to test the bug JDK-6751643, but with its 2*10000 resume repeatings it > would have big chance to hit the bug conditions, the failure the patch > to fix happened exactly in the condition the bug JDK-6751643 could happen. > > 3) there is possibly someway to realize the synchronization logic > between the thread invoking the operations and the thread resuming, I > could see to add code into the method "resume" to do waiting for this > test, but I could not see an easy and practical way to do that. Just a blind shot - using eg. phaser or cyclic barrier to orchestrate stepping through the code in both threads could help to increase the chances of hitting the problematic situation (but not making it certain, though) > > 4) we can create a new bug to fix this synchronization issue if necessary. Sounds like a very good idea. Thanks, -JB- > > Thanks, > Shanliang > > shanliang wrote: >> Jaroslav Bachorik wrote: >>> Thanks Shanliang, it is clear now. >>> >>> The patch will get rid off the IOOBE but I have my doubts about what >>> the test actually tests. It is supposed to make sure that certain >>> operations will not throw NPE when the debugged thread is resumed >>> (from a concurrent debugger thread) before the operation has managed >>> to finish. However, there seems to be no synchronization logic >>> between the thread invoking the operations and the thread resuming >>> the paused debugged thread, relying only on hitting this condition by >>> chance. >>> >>> This test seems to be a good candidate for a thorough revision/rewrite. >> Not sure how to make the checking happen during a "resuming" window, >> the test creates 2 threads and each repeats "resume"10000 times, and >> one another thread repeats checking with 100ms sleeping time, just >> hoping some checking would fail into a resuming window. >> >> Shanliang >>> >>> -JB- >>> >>> On 31.3.2014 11:26, shanliang wrote: >>>> Erik Gahlin wrote: >>>>> I also like to understand better. >>>> Possibly my previous reply was not clear enough or I missed something >>>> there. >>>> >>>> The test was to test JDK-6751643 as I cited in the last mail, here is >>>> the info from JDK-6751643 to which this test was developed: >>>> ------ >>>> This bug can only occur if a debugger has multiple threads and calls >>>> any >>>> of the following methods in one thread while simultaneously resuming >>>> the >>>> same debuggee thread in a different debugger thread. Debuggers >>>> shouldn't >>>> do this because it is a race condition and the result returned by these >>>> methods will vary depending upon just where in the processing of these >>>> methods the resume takes effect. EG, the frameCount() method could >>>> return 6 in a case where the debuggee has already been resumed and >>>> there >>>> are no frames. >>>> ------ >>>> >>>> To reproduce the bug, test did mainly 2 things by different threads: >>>> 1) received vm events and resumed vm, this was done by thread >>>> "Thread-1" >>>> in the class TestScaffold which registered a listener and called the >>>> following method: >>>> /** >>>> * Events handled directly by scaffold always resume (well, almost >>>> always) >>>> */ >>>> public void eventSetComplete(EventSet set) { >>>> // The listener in connect(..) resumes after receiving our >>>> // special VMDeathEvent. We can't also do the resume >>>> // here or we will probably get a VMDisconnectedException >>>> if (!containsOurVMDeathRequest(set)) { >>>> traceln("TS: set.resume() called"); >>>> set.resume(); >>>> } >>>> } >>>> >>>> 2) called the method "check" in the class SimulResumerTarg, to see >>>> whether a NullPointerException was thrown, the thread name was "test >>>> resumer" (better to named as "checking thread"?) >>>> >>>> So one thread was doing resume, another thread was doing check at same. >>>> I added the code to see the different values of frames.size() at >>>> line 185: >>>> for (i=0; i<10:i++) { >>>> System.out.println("---frames.size(): "+frames.size()); >>>> Thhread.sleep(200); >>>> } >>>> >>>> if printing out frames, sometime we could see one more frame: >>>> ------------------ java.lang.Thread.yield()+-1 in thread >>>> instance of >>>> SimulResumerTarg(name='Thread 2', id=109) >>>> >>>> >>>> Shanliang >>>>> >>>>> I looked at this failure before and I couldn't see what was wrong, not >>>>> in the test or product. >>>>> >>>>> Erik >>>>> >>>>> Jaroslav Bachorik skrev 3/27/14 4:49 PM: >>>>>> On 27.3.2014 15:49, shanliang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The call >>>>>>> thr.frames(0, frames.size() - 1); >>>>>>> suffers a synchronization issue, the size may be changed after >>>>>>> frames.size() returns. >>>>>> >>>>>> Any idea why there is a synchronization issue? The code seems to be >>>>>> intended to run only when a breakpoint is hit and the target thread >>>>>> is suspended. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-6815126/00/ >>>>>>> >>>>>>> bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6815126 >>>>>>> >>>>>>> Shanliang >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Apr 2 09:04:49 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 02 Apr 2014 11:04:49 +0200 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <533BD2B1.8060106@oracle.com> On 4/2/14 8:39 AM, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to > fully clear the JDK 9 jdk repo of serialization warnings. Looks good Joe! best regards, -- daniel > > Thanks, > > -Joe > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java > --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,7 +45,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > abstract public class Enumerated implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -44,6 +44,7 @@ > * The class defines an abstract representation of a host. > * > */ > + at SuppressWarnings("serial") // JDK implementation class > abstract class Host extends SimpleNode implements Serializable { > > public Host(int id) { > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,6 +45,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpPdu implements SnmpDefinitions, Serializable { > > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -47,6 +47,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpScopedPduPacket extends SnmpPdu > implements Serializable { > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -34,7 +34,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpUnsignedInt extends SnmpInt { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 > 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 > 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,7 +38,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpValue implements Cloneable, Serializable, > SnmpDataTypeEnums { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,6 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMib extends SnmpMibAgent implements > Serializable { > > /** > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,7 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibAgent > implements SnmpMibAgentMBean, MBeanRegistration, Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -41,7 +41,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibEntry extends SnmpMibNode > implements Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -49,7 +49,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibGroup extends SnmpMibOid > implements Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -53,7 +53,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibNode implements Serializable { > > // > --------------------------------------------------------------------- > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr > 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr > 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -84,7 +84,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpTableSupport > * > */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibTable extends SnmpMibNode > implements NotificationBroadcaster, Serializable { > > diff -r b6997dd0667e > src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -80,6 +80,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpMibTable > * > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableSupport implements SnmpTableEntryFactory, > // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 > // SnmpTableCallbackHandler { > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -43,6 +43,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpListTableCache extends SnmpTableCache { > > > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java > --- > a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue > Apr 01 09:12:51 2014 -0700 > +++ > b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -49,6 +49,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpNamedListTableCache extends > SnmpListTableCache { > > /** > diff -r b6997dd0667e > src/share/classes/sun/management/snmp/util/SnmpTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue > Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue > Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,6 +45,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization when needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableCache implements Serializable { > > /** > From lance.andersen at oracle.com Wed Apr 2 10:49:15 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Wed, 2 Apr 2014 06:49:15 -0400 Subject: JDK 9 RFR of JDK-8039038: Fix serial lint warnings in com.sun.jmx.snmp In-Reply-To: <533BB0AB.8010802@oracle.com> References: <533BB0AB.8010802@oracle.com> Message-ID: <47902F98-E909-42F0-A2C6-F80F6F561340@oracle.com> +1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On Apr 2, 2014, at 2:39 AM, Joe Darcy wrote: > Hello, > > *fingers crossed* The patch below should be the last change needed to fully clear the JDK 9 jdk repo of serialization warnings. > > Thanks, > > -Joe > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/Enumerated.java > --- a/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/Enumerated.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,7 +45,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > abstract public class Enumerated implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/Host.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -44,6 +44,7 @@ > * The class defines an abstract representation of a host. > * > */ > + at SuppressWarnings("serial") // JDK implementation class > abstract class Host extends SimpleNode implements Serializable { > > public Host(int id) { > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpPdu.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpPdu.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,6 +45,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpPdu implements SnmpDefinitions, Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpScopedPduPacket.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2003, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -47,6 +47,7 @@ > * > * @since 1.5 > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpScopedPduPacket extends SnmpPdu > implements Serializable { > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpUnsignedInt.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -34,7 +34,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpUnsignedInt extends SnmpInt { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/SnmpValue.java > --- a/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/SnmpValue.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,7 +38,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpValue implements Cloneable, Serializable, SnmpDataTypeEnums { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,6 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMib extends SnmpMibAgent implements Serializable { > > /** > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,7 +59,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibAgent > implements SnmpMibAgentMBean, MBeanRegistration, Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -41,7 +41,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibEntry extends SnmpMibNode > implements Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -49,7 +49,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibGroup extends SnmpMibOid > implements Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -53,7 +53,7 @@ > *

This API is a Sun Microsystems internal API and is subject > * to change without notice.

> */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibNode implements Serializable { > > // --------------------------------------------------------------------- > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -84,7 +84,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpTableSupport > * > */ > - > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpMibTable extends SnmpMibNode > implements NotificationBroadcaster, Serializable { > > diff -r b6997dd0667e src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java > --- a/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -80,6 +80,7 @@ > * @see com.sun.jmx.snmp.agent.SnmpMibTable > * > */ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableSupport implements SnmpTableEntryFactory, > // NPCTE fix for bugId 4499265, esc 0, MR 04 sept 2001 > // SnmpTableCallbackHandler { > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpListTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -43,6 +43,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpListTableCache extends SnmpTableCache { > > > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -49,6 +49,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization whwn needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpNamedListTableCache extends SnmpListTableCache { > > /** > diff -r b6997dd0667e src/share/classes/sun/management/snmp/util/SnmpTableCache.java > --- a/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 09:12:51 2014 -0700 > +++ b/src/share/classes/sun/management/snmp/util/SnmpTableCache.java Tue Apr 01 23:36:42 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -45,6 +45,7 @@ > *

NOTE: This class is not synchronized, subclasses must implement > * the appropriate synchronization when needed.

> **/ > + at SuppressWarnings("serial") // JDK implementation class > public abstract class SnmpTableCache implements Serializable { > > /** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Apr 2 11:26:03 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Apr 2014 13:26:03 +0200 Subject: RFR: 8038963 com/sun/jdi tests fail because cygwin's ps sometimes misses processes Message-ID: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> We have had many intermittent failures in the com/sun/jdi tests recently. After much debugging it turns out that the cygwin version of ps sometimes misses some processes. Since the output of ps is used to determine if the tests should exit, this causes some problems? I suspect a recent update to cygwin, but haven?t been able to confirm that. This change stops using ps on cygwin and instead uses the builtin tasklist program on windows. I have also removed some old supporting code for Windows 98 (!). Tested by running the jdi tests over and over locally many times and also in jprt. webrev: http://cr.openjdk.java.net/~sla/8038963/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8038963 Thanks, /Staffan From jaroslav.bachorik at oracle.com Wed Apr 2 11:38:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Apr 2014 13:38:34 +0200 Subject: RFR: 8038963 com/sun/jdi tests fail because cygwin's ps sometimes misses processes In-Reply-To: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> References: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> Message-ID: <533BF6BA.406@oracle.com> Looks good! -JB- On 2.4.2014 13:26, Staffan Larsen wrote: > We have had many intermittent failures in the com/sun/jdi tests recently. After much debugging it turns out that the cygwin version of ps sometimes misses some processes. Since the output of ps is used to determine if the tests should exit, this causes some problems? I suspect a recent update to cygwin, but haven?t been able to confirm that. > > This change stops using ps on cygwin and instead uses the builtin tasklist program on windows. > > I have also removed some old supporting code for Windows 98 (!). > > Tested by running the jdi tests over and over locally many times and also in jprt. > > webrev: http://cr.openjdk.java.net/~sla/8038963/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038963 > > Thanks, > /Staffan > From staffan.larsen at oracle.com Thu Apr 3 09:31:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 11:31:07 +0200 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <533514F4.8050906@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> <533514F4.8050906@oracle.com> Message-ID: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com> Thanks Serguei, I don?t think it is necessary to initialize ?end? since strtol will always set it. I still need an official Reviewer for this change. Thanks, /Staffan On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote: > On 3/27/14 12:55 AM, Staffan Larsen wrote: >> Here is an updated webrev which incorporates Dmitry?s feedback: >> >> http://cr.openjdk.java.net/~sla/8038296/webrev.01/ > > > It looks good. > The only suggestion is to initialize the 'end': > char* end; > > Not sure what value is better to use for initialization. > Probably, end = probe would work Ok. > > Thanks, > Serguei >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: >> >>> Staffan, >>> >>>> Yes, that will find problems when trying to convert something like >>>> ?bla?. It will not capture the case where the input string is a too >>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>> both cases it looks like we need something like: >>>> errno = 0; >>>> char* end; >>>> int probe_typess = (int) strtol(probe, &end, 10); >>>> if (end == probe || errno) { >>>> return JNI_ERR; >>>> } >>> As probe_typess is positive and you are converting long to int >>> It's be better to check value boundaries explicitly: >>> >>> char* end; >>> long ptl = strtol(probe, &end, 10); >>> if (end == probe || ptl < 0 || ptl > MAX_INT) { >>> return JNI_ERR; >>> } >>> >>> int probe_typess = (int) ptl; >>> >>> >>> -Dmitry >>> >>> >>> On 2014-03-25 17:35, Staffan Larsen wrote: >>>> On 25 mar 2014, at 13:46, Dmitry Samersoff >>>> wrote: >>>> >>>>> Staffan, >>>>> >>>>> strtol() sets errno in two cases - >>>>> >>>>> ERANGE if supplied value is less then LONG_MIN or greater than >>>>> LONG_MAX EINVAL if supplied base is not supported. >>>>> >>>>> if you pass probe == 'bla', strtol just return 0 and errno will not >>>>> be set. So I'm not sure that check for errno has any value here. >>>>> >>>>> One of possible way to check that supplied value is convertible to >>>>> long is >>>>> >>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>>>> probe) { // we can't convert supplied value return JNI_ERR; } >>>> Yes, that will find problems when trying to convert something like >>>> ?bla?. It will not capture the case where the input string is a too >>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>> both cases it looks like we need something like: >>>> >>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >>>> 10); if (end == probe || errno) { return JNI_ERR; } >>>> >>>> >>>> /Staffan >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>>>> see if any errors occurred. The problem is that atoi() does not >>>>>> set errno, so some old value of errno is checked which sometimes >>>>>> causes the function to fail. >>>>>> >>>>>> The fix is to replace atoi() with strtol() which does set errno. >>>>>> But errno is only set if an error occurred and not set to 0 in >>>>>> case of success. Thus, I set errno to 0 before calling strtol() >>>>>> and check the value afterwards. >>>>>> >>>>>> Verified with a JPRT run. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>>>> >>>>>> Thanks, /Staffan >>>>>> >>>>> >>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>> Russia * I would love to change the world, but they won't give me >>>>> the sources. >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > From staffan.larsen at oracle.com Thu Apr 3 11:03:25 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 13:03:25 +0200 Subject: RFR: 6815126 intermittent SimulResumerTest.java failure In-Reply-To: <533BC5BC.3030305@oracle.com> References: <53343A96.4040201@oracle.com> <53344887.1000004@oracle.com> <5336A3A8.5000501@oracle.com> <533934D3.9020102@oracle.com> <53394CBE.7000002@oracle.com> <53395A48.6090308@oracle.com> <533BC3F6.50007@oracle.com> <533BC5BC.3030305@oracle.com> Message-ID: Looks ok. Thanks, /Staffan On 2 apr 2014, at 10:09, Jaroslav Bachorik wrote: > Hi Shanliang, > > I'm fine with the proposed fix, although not a reviewer. > > On 2.4.2014 10:01, shanliang wrote: >> Hope to get reviewed and to push this fix: >> >> 1) this is a fix for a bug labeled with "svc-nightly" >> >> 2) The current test must be useful. Yes the test could not be 100% sure >> to test the bug JDK-6751643, but with its 2*10000 resume repeatings it >> would have big chance to hit the bug conditions, the failure the patch >> to fix happened exactly in the condition the bug JDK-6751643 could happen. >> >> 3) there is possibly someway to realize the synchronization logic >> between the thread invoking the operations and the thread resuming, I >> could see to add code into the method "resume" to do waiting for this >> test, but I could not see an easy and practical way to do that. > > Just a blind shot - using eg. phaser or cyclic barrier to orchestrate stepping through the code in both threads could help to increase the chances of hitting the problematic situation (but not making it certain, though) > > >> >> 4) we can create a new bug to fix this synchronization issue if necessary. > > Sounds like a very good idea. > > Thanks, > > -JB- > > >> >> Thanks, >> Shanliang >> >> shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> Thanks Shanliang, it is clear now. >>>> >>>> The patch will get rid off the IOOBE but I have my doubts about what >>>> the test actually tests. It is supposed to make sure that certain >>>> operations will not throw NPE when the debugged thread is resumed >>>> (from a concurrent debugger thread) before the operation has managed >>>> to finish. However, there seems to be no synchronization logic >>>> between the thread invoking the operations and the thread resuming >>>> the paused debugged thread, relying only on hitting this condition by >>>> chance. >>>> >>>> This test seems to be a good candidate for a thorough revision/rewrite. >>> Not sure how to make the checking happen during a "resuming" window, >>> the test creates 2 threads and each repeats "resume"10000 times, and >>> one another thread repeats checking with 100ms sleeping time, just >>> hoping some checking would fail into a resuming window. >>> >>> Shanliang >>>> >>>> -JB- >>>> >>>> On 31.3.2014 11:26, shanliang wrote: >>>>> Erik Gahlin wrote: >>>>>> I also like to understand better. >>>>> Possibly my previous reply was not clear enough or I missed something >>>>> there. >>>>> >>>>> The test was to test JDK-6751643 as I cited in the last mail, here is >>>>> the info from JDK-6751643 to which this test was developed: >>>>> ------ >>>>> This bug can only occur if a debugger has multiple threads and calls >>>>> any >>>>> of the following methods in one thread while simultaneously resuming >>>>> the >>>>> same debuggee thread in a different debugger thread. Debuggers >>>>> shouldn't >>>>> do this because it is a race condition and the result returned by these >>>>> methods will vary depending upon just where in the processing of these >>>>> methods the resume takes effect. EG, the frameCount() method could >>>>> return 6 in a case where the debuggee has already been resumed and >>>>> there >>>>> are no frames. >>>>> ------ >>>>> >>>>> To reproduce the bug, test did mainly 2 things by different threads: >>>>> 1) received vm events and resumed vm, this was done by thread >>>>> "Thread-1" >>>>> in the class TestScaffold which registered a listener and called the >>>>> following method: >>>>> /** >>>>> * Events handled directly by scaffold always resume (well, almost >>>>> always) >>>>> */ >>>>> public void eventSetComplete(EventSet set) { >>>>> // The listener in connect(..) resumes after receiving our >>>>> // special VMDeathEvent. We can't also do the resume >>>>> // here or we will probably get a VMDisconnectedException >>>>> if (!containsOurVMDeathRequest(set)) { >>>>> traceln("TS: set.resume() called"); >>>>> set.resume(); >>>>> } >>>>> } >>>>> >>>>> 2) called the method "check" in the class SimulResumerTarg, to see >>>>> whether a NullPointerException was thrown, the thread name was "test >>>>> resumer" (better to named as "checking thread"?) >>>>> >>>>> So one thread was doing resume, another thread was doing check at same. >>>>> I added the code to see the different values of frames.size() at >>>>> line 185: >>>>> for (i=0; i<10:i++) { >>>>> System.out.println("---frames.size(): "+frames.size()); >>>>> Thhread.sleep(200); >>>>> } >>>>> >>>>> if printing out frames, sometime we could see one more frame: >>>>> ------------------ java.lang.Thread.yield()+-1 in thread >>>>> instance of >>>>> SimulResumerTarg(name='Thread 2', id=109) >>>>> >>>>> >>>>> Shanliang >>>>>> >>>>>> I looked at this failure before and I couldn't see what was wrong, not >>>>>> in the test or product. >>>>>> >>>>>> Erik >>>>>> >>>>>> Jaroslav Bachorik skrev 3/27/14 4:49 PM: >>>>>>> On 27.3.2014 15:49, shanliang wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The call >>>>>>>> thr.frames(0, frames.size() - 1); >>>>>>>> suffers a synchronization issue, the size may be changed after >>>>>>>> frames.size() returns. >>>>>>> >>>>>>> Any idea why there is a synchronization issue? The code seems to be >>>>>>> intended to run only when a breakpoint is hit and the target thread >>>>>>> is suspended. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-6815126/00/ >>>>>>>> >>>>>>>> bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6815126 >>>>>>>> >>>>>>>> Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Apr 3 11:27:30 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Apr 2014 13:27:30 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" Message-ID: <533D45A2.4040300@oracle.com> Please, review the following fix in "jinfo" launcher. Issue : https://bugs.openjdk.java.net/browse/JDK-8039080 Webrev: http://cr.openjdk.java.net/~jbachorik/8039080/webrev.00 When switching "jinfo" to utilize diagnostic commands when possible a combination of launcher arguments was omitted causing "jinfo" fail to execute the default action (-flags & -sysproperties) against a remote SA debug server. The patch fixes this omission. Additionally it contains a refactoring to make the launcher argument parsing testable via a unit test (testng). Also, a new test is provided covering the possible argument combinations. Thanks, -JB- From mattias.tobiasson at oracle.com Thu Apr 3 11:58:11 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Thu, 3 Apr 2014 04:58:11 -0700 (PDT) Subject: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Message-ID: Hi, This test sometimes fails with OutOfMemory. It fails rarely, I have not been able to reproduce it. The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount() > 0. UsageThresholdCount is only updated during a GC. My guess is that the test loads classes too fast so we run out of memory before the flag is set. This fix will force a GC when used memory is above the threshold. That should update the UsageThresholdCount immediately. I have also added more logging if the test fails again. changes: 1. Force a GC if memory usage is above threshold. 2. Split the big check pools loop into sub functions. 3. "pools" list only contains the relevant pools, instead of keeping all pools and filter them each loop. webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00 bug: https://bugs.openjdk.java.net/browse/JDK-8038822 Mattias From dmitry.samersoff at oracle.com Thu Apr 3 12:08:37 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Apr 2014 16:08:37 +0400 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <533D45A2.4040300@oracle.com> References: <533D45A2.4040300@oracle.com> Message-ID: <533D4F45.4010701@oracle.com> Jaroslav, Command line processing is still not clean, e.g. you check for -help in three different places. If you go to refactor this code rather than provide a minimal fix, it might be better to create a separate inner class that do all command line processing and provide couple of flags like should_sa(), should_help(), should_attach() etc. -Dmitry On 2014-04-03 15:27, Jaroslav Bachorik wrote: > Please, review the following fix in "jinfo" launcher. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8039080 > Webrev: http://cr.openjdk.java.net/~jbachorik/8039080/webrev.00 > > When switching "jinfo" to utilize diagnostic commands when possible a > combination of launcher arguments was omitted causing "jinfo" fail to > execute the default action (-flags & -sysproperties) against a remote SA > debug server. > > The patch fixes this omission. Additionally it contains a refactoring to > make the launcher argument parsing testable via a unit test (testng). > Also, a new test is provided covering the possible argument combinations. > > Thanks, > > -JB- -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Apr 3 12:20:05 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Apr 2014 14:20:05 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <533D4F45.4010701@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> Message-ID: <533D51F5.8090008@oracle.com> On 3.4.2014 14:08, Dmitry Samersoff wrote: > Jaroslav, > > Command line processing is still not clean, e.g. you check for -help in > three different places. > > If you go to refactor this code rather than provide a minimal fix, > it might be better to create a separate inner class that do all command > line processing and provide couple of flags like should_sa(), > should_help(), should_attach() etc. Yes, I know :( My first approach was exactly like that. But I was rewriting the command line parser from scratch for at least the 3rd time for "tools" alone :( And the change was going to be rather big - more of a complete rewrite than a fix. May be this is a time to replace all various incarnations of command line processing with a unified command line parsing API? But this would obviously go beyond the simple fix of one missed argument combination. -JB- > > -Dmitry > > > > On 2014-04-03 15:27, Jaroslav Bachorik wrote: >> Please, review the following fix in "jinfo" launcher. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8039080 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8039080/webrev.00 >> >> When switching "jinfo" to utilize diagnostic commands when possible a >> combination of launcher arguments was omitted causing "jinfo" fail to >> execute the default action (-flags & -sysproperties) against a remote SA >> debug server. >> >> The patch fixes this omission. Additionally it contains a refactoring to >> make the launcher argument parsing testable via a unit test (testng). >> Also, a new test is provided covering the possible argument combinations. >> >> Thanks, >> >> -JB- > > From staffan.larsen at oracle.com Thu Apr 3 12:33:22 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 14:33:22 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <533D51F5.8090008@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> Message-ID: <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> On 3 apr 2014, at 14:20, Jaroslav Bachorik wrote: > On 3.4.2014 14:08, Dmitry Samersoff wrote: >> Jaroslav, >> >> Command line processing is still not clean, e.g. you check for -help in >> three different places. >> >> If you go to refactor this code rather than provide a minimal fix, >> it might be better to create a separate inner class that do all command >> line processing and provide couple of flags like should_sa(), >> should_help(), should_attach() etc. > > Yes, I know :( > > My first approach was exactly like that. But I was rewriting the command line parser from scratch for at least the 3rd time for "tools" alone :( And the change was going to be rather big - more of a complete rewrite than a fix. I just re-wrote that command line parser. Obviously with mixed results? :( I think the real problem here is that this command line is not specified in a way that is easily parseable, and we don?t want to change how it works. Command line parsing is one of the really hard areas in computer science. You have added two methods that do not look like they are being called: useSA() and getArgs(). Otherwise the changes look good. If you haven?t already, make sure sun/tools/jinfo/Basic.sh passes on all platforms and add cases to it if that is appropriate. (Note that it currently fails on solaris JDK-8038296). Thanks, /Staffan From jaroslav.bachorik at oracle.com Thu Apr 3 12:47:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Apr 2014 14:47:40 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> Message-ID: <533D586C.6090901@oracle.com> On 3.4.2014 14:33, Staffan Larsen wrote: > > On 3 apr 2014, at 14:20, Jaroslav Bachorik wrote: > >> On 3.4.2014 14:08, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> Command line processing is still not clean, e.g. you check for -help in >>> three different places. >>> >>> If you go to refactor this code rather than provide a minimal fix, >>> it might be better to create a separate inner class that do all command >>> line processing and provide couple of flags like should_sa(), >>> should_help(), should_attach() etc. >> >> Yes, I know :( >> >> My first approach was exactly like that. But I was rewriting the command line parser from scratch for at least the 3rd time for "tools" alone :( And the change was going to be rather big - more of a complete rewrite than a fix. > > I just re-wrote that command line parser. Obviously with mixed results? :( I think the real problem here is that this command line is not specified in a way that is easily parseable, and we don?t want to change how it works. > > Command line parsing is one of the really hard areas in computer science. There are some rather flexible frameworks allowing nice command line parsing in java. But they are all 3rd party utilities. > > > You have added two methods that do not look like they are being called: useSA() and getArgs(). These two methods are there only to make the code testable without resorting to reflection and setAccessible(). Not sure what is the lesser evil ... > > Otherwise the changes look good. > > If you haven?t already, make sure sun/tools/jinfo/Basic.sh passes on all platforms and add cases to it if that is appropriate. (Note that it currently fails on solaris JDK-8038296). Basic.sh should not be affected by this change at all. But I will make sure the tests pass on all platforms before pushing. -JB- > > Thanks, > /Staffan > From staffan.larsen at oracle.com Thu Apr 3 12:51:44 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 14:51:44 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <533D586C.6090901@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> Message-ID: <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> On 3 apr 2014, at 14:47, Jaroslav Bachorik wrote: > On 3.4.2014 14:33, Staffan Larsen wrote: >> >> On 3 apr 2014, at 14:20, Jaroslav Bachorik wrote: >> >>> On 3.4.2014 14:08, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> Command line processing is still not clean, e.g. you check for -help in >>>> three different places. >>>> >>>> If you go to refactor this code rather than provide a minimal fix, >>>> it might be better to create a separate inner class that do all command >>>> line processing and provide couple of flags like should_sa(), >>>> should_help(), should_attach() etc. >>> >>> Yes, I know :( >>> >>> My first approach was exactly like that. But I was rewriting the command line parser from scratch for at least the 3rd time for "tools" alone :( And the change was going to be rather big - more of a complete rewrite than a fix. >> >> I just re-wrote that command line parser. Obviously with mixed results? :( I think the real problem here is that this command line is not specified in a way that is easily parseable, and we don?t want to change how it works. >> >> Command line parsing is one of the really hard areas in computer science. > > There are some rather flexible frameworks allowing nice command line parsing in java. But they are all 3rd party utilities. > >> >> >> You have added two methods that do not look like they are being called: useSA() and getArgs(). > > These two methods are there only to make the code testable without resorting to reflection and setAccessible(). Not sure what is the lesser evil ? My bad - I missed the test. > >> >> Otherwise the changes look good. >> >> If you haven?t already, make sure sun/tools/jinfo/Basic.sh passes on all platforms and add cases to it if that is appropriate. (Note that it currently fails on solaris JDK-8038296). > Basic.sh should not be affected by this change at all. But I will make sure the tests pass on all platforms before pushing. Thanks. Reviewed. /Staffan > > -JB- > >> >> Thanks, >> /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Apr 3 14:04:07 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 03 Apr 2014 16:04:07 +0200 Subject: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace In-Reply-To: References: Message-ID: <533D6A57.3040406@oracle.com> Hi Mattias, This looks good. Maybe you could afford to call gc() unconditionally instead of only when isAnyUsageAboveThreshold(pools) returns true. This may be taken into consideration if this test fails again ;-( Small nit: BoundlessLoaderThread.pool could be declared final. best regards, -- daniel On 4/3/14 1:58 PM, Mattias Tobiasson wrote: > Hi, > This test sometimes fails with OutOfMemory. It fails rarely, I have not been able to reproduce it. > > The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount() > 0. > UsageThresholdCount is only updated during a GC. My guess is that the test loads classes > too fast so we run out of memory before the flag is set. > > This fix will force a GC when used memory is above the threshold. > That should update the UsageThresholdCount immediately. > I have also added more logging if the test fails again. > > changes: > 1. Force a GC if memory usage is above threshold. > 2. Split the big check pools loop into sub functions. > 3. "pools" list only contains the relevant pools, > instead of keeping all pools and filter them each loop. > > webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00 > bug: https://bugs.openjdk.java.net/browse/JDK-8038822 > > Mattias > From staffan.larsen at oracle.com Thu Apr 3 14:23:51 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Apr 2014 16:23:51 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework Message-ID: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> All, In the attach framework, the result is sent back to the attaching process as a stream. The first value in the stream is an integer that is interpreted as the completion status. For successful operations, this value is 0. In that case the attaching process continues to read output from the stream and displays that as the result of the operation. When the completion status signals an error, the rest of the stream output is ignored. This means that there is currently no way for an attach operation to signal an error and provide an error message. I would like to change the protocol slightly so that the client continues to read from the stream even if the completion status signalled an error. The data that is read would be considered the error message and would be included as the message in the IOException thrown by the attachers code when an operation fails. To do this, I propose a new subclass of IOException, AttachOperationFailedException, which will be thrown in these cases from the implementation of VirtualMachine. The client can catch this exception and display the error message as well as signal that the operation failed. I have limited the error message to 200 bytes, since I did not want a runaway Diagnostic Command to enormous amounts of output in the client. When I was testing out this change, I also discovered buffer errors in the native implementations for HotSpotVirtualMachine. Fixes for these are included in this patch. The jcmd executable has been modified to 1) have an exit code of 0 if the command succeeded and 1 if it failed, 2) print out a generic message if the diagnostic command did not output anything. Since output from jcmd was modified, the JMXStartStopTest needed a slight modification as well. At a later stage, I am planning to change the hotspot code so that exceptions in Diagnostic Commands actually set the completion status to an error. Today, the completation status is set to success, just because we want the error message to propagate. bug: https://bugs.openjdk.java.net/browse/JDK-8039173 webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.00/ Thanks, /Staffan From mattias.tobiasson at oracle.com Thu Apr 3 14:41:46 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Thu, 3 Apr 2014 07:41:46 -0700 (PDT) Subject: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Message-ID: <36443dde-fddc-4513-a644-7dd04a8d026d@default> Thanks for the feedback. I first tried to call gc() unconditionally, but then the duration of the test increased from 2 to 25 seconds. I was surprised it made such a difference. I will make BoundlessLoaderThread.pool final. Mattias ----- Original Message ----- From: daniel.fuchs at oracle.com To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net Sent: Thursday, April 3, 2014 4:03:45 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Hi Mattias, This looks good. Maybe you could afford to call gc() unconditionally instead of only when isAnyUsageAboveThreshold(pools) returns true. This may be taken into consideration if this test fails again ;-( Small nit: BoundlessLoaderThread.pool could be declared final. best regards, -- daniel On 4/3/14 1:58 PM, Mattias Tobiasson wrote: > Hi, > This test sometimes fails with OutOfMemory. It fails rarely, I have not been able to reproduce it. > > The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount() > 0. > UsageThresholdCount is only updated during a GC. My guess is that the test loads classes > too fast so we run out of memory before the flag is set. > > This fix will force a GC when used memory is above the threshold. > That should update the UsageThresholdCount immediately. > I have also added more logging if the test fails again. > > changes: > 1. Force a GC if memory usage is above threshold. > 2. Split the big check pools loop into sub functions. > 3. "pools" list only contains the relevant pools, > instead of keeping all pools and filter them each loop. > > webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00 > bug: https://bugs.openjdk.java.net/browse/JDK-8038822 > > Mattias > From ivan.gerasimov at oracle.com Fri Apr 4 09:18:45 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Apr 2014 13:18:45 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> Message-ID: <533E78F5.4030800@oracle.com> Hi Staffan! I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. Sincerely yours, Ivan From staffan.larsen at oracle.com Fri Apr 4 11:33:16 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 13:33:16 +0200 Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt Message-ID: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -273,4 +273,7 @@ # 8031482 sun/tools/jcmd/TestJcmdSanity.java windows-all +# 8033104 +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all + ############################################################################ From staffan.larsen at oracle.com Fri Apr 4 11:47:03 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 13:47:03 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <533E78F5.4030800@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> Message-ID: Thanks for finding these bugs, Ivan! I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. Thanks, /Staffan diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java @@ -266,18 +266,21 @@ */ String getErrorMessage(InputStream sis, int maxlen) throws IOException { byte b[] = new byte[maxlen]; - int n, off = 0, len = b.length; + int n, off = 0, len = maxlen; do { n = sis.read(b, off, len); + if (n == -1) { + break; + } off += n; len -= n; - } while (n >= 0 && off < b.length); + } while (off < maxlen); String message = null; if (off > 0) { message = new String(b, 0, off, "UTF-8"); } - if (off == b.length && message != null) { + if (off > b.length && message != null) { message += " ..."; } return message; On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: > Hi Staffan! > > I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). > > 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, > 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. > > Sincerely yours, > Ivan > From ivan.gerasimov at oracle.com Fri Apr 4 11:55:12 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Apr 2014 15:55:12 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> Message-ID: <533E9DA0.2080200@oracle.com> Thank you Staffan for fixing them! But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. Sincerely yours, Ivan On 04.04.2014 15:47, Staffan Larsen wrote: > Thanks for finding these bugs, Ivan! > > I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. > > The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. > > Thanks, > /Staffan > > > diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > @@ -266,18 +266,21 @@ > */ > String getErrorMessage(InputStream sis, int maxlen) throws IOException { > byte b[] = new byte[maxlen]; > - int n, off = 0, len = b.length; > + int n, off = 0, len = maxlen; > do { > n = sis.read(b, off, len); > + if (n == -1) { > + break; > + } > off += n; > len -= n; > - } while (n >= 0 && off < b.length); > + } while (off < maxlen); > > String message = null; > if (off > 0) { > message = new String(b, 0, off, "UTF-8"); > } > - if (off == b.length && message != null) { > + if (off > b.length && message != null) { > message += " ..."; > } > return message; > > > On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: > >> Hi Staffan! >> >> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >> >> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >> >> Sincerely yours, >> Ivan >> > > From staffan.larsen at oracle.com Fri Apr 4 12:00:36 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 14:00:36 +0200 Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM Message-ID: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> Please review the following small change to provide more information from jstat when it fails. bug: https://bugs.openjdk.java.net/browse/JDK-8028354 webrev: http://cr.openjdk.java.net/~sla/8028354/webrev.00/ Thanks, /Staffan From staffan.larsen at oracle.com Fri Apr 4 12:08:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 14:08:14 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <533E9DA0.2080200@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> Message-ID: <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> I?m afraid you are right! Doh. Need to add more testing... How about this change: --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java @@ -267,9 +267,11 @@ String getErrorMessage(InputStream sis, int maxlen) throws IOException { byte b[] = new byte[maxlen]; int n, off = 0, len = maxlen; + boolean complete = false; do { n = sis.read(b, off, len); if (n == -1) { + complete = true; break; } off += n; @@ -280,7 +282,7 @@ if (off > 0) { message = new String(b, 0, off, "UTF-8"); } - if (off > b.length && message != null) { + if (!complete && message != null) { message += " ..."; } return message; On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: > Thank you Staffan for fixing them! > > But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. > > Sincerely yours, > Ivan > > On 04.04.2014 15:47, Staffan Larsen wrote: >> Thanks for finding these bugs, Ivan! >> >> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >> >> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >> >> Thanks, >> /Staffan >> >> >> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >> @@ -266,18 +266,21 @@ >> */ >> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >> byte b[] = new byte[maxlen]; >> - int n, off = 0, len = b.length; >> + int n, off = 0, len = maxlen; >> do { >> n = sis.read(b, off, len); >> + if (n == -1) { >> + break; >> + } >> off += n; >> len -= n; >> - } while (n >= 0 && off < b.length); >> + } while (off < maxlen); >> >> String message = null; >> if (off > 0) { >> message = new String(b, 0, off, "UTF-8"); >> } >> - if (off == b.length && message != null) { >> + if (off > b.length && message != null) { >> message += " ..."; >> } >> return message; >> >> >> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >> >>> Hi Staffan! >>> >>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>> >>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>> >>> Sincerely yours, >>> Ivan >>> >> >> > From mattias.tobiasson at oracle.com Fri Apr 4 12:12:51 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Fri, 4 Apr 2014 05:12:51 -0700 (PDT) Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Message-ID: <11993ca8-443e-4c86-b8a4-be291b3c373c@default> Hi, I have updated the patch with the following changes: Util.java line 130 - Moved Pattern from function to "private static final" RunUtil.java line 64 - Use diamond operator. webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04 I have created an enhancement for porting the other shell scripts to java (https://bugs.openjdk.java.net/browse/JDK-8039257) Mattias ----- Original Message ----- From: mandy.chung at oracle.com To: mattias.tobiasson at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Wednesday, April 2, 2014 12:22:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Hi Mattias, On 4/1/14 3:11 AM, Mattias Tobiasson wrote: > Hi Mandy, > I have moved the common code to a new utility class. Thanks for the refactoring. Looks much better. Nit: RunUtil.java line 64 - you can use diamond operator. No need to generate a new webrev. > > The shell script tests work as they are, they do not fail. > The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. > Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. > We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. Can you file a bug to replace the shell script tests with the new RunUtil class? @requires could be done independent with the shell script test conversion. thanks Mandy > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net > Cc: leonid.mesnik at oracle.com > Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: >> Hi, >> I have updated the patch to include all failing tests for this bug. >> >> The tests currently fail because their GC options collide with GC options from the test framework. >> The fix will launch the tests in a separate JVM with controlled GC options. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > Thanks for updating other failing tests. I think we are not sure when > the proper configuration support is in place and this temporary solution > to allow the tests to run is reasonable. > > It'd be better to refactor the common code to launch the test with all > GC configurations shared by jdk/test/java/lang/management/MemoryMXBean > tests. > > There are other shell tests that can be removed if the corresponding > java tests are modified to use your utility class. It's probably out > of the scope of this fix. Do you have cycles to clean them up as well? > They probably fail in VM nightlies like the ones you fixed if it > overrides with a different GC. > > LowMemoryTest2.sh > MemoryManagementParallelGC.sh > MemoryManagementConcMarkSweepGC.sh > MemoryManagementSerialGC.sh > PendingAllGC.sh > > Mandy > >> Mattias >> >> >> ----- Original Message ----- >> From: mattias.tobiasson at oracle.com >> To: mandy.chung at oracle.com >> Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com >> Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mandy, >> I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. >> >> I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. >> >> I did not notice that there are more tests in the same dir. I will change them too. >> >> Mattias >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com >> Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mattias, >> >> Have you discussed with Jon Gibbons about the jtreg @requires support? >> I thought it was partly motivated by the requirement to specify a test >> to run in different collector. >> >> The reason why these regression tests explicitly specifies different GC >> flags was to increase the coverage and ensure to catch regression early >> during development cycle. At that time, the VM nightly testing rotates >> the test execution with different GC configuration that delayed to catch >> a regression that occurs in one collector while the nightly testing is >> testing another collector. For integration, I don't recall if different >> collectors are tested rather than default. It may be time to revisit >> the test execution with different collectors. If the verification of >> different collectors is well covered in nightly, perhaps these tests no >> longer need one @run per each collector. >> >> There are other regression tests that specifies the -XX:+UseXXGC flag in >> the @run tag. It makes sense to modify them in the same patch (perhaps >> at least tests under test/java/lang/management). >> >> Mandy >> >> On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >>> Hi, >>> Could you please review this test fix. >>> >>> The test fails because it specifies its own GC command line options, for example: >>> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >>> >>> When the framework also specifies GC version, then the test will fail with this log: >>> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >>> >>> The solution is to run the test in a separate JVM with controlled GC options. >>> The test will be run multiple times. >>> First with the command line specified from the framework, without test specific GC options. >>> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >>> >>> Mattias >>> From mattias.tobiasson at oracle.com Fri Apr 4 12:20:14 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Fri, 4 Apr 2014 05:20:14 -0700 (PDT) Subject: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Message-ID: <3ebde040-5162-41c9-89f6-a926dfe34f38@default> Hi Daniel, Could you please sponsor the attached patch? Webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.01 The only change is that I have made BoundlessLoaderThread.pool final. Mattias ----- Original Message ----- From: mattias.tobiasson at oracle.com To: daniel.fuchs at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Thursday, April 3, 2014 4:41:46 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Thanks for the feedback. I first tried to call gc() unconditionally, but then the duration of the test increased from 2 to 25 seconds. I was surprised it made such a difference. I will make BoundlessLoaderThread.pool final. Mattias ----- Original Message ----- From: daniel.fuchs at oracle.com To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net Sent: Thursday, April 3, 2014 4:03:45 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace Hi Mattias, This looks good. Maybe you could afford to call gc() unconditionally instead of only when isAnyUsageAboveThreshold(pools) returns true. This may be taken into consideration if this test fails again ;-( Small nit: BoundlessLoaderThread.pool could be declared final. best regards, -- daniel On 4/3/14 1:58 PM, Mattias Tobiasson wrote: > Hi, > This test sometimes fails with OutOfMemory. It fails rarely, I have not been able to reproduce it. > > The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount() > 0. > UsageThresholdCount is only updated during a GC. My guess is that the test loads classes > too fast so we run out of memory before the flag is set. > > This fix will force a GC when used memory is above the threshold. > That should update the UsageThresholdCount immediately. > I have also added more logging if the test fails again. > > changes: > 1. Force a GC if memory usage is above threshold. > 2. Split the big check pools loop into sub functions. > 3. "pools" list only contains the relevant pools, > instead of keeping all pools and filter them each loop. > > webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00 > bug: https://bugs.openjdk.java.net/browse/JDK-8038822 > > Mattias > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8038822.diff Type: text/x-patch Size: 6121 bytes Desc: not available URL: From ivan.gerasimov at oracle.com Fri Apr 4 12:24:58 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Apr 2014 16:24:58 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> Message-ID: <533EA49A.6000609@oracle.com> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). The dots will be appended to the message, even though it's not necessary. I think the only reliable way to deal with it is to try to read one extra character from sis. Something like this should do: ------------------------ String getErrorMessage(InputStream sis, int maxlen) throws IOException { byte b[] = new byte[maxlen + 1]; int n, off = 0, len = b.length; do { n = sis.read(b, off, len); if (n == -1) { break; } off += n; len -= n; } while (off < maxlen); String message = null; if (off > 0) { message = (off > maxlen) ? new String(b, 0, maxlen, "UTF-8") + " ..." : new String(b, 0, off, "UTF-8"); } return message; } ------------------------ Sincerely yours, Ivan On 04.04.2014 16:08, Staffan Larsen wrote: > I?m afraid you are right! Doh. Need to add more testing... > > How about this change: > > --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > @@ -267,9 +267,11 @@ > String getErrorMessage(InputStream sis, int maxlen) throws IOException { > byte b[] = new byte[maxlen]; > int n, off = 0, len = maxlen; > + boolean complete = false; > do { > n = sis.read(b, off, len); > if (n == -1) { > + complete = true; > break; > } > off += n; > @@ -280,7 +282,7 @@ > if (off > 0) { > message = new String(b, 0, off, "UTF-8"); > } > - if (off > b.length && message != null) { > + if (!complete && message != null) { > message += " ..."; > } > return message; > > > On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: > >> Thank you Staffan for fixing them! >> >> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >> >> Sincerely yours, >> Ivan >> >> On 04.04.2014 15:47, Staffan Larsen wrote: >>> Thanks for finding these bugs, Ivan! >>> >>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>> >>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>> >>> Thanks, >>> /Staffan >>> >>> >>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>> @@ -266,18 +266,21 @@ >>> */ >>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>> byte b[] = new byte[maxlen]; >>> - int n, off = 0, len = b.length; >>> + int n, off = 0, len = maxlen; >>> do { >>> n = sis.read(b, off, len); >>> + if (n == -1) { >>> + break; >>> + } >>> off += n; >>> len -= n; >>> - } while (n >= 0 && off < b.length); >>> + } while (off < maxlen); >>> >>> String message = null; >>> if (off > 0) { >>> message = new String(b, 0, off, "UTF-8"); >>> } >>> - if (off == b.length && message != null) { >>> + if (off > b.length && message != null) { >>> message += " ..."; >>> } >>> return message; >>> >>> >>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>> >>>> Hi Staffan! >>>> >>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>> >>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>> > > From david.holmes at oracle.com Fri Apr 4 12:29:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Apr 2014 22:29:28 +1000 Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM In-Reply-To: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> References: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> Message-ID: <533EA5A8.2040906@oracle.com> On 4/04/2014 10:00 PM, Staffan Larsen wrote: > Please review the following small change to provide more information from jstat when it fails. > > bug: https://bugs.openjdk.java.net/browse/JDK-8028354 > webrev: http://cr.openjdk.java.net/~sla/8028354/webrev.00/ Seems reasonable. But I bet there is a test somewhere that will need changing :) David > Thanks, > /Staffan > From staffan.larsen at oracle.com Fri Apr 4 12:34:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 14:34:42 +0200 Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM In-Reply-To: <533EA5A8.2040906@oracle.com> References: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> <533EA5A8.2040906@oracle.com> Message-ID: On 4 apr 2014, at 14:29, David Holmes wrote: > On 4/04/2014 10:00 PM, Staffan Larsen wrote: >> Please review the following small change to provide more information from jstat when it fails. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8028354 >> webrev: http://cr.openjdk.java.net/~sla/8028354/webrev.00/ > > Seems reasonable. But I bet there is a test somewhere that will need changing :) Look forward to it! ;) /Staffan > > David > >> Thanks, >> /Staffan >> From markus.gronlund at oracle.com Fri Apr 4 12:45:02 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 4 Apr 2014 05:45:02 -0700 (PDT) Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt In-Reply-To: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> References: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Message-ID: <9d433983-6ce7-4894-acfc-7b32e6e0ed1d@default> Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 4 april 2014 13:33 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; core-libs-dev Libs Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -273,4 +273,7 @@ # 8031482 sun/tools/jcmd/TestJcmdSanity.java windows-all +# 8033104 +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all + ############################################################################ From ivan.gerasimov at oracle.com Fri Apr 4 12:41:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 04 Apr 2014 16:41:10 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <533EA49A.6000609@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> Message-ID: <533EA866.5060404@oracle.com> An alternative, more compact variant might be ------------------------ String getErrorMessage(InputStream sis, int maxlen) throws IOException { int n, off = 0, len = maxlen + 1; byte b[] = new byte[len]; while ((n = sis.read(b, off, len - off)) > 0) off += n; return (off == 0) ? null : (off < len) ? new String(b, 0, off, "UTF-8") : new String(b, 0, maxlen, "UTF-8") + " ..."; } ------------------------ Not a big deal, of course. Sincerely yours, Ivan On 04.04.2014 16:24, Ivan Gerasimov wrote: > Now you reintroduced the smallish issue, when the message is exactly > 200 characters (or whatever maxlen is). > The dots will be appended to the message, even though it's not necessary. > > I think the only reliable way to deal with it is to try to read one > extra character from sis. > > Something like this should do: > ------------------------ > String getErrorMessage(InputStream sis, int maxlen) throws > IOException { > byte b[] = new byte[maxlen + 1]; > int n, off = 0, len = b.length; > do { > n = sis.read(b, off, len); > if (n == -1) { > break; > } > off += n; > len -= n; > } while (off < maxlen); > > String message = null; > if (off > 0) { > message = (off > maxlen) > ? new String(b, 0, maxlen, "UTF-8") + " ..." > : new String(b, 0, off, "UTF-8"); > } > return message; > } > ------------------------ > > Sincerely yours, > Ivan > > On 04.04.2014 16:08, Staffan Larsen wrote: >> I?m afraid you are right! Doh. Need to add more testing... >> >> How about this change: >> >> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >> @@ -267,9 +267,11 @@ >> String getErrorMessage(InputStream sis, int maxlen) throws >> IOException { >> byte b[] = new byte[maxlen]; >> int n, off = 0, len = maxlen; >> + boolean complete = false; >> do { >> n = sis.read(b, off, len); >> if (n == -1) { >> + complete = true; >> break; >> } >> off += n; >> @@ -280,7 +282,7 @@ >> if (off > 0) { >> message = new String(b, 0, off, "UTF-8"); >> } >> - if (off > b.length && message != null) { >> + if (!complete && message != null) { >> message += " ..."; >> } >> return message; >> >> >> On 4 apr 2014, at 13:55, Ivan Gerasimov >> wrote: >> >>> Thank you Staffan for fixing them! >>> >>> But I'm afraid that now the function will never add ellipsis to the >>> message, even if it gets truncated. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>> Thanks for finding these bugs, Ivan! >>>> >>>> I have updated the webrev at: >>>> http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also >>>> included the diff below. >>>> >>>> The updated webrev also has some changes in the javadoc for >>>> VirtualMachine to clarify that some methods can now throw >>>> AttachOperationFailedException. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> diff --git >>>> a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> @@ -266,18 +266,21 @@ >>>> */ >>>> String getErrorMessage(InputStream sis, int maxlen) throws >>>> IOException { >>>> byte b[] = new byte[maxlen]; >>>> - int n, off = 0, len = b.length; >>>> + int n, off = 0, len = maxlen; >>>> do { >>>> n = sis.read(b, off, len); >>>> + if (n == -1) { >>>> + break; >>>> + } >>>> off += n; >>>> len -= n; >>>> - } while (n >= 0 && off < b.length); >>>> + } while (off < maxlen); >>>> >>>> String message = null; >>>> if (off > 0) { >>>> message = new String(b, 0, off, "UTF-8"); >>>> } >>>> - if (off == b.length && message != null) { >>>> + if (off > b.length && message != null) { >>>> message += " ..."; >>>> } >>>> return message; >>>> >>>> >>>> On 4 apr 2014, at 11:18, Ivan Gerasimov >>>> wrote: >>>> >>>>> Hi Staffan! >>>>> >>>>> I think there is a couple of minor bugs in >>>>> getErrorMessage(InputStream sis, int maxlen). >>>>> >>>>> 1) If maxlen is exactly the size of the message to read, the >>>>> function will add an ellipsis, even though the message isn't >>>>> truncated, >>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at >>>>> the line #271 will eventually return -1, and it will cause the >>>>> message to lose its last character. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>> >> >> > > > From markus.gronlund at oracle.com Fri Apr 4 12:48:25 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 4 Apr 2014 05:48:25 -0700 (PDT) Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM In-Reply-To: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> References: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> Message-ID: Looks good. /Markus -----Original Message----- From: Staffan Larsen Sent: den 4 april 2014 14:01 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM Please review the following small change to provide more information from jstat when it fails. bug: https://bugs.openjdk.java.net/browse/JDK-8028354 webrev: http://cr.openjdk.java.net/~sla/8028354/webrev.00/ Thanks, /Staffan From yekaterina.kantserova at oracle.com Fri Apr 4 13:25:09 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 04 Apr 2014 15:25:09 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. Message-ID: <533EB2B5.9030909@oracle.com> Hi, Could I please have a review of this fix. webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8031766 The bug is not visible. But short summary is as follows. sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, TestJstatdServer.java have been failing because they expect only one jstad process running. I've added a unique identifier for the jstad process tests start. So the tests will no more care about how many other jstad processes are running. Thanks, Katja From Alan.Bateman at oracle.com Fri Apr 4 13:31:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 14:31:11 +0100 Subject: RFR: 8028354 jstat does not provide enough information when fail to read data from remote JVM In-Reply-To: <533EA5A8.2040906@oracle.com> References: <14B296F6-26E6-4D35-ADD5-9D9A58E5A5A5@oracle.com> <533EA5A8.2040906@oracle.com> Message-ID: <533EB41F.6050405@oracle.com> On 04/04/2014 13:29, David Holmes wrote: > On 4/04/2014 10:00 PM, Staffan Larsen wrote: >> Please review the following small change to provide more information >> from jstat when it fails. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8028354 >> webrev: http://cr.openjdk.java.net/~sla/8028354/webrev.00/ > > Seems reasonable. But I bet there is a test somewhere that will need > changing :) It looks reasonable to me too, I assume there are a bunch of issues that arise in test environments with concurrent execution or stale VMs left behind. Hopefully this help get more information and help improve the tests to make them more robust. -Alan. From jaroslav.bachorik at oracle.com Fri Apr 4 13:32:22 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 04 Apr 2014 15:32:22 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EB2B5.9030909@oracle.com> References: <533EB2B5.9030909@oracle.com> Message-ID: <533EB466.5070404@oracle.com> Looks fine. You might add a small performance improvement by taking out the regex out of the loop at line 99 (compile the pattern before starting the loop). -JB- On 4.4.2014 15:25, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8031766 > > The bug is not visible. But short summary is as follows. > sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, > TestJstatdServer.java have been failing because they expect only one > jstad process running. I've added a unique identifier for the jstad > process tests start. So the tests will no more care about how many other > jstad processes are running. > > Thanks, > Katja From yekaterina.kantserova at oracle.com Fri Apr 4 14:02:47 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 04 Apr 2014 16:02:47 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EB466.5070404@oracle.com> References: <533EB2B5.9030909@oracle.com> <533EB466.5070404@oracle.com> Message-ID: <533EBB87.70009@oracle.com> Thanks, Jaroslav! Please find the new webrev here: http://cr.openjdk.java.net/~ykantser/8031766/webrev.01/ // Katja On 04/04/2014 03:32 PM, Jaroslav Bachorik wrote: > Looks fine. > You might add a small performance improvement by taking out the regex > out of the loop at line 99 (compile the pattern before starting the > loop). > > -JB- > > On 4.4.2014 15:25, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8031766 >> >> The bug is not visible. But short summary is as follows. >> sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, >> TestJstatdServer.java have been failing because they expect only one >> jstad process running. I've added a unique identifier for the jstad >> process tests start. So the tests will no more care about how many other >> jstad processes are running. >> >> Thanks, >> Katja > From jaroslav.bachorik at oracle.com Fri Apr 4 14:04:17 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 04 Apr 2014 16:04:17 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EBB87.70009@oracle.com> References: <533EB2B5.9030909@oracle.com> <533EB466.5070404@oracle.com> <533EBB87.70009@oracle.com> Message-ID: <533EBBE1.1000806@oracle.com> No more comments. -JB- On 4.4.2014 16:02, Yekaterina Kantserova wrote: > Thanks, Jaroslav! > Please find the new webrev here: > http://cr.openjdk.java.net/~ykantser/8031766/webrev.01/ > > // Katja > > > > On 04/04/2014 03:32 PM, Jaroslav Bachorik wrote: >> Looks fine. >> You might add a small performance improvement by taking out the regex >> out of the loop at line 99 (compile the pattern before starting the >> loop). >> >> -JB- >> >> On 4.4.2014 15:25, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8031766 >>> >>> The bug is not visible. But short summary is as follows. >>> sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, >>> TestJstatdServer.java have been failing because they expect only one >>> jstad process running. I've added a unique identifier for the jstad >>> process tests start. So the tests will no more care about how many other >>> jstad processes are running. >>> >>> Thanks, >>> Katja >> > From staffan.larsen at oracle.com Fri Apr 4 14:17:00 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 16:17:00 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EBB87.70009@oracle.com> References: <533EB2B5.9030909@oracle.com> <533EB466.5070404@oracle.com> <533EBB87.70009@oracle.com> Message-ID: <1BD3948F-72A7-4896-B07D-A7FFD6EAB28E@oracle.com> Looks good! Thanks, /Staffan On 4 apr 2014, at 16:02, Yekaterina Kantserova wrote: > Thanks, Jaroslav! > Please find the new webrev here: http://cr.openjdk.java.net/~ykantser/8031766/webrev.01/ > > // Katja > > > > On 04/04/2014 03:32 PM, Jaroslav Bachorik wrote: >> Looks fine. >> You might add a small performance improvement by taking out the regex out of the loop at line 99 (compile the pattern before starting the loop). >> >> -JB- >> >> On 4.4.2014 15:25, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8031766 >>> >>> The bug is not visible. But short summary is as follows. >>> sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, >>> TestJstatdServer.java have been failing because they expect only one >>> jstad process running. I've added a unique identifier for the jstad >>> process tests start. So the tests will no more care about how many other >>> jstad processes are running. >>> >>> Thanks, >>> Katja >> > From daniel.fuchs at oracle.com Fri Apr 4 14:19:15 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Apr 2014 16:19:15 +0200 Subject: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace In-Reply-To: <3ebde040-5162-41c9-89f6-a926dfe34f38@default> References: <3ebde040-5162-41c9-89f6-a926dfe34f38@default> Message-ID: <533EBF63.6040402@oracle.com> On 4/4/14 2:20 PM, Mattias Tobiasson wrote: > Hi Daniel, > Could you please sponsor the attached patch? > Webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.01 > > The only change is that I have made BoundlessLoaderThread.pool final. No Problem Mattias, I'll do it! -- daniel > > Mattias > > ----- Original Message ----- > From: mattias.tobiasson at oracle.com > To: daniel.fuchs at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Thursday, April 3, 2014 4:41:46 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace > > Thanks for the feedback. > > I first tried to call gc() unconditionally, but then the duration of the test > increased from 2 to 25 seconds. I was surprised it made such a difference. > > I will make BoundlessLoaderThread.pool final. > > Mattias > > ----- Original Message ----- > From: daniel.fuchs at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net > Sent: Thursday, April 3, 2014 4:03:45 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace > > Hi Mattias, > > This looks good. > > Maybe you could afford to call gc() unconditionally > instead of only when isAnyUsageAboveThreshold(pools) returns > true. > This may be taken into consideration if this test fails again ;-( > > Small nit: BoundlessLoaderThread.pool could be declared final. > > best regards, > > -- daniel > > On 4/3/14 1:58 PM, Mattias Tobiasson wrote: >> Hi, >> This test sometimes fails with OutOfMemory. It fails rarely, I have not been able to reproduce it. >> >> The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount() > 0. >> UsageThresholdCount is only updated during a GC. My guess is that the test loads classes >> too fast so we run out of memory before the flag is set. >> >> This fix will force a GC when used memory is above the threshold. >> That should update the UsageThresholdCount immediately. >> I have also added more logging if the test fails again. >> >> changes: >> 1. Force a GC if memory usage is above threshold. >> 2. Split the big check pools loop into sub functions. >> 3. "pools" list only contains the relevant pools, >> instead of keeping all pools and filter them each loop. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00 >> bug: https://bugs.openjdk.java.net/browse/JDK-8038822 >> >> Mattias >> > From staffan.larsen at oracle.com Fri Apr 4 14:27:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Apr 2014 16:27:02 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <533EA866.5060404@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> Message-ID: Thanks Ivan. I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). If someone has a better solution for propagating error messages from the operations, I?m all ears. Thanks, /Staffan On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: > An alternative, more compact variant might be > > ------------------------ > String getErrorMessage(InputStream sis, int maxlen) throws IOException { > int n, off = 0, len = maxlen + 1; > byte b[] = new byte[len]; > while ((n = sis.read(b, off, len - off)) > 0) > off += n; > return (off == 0) ? null > : (off < len) > ? new String(b, 0, off, "UTF-8") > : new String(b, 0, maxlen, "UTF-8") + " ..."; > } > ------------------------ > > Not a big deal, of course. > > Sincerely yours, > Ivan > > > > On 04.04.2014 16:24, Ivan Gerasimov wrote: >> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >> The dots will be appended to the message, even though it's not necessary. >> >> I think the only reliable way to deal with it is to try to read one extra character from sis. >> >> Something like this should do: >> ------------------------ >> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >> byte b[] = new byte[maxlen + 1]; >> int n, off = 0, len = b.length; >> do { >> n = sis.read(b, off, len); >> if (n == -1) { >> break; >> } >> off += n; >> len -= n; >> } while (off < maxlen); >> >> String message = null; >> if (off > 0) { >> message = (off > maxlen) >> ? new String(b, 0, maxlen, "UTF-8") + " ..." >> : new String(b, 0, off, "UTF-8"); >> } >> return message; >> } >> ------------------------ >> >> Sincerely yours, >> Ivan >> >> On 04.04.2014 16:08, Staffan Larsen wrote: >>> I?m afraid you are right! Doh. Need to add more testing... >>> >>> How about this change: >>> >>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>> @@ -267,9 +267,11 @@ >>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>> byte b[] = new byte[maxlen]; >>> int n, off = 0, len = maxlen; >>> + boolean complete = false; >>> do { >>> n = sis.read(b, off, len); >>> if (n == -1) { >>> + complete = true; >>> break; >>> } >>> off += n; >>> @@ -280,7 +282,7 @@ >>> if (off > 0) { >>> message = new String(b, 0, off, "UTF-8"); >>> } >>> - if (off > b.length && message != null) { >>> + if (!complete && message != null) { >>> message += " ..."; >>> } >>> return message; >>> >>> >>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>> >>>> Thank you Staffan for fixing them! >>>> >>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>> Thanks for finding these bugs, Ivan! >>>>> >>>>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>> >>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>> @@ -266,18 +266,21 @@ >>>>> */ >>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>> byte b[] = new byte[maxlen]; >>>>> - int n, off = 0, len = b.length; >>>>> + int n, off = 0, len = maxlen; >>>>> do { >>>>> n = sis.read(b, off, len); >>>>> + if (n == -1) { >>>>> + break; >>>>> + } >>>>> off += n; >>>>> len -= n; >>>>> - } while (n >= 0 && off < b.length); >>>>> + } while (off < maxlen); >>>>> >>>>> String message = null; >>>>> if (off > 0) { >>>>> message = new String(b, 0, off, "UTF-8"); >>>>> } >>>>> - if (off == b.length && message != null) { >>>>> + if (off > b.length && message != null) { >>>>> message += " ..."; >>>>> } >>>>> return message; >>>>> >>>>> >>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>> >>>>>> Hi Staffan! >>>>>> >>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>> >>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>> >>> >>> >> >> >> > From Alan.Bateman at oracle.com Fri Apr 4 15:30:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Apr 2014 16:30:40 +0100 Subject: RFR: 8039256 Add sun/jvmstat/monitor/MonitoredVm/CR6672135.java to ProblemList.txt In-Reply-To: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> References: <62E765EE-6B7F-4D80-A0F2-66D02BEEC1BB@oracle.com> Message-ID: <533ED020.6010902@oracle.com> On 04/04/2014 12:33, Staffan Larsen wrote: > Please review the change below to add a test to ProblemList.txt. For details, see https://bugs.openjdk.java.net/browse/JDK-8033104 > > Thanks, > /Staffan > > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -273,4 +273,7 @@ > # 8031482 > sun/tools/jcmd/TestJcmdSanity.java windows-all > > +# 8033104 > +sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all > + > ############################################################################ Excluding this test until the issue running with java.io.tmpdir set is resolved seem okay to me. -Alan From dmitry.samersoff at oracle.com Fri Apr 4 16:28:33 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 04 Apr 2014 20:28:33 +0400 Subject: Should we get rid of libnpt.so ? Message-ID: <533EDDB1.2030307@oracle.com> Hi Everybody, We have an libnpt.so[1] in JDK. This library contains bunch of UTF related functions. On a brief investigation it looks like most of these functions are not used. Six functions below called one time each from share/back/* and hprof_init.c [2] Should I file a CR to have it cleaned up - remove npt library as a separate entity and move few utf functions that really used to place where it actually called. [1] Library sources location src/share/npt src/solaris/npt src/windows/npt [2] Library usage src/share/back/transport.c: utf8FromPlatform utf8ToPlatform src/share/back/inStream.c: utf8sToUtf8m utf8sToUtf8mLength src/share/back/outStream.c: utf8mToUtf8s utf8mToUtf8sLength src/share/demo/jvmti/hprof/hprof_init.c utf8ToPlatform -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kellyohair at gmail.com Fri Apr 4 16:52:04 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Fri, 4 Apr 2014 09:52:04 -0700 Subject: Should we get rid of libnpt.so ? In-Reply-To: <533EDDB1.2030307@oracle.com> References: <533EDDB1.2030307@oracle.com> Message-ID: Just as background information... The serviceability team should do what they think is right here, I'll just provide some history... ;) The original purpose of this library was to provide some generic native platform tools for dealing with things that will happen BEFORE the JVM is started and Java code can be called. This was necessary for JVM agents (hprof, debugger backend, jvmti demo agents) and any native code that was executed before the JVM had gotten off the ground. Doing arbitrary character encoding conversions to/from the various flavors of UTF-8 is a nightmare outside Java. And since the characters typed in on a java commandline is in the OS's default platform encoding, and not in UTF-8, they need to be converted. Since this native code was not part of hotspot, and was written in C, using the hotspot functionality for this was not possible at the time. This logic was isolated because it was so OS specific and ugly, and we (maybe just me) had visions of needed more in this library, and that maybe we could limit the ifdef-mania to this library rather than scatter the same ifdef-mania all over the rest of the JDK native code that lives outside hotspot. So it seemed natural to isolate it as a separate little library that could be unit tested on it's own. It's extremely likely that it could be trimmed down, and as more and more OS default encodings become UTF-8, maybe it' will eventually become obsolete. Hope this helps. -kto On Apr 4, 2014, at 9:28 AM, Dmitry Samersoff wrote: > Hi Everybody, > > We have an libnpt.so[1] in JDK. This library contains bunch of UTF > related functions. On a brief investigation it looks like most of these > functions are not used. Six functions below called one time each from > share/back/* and hprof_init.c [2] > > Should I file a CR to have it cleaned up - remove npt library as a > separate entity and move few utf functions that really used to place > where it actually called. > > > [1] Library sources location > > src/share/npt > src/solaris/npt > src/windows/npt > > [2] Library usage > > src/share/back/transport.c: > > utf8FromPlatform > utf8ToPlatform > > src/share/back/inStream.c: > > utf8sToUtf8m > utf8sToUtf8mLength > > src/share/back/outStream.c: > > utf8mToUtf8s > utf8mToUtf8sLength > > > src/share/demo/jvmti/hprof/hprof_init.c > > utf8ToPlatform > > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri Apr 4 16:58:04 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 04 Apr 2014 20:58:04 +0400 Subject: Should we get rid of libnpt.so ? In-Reply-To: References: <533EDDB1.2030307@oracle.com> Message-ID: <533EE49C.2040306@oracle.com> Kelly, Thank you for the background. -Dmitry On 2014-04-04 20:52, Kelly O'Hair wrote: > Just as background information... > > The serviceability team should do what they think is right here, I'll just provide some history... ;) > > The original purpose of this library was to provide some generic native platform tools for dealing with things that will happen BEFORE the JVM is started and Java code can be called. > > This was necessary for JVM agents (hprof, debugger backend, jvmti demo agents) and any native code that was executed before the JVM had gotten off the ground. > Doing arbitrary character encoding conversions to/from the various flavors of UTF-8 is a nightmare outside Java. > And since the characters typed in on a java commandline is in the OS's default platform encoding, and not in UTF-8, they need to be converted. > Since this native code was not part of hotspot, and was written in C, using the hotspot functionality for this was not possible at the time. > > This logic was isolated because it was so OS specific and ugly, and we (maybe just me) had visions of needed more in this library, and that maybe we could limit the ifdef-mania to this library rather than scatter the same ifdef-mania all over the rest of the JDK native code that lives outside hotspot. > So it seemed natural to isolate it as a separate little library that could be unit tested on it's own. > > It's extremely likely that it could be trimmed down, and as more and more OS default encodings become UTF-8, maybe it' will eventually become obsolete. > > Hope this helps. > > -kto > > On Apr 4, 2014, at 9:28 AM, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >> related functions. On a brief investigation it looks like most of these >> functions are not used. Six functions below called one time each from >> share/back/* and hprof_init.c [2] >> >> Should I file a CR to have it cleaned up - remove npt library as a >> separate entity and move few utf functions that really used to place >> where it actually called. >> >> >> [1] Library sources location >> >> src/share/npt >> src/solaris/npt >> src/windows/npt >> >> [2] Library usage >> >> src/share/back/transport.c: >> >> utf8FromPlatform >> utf8ToPlatform >> >> src/share/back/inStream.c: >> >> utf8sToUtf8m >> utf8sToUtf8mLength >> >> src/share/back/outStream.c: >> >> utf8mToUtf8s >> utf8mToUtf8sLength >> >> >> src/share/demo/jvmti/hprof/hprof_init.c >> >> utf8ToPlatform >> >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Sun Apr 6 18:16:00 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 6 Apr 2014 20:16:00 +0200 Subject: Should we get rid of libnpt.so ? In-Reply-To: <533EDDB1.2030307@oracle.com> References: <533EDDB1.2030307@oracle.com> Message-ID: <011B69CF-4FD6-4B66-9256-C981F28EA196@oracle.com> It makes sense to have this code separated out. But I?m not sure it makes sense to compile it into a separate library. We could just as well compile in the necessary source files where needed. And if there are unused functions, I think they could be removed to decrease the maintenance burden. /Staffan On 4 apr 2014, at 18:28, Dmitry Samersoff wrote: > Hi Everybody, > > We have an libnpt.so[1] in JDK. This library contains bunch of UTF > related functions. On a brief investigation it looks like most of these > functions are not used. Six functions below called one time each from > share/back/* and hprof_init.c [2] > > Should I file a CR to have it cleaned up - remove npt library as a > separate entity and move few utf functions that really used to place > where it actually called. > > > [1] Library sources location > > src/share/npt > src/solaris/npt > src/windows/npt > > [2] Library usage > > src/share/back/transport.c: > > utf8FromPlatform > utf8ToPlatform > > src/share/back/inStream.c: > > utf8sToUtf8m > utf8sToUtf8mLength > > src/share/back/outStream.c: > > utf8mToUtf8s > utf8mToUtf8sLength > > > src/share/demo/jvmti/hprof/hprof_init.c > > utf8ToPlatform > > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Mon Apr 7 00:56:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Apr 2014 10:56:24 +1000 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EB2B5.9030909@oracle.com> References: <533EB2B5.9030909@oracle.com> Message-ID: <5341F7B8.60302@oracle.com> Hi Katja, I don't object to making the test more resilient, but I do have to wonder why we have multiple jstatd processes as that would seem to indicate another problem that needs addressing. David On 4/04/2014 11:25 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8031766 > > The bug is not visible. But short summary is as follows. > sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, > TestJstatdServer.java have been failing because they expect only one > jstad process running. I've added a unique identifier for the jstad > process tests start. So the tests will no more care about how many other > jstad processes are running. > > Thanks, > Katja From staffan.larsen at oracle.com Mon Apr 7 06:13:00 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 08:13:00 +0200 Subject: Should we get rid of libnpt.so ? In-Reply-To: References: <533EDDB1.2030307@oracle.com> Message-ID: <60C36D53-0F77-412C-8B18-1D9880178AA7@oracle.com> Curious: What does NPT stand for? On 4 apr 2014, at 18:52, Kelly O'Hair wrote: > Just as background information... > > The serviceability team should do what they think is right here, I'll just provide some history... ;) > > The original purpose of this library was to provide some generic native platform tools for dealing with things that will happen BEFORE the JVM is started and Java code can be called. > > This was necessary for JVM agents (hprof, debugger backend, jvmti demo agents) and any native code that was executed before the JVM had gotten off the ground. > Doing arbitrary character encoding conversions to/from the various flavors of UTF-8 is a nightmare outside Java. > And since the characters typed in on a java commandline is in the OS's default platform encoding, and not in UTF-8, they need to be converted. > Since this native code was not part of hotspot, and was written in C, using the hotspot functionality for this was not possible at the time. > > This logic was isolated because it was so OS specific and ugly, and we (maybe just me) had visions of needed more in this library, and that maybe we could limit the ifdef-mania to this library rather than scatter the same ifdef-mania all over the rest of the JDK native code that lives outside hotspot. > So it seemed natural to isolate it as a separate little library that could be unit tested on it's own. > > It's extremely likely that it could be trimmed down, and as more and more OS default encodings become UTF-8, maybe it' will eventually become obsolete. > > Hope this helps. > > -kto > > On Apr 4, 2014, at 9:28 AM, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >> related functions. On a brief investigation it looks like most of these >> functions are not used. Six functions below called one time each from >> share/back/* and hprof_init.c [2] >> >> Should I file a CR to have it cleaned up - remove npt library as a >> separate entity and move few utf functions that really used to place >> where it actually called. >> >> >> [1] Library sources location >> >> src/share/npt >> src/solaris/npt >> src/windows/npt >> >> [2] Library usage >> >> src/share/back/transport.c: >> >> utf8FromPlatform >> utf8ToPlatform >> >> src/share/back/inStream.c: >> >> utf8sToUtf8m >> utf8sToUtf8mLength >> >> src/share/back/outStream.c: >> >> utf8mToUtf8s >> utf8mToUtf8sLength >> >> >> src/share/demo/jvmti/hprof/hprof_init.c >> >> utf8ToPlatform >> >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > From staffan.larsen at oracle.com Mon Apr 7 06:31:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 08:31:08 +0200 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> <533514F4.8050906@oracle.com> <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com> Message-ID: <4B0BFA9A-4970-4BDB-A2A0-BF6057EB7298@oracle.com> Could I have an official Review of this change? Thanks, /Staffan On 3 apr 2014, at 11:31, Staffan Larsen wrote: > Thanks Serguei, > > I don?t think it is necessary to initialize ?end? since strtol will always set it. > > I still need an official Reviewer for this change. > > Thanks, > /Staffan > > On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote: > >> On 3/27/14 12:55 AM, Staffan Larsen wrote: >>> Here is an updated webrev which incorporates Dmitry?s feedback: >>> >>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/ >> >> >> It looks good. >> The only suggestion is to initialize the 'end': >> char* end; >> >> Not sure what value is better to use for initialization. >> Probably, end = probe would work Ok. >> >> Thanks, >> Serguei >>> >>> Thanks, >>> /Staffan >>> >>> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: >>> >>>> Staffan, >>>> >>>>> Yes, that will find problems when trying to convert something like >>>>> ?bla?. It will not capture the case where the input string is a too >>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>>> both cases it looks like we need something like: >>>>> errno = 0; >>>>> char* end; >>>>> int probe_typess = (int) strtol(probe, &end, 10); >>>>> if (end == probe || errno) { >>>>> return JNI_ERR; >>>>> } >>>> As probe_typess is positive and you are converting long to int >>>> It's be better to check value boundaries explicitly: >>>> >>>> char* end; >>>> long ptl = strtol(probe, &end, 10); >>>> if (end == probe || ptl < 0 || ptl > MAX_INT) { >>>> return JNI_ERR; >>>> } >>>> >>>> int probe_typess = (int) ptl; >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-25 17:35, Staffan Larsen wrote: >>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff >>>>> wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> strtol() sets errno in two cases - >>>>>> >>>>>> ERANGE if supplied value is less then LONG_MIN or greater than >>>>>> LONG_MAX EINVAL if supplied base is not supported. >>>>>> >>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not >>>>>> be set. So I'm not sure that check for errno has any value here. >>>>>> >>>>>> One of possible way to check that supplied value is convertible to >>>>>> long is >>>>>> >>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>>>>> probe) { // we can't convert supplied value return JNI_ERR; } >>>>> Yes, that will find problems when trying to convert something like >>>>> ?bla?. It will not capture the case where the input string is a too >>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>>> both cases it looks like we need something like: >>>>> >>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >>>>> 10); if (end == probe || errno) { return JNI_ERR; } >>>>> >>>>> >>>>> /Staffan >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>>>>> see if any errors occurred. The problem is that atoi() does not >>>>>>> set errno, so some old value of errno is checked which sometimes >>>>>>> causes the function to fail. >>>>>>> >>>>>>> The fix is to replace atoi() with strtol() which does set errno. >>>>>>> But errno is only set if an error occurred and not set to 0 in >>>>>>> case of success. Thus, I set errno to 0 before calling strtol() >>>>>>> and check the value afterwards. >>>>>>> >>>>>>> Verified with a JPRT run. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>>>>> >>>>>>> Thanks, /Staffan >>>>>>> >>>>>> >>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>>> Russia * I would love to change the world, but they won't give me >>>>>> the sources. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > From staffan.larsen at oracle.com Mon Apr 7 06:41:47 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 08:41:47 +0200 Subject: RFR: 8038963 com/sun/jdi tests fail because cygwin's ps sometimes misses processes In-Reply-To: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> References: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> Message-ID: <9E0E280F-1D62-4EC4-8E5C-900DCE0ED567@oracle.com> I need an official Review of this change. Thanks, /Staffan On 2 apr 2014, at 13:26, Staffan Larsen wrote: > We have had many intermittent failures in the com/sun/jdi tests recently. After much debugging it turns out that the cygwin version of ps sometimes misses some processes. Since the output of ps is used to determine if the tests should exit, this causes some problems? I suspect a recent update to cygwin, but haven?t been able to confirm that. > > This change stops using ps on cygwin and instead uses the builtin tasklist program on windows. > > I have also removed some old supporting code for Windows 98 (!). > > Tested by running the jdi tests over and over locally many times and also in jprt. > > webrev: http://cr.openjdk.java.net/~sla/8038963/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038963 > > Thanks, > /Staffan From yekaterina.kantserova at oracle.com Mon Apr 7 06:59:42 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Sun, 6 Apr 2014 23:59:42 -0700 (PDT) Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. Message-ID: Hi David, The tests start a couple of external processes and have a procedure of destroying them if something unexpected happens. But when JVM crashes in the middle of the execution this procedure is useless and processes are left on servers. It should be up to framework to do clean-up. Unfortunately the JTreg framework has no mechanism of removing process trees today. But it has been discussed a lot and hopefully will be implemented in the nearest future. Best regards, Katja ----- Original Message ----- From: david.holmes at oracle.com To: yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net Sent: Monday, April 7, 2014 2:57:09 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. Hi Katja, I don't object to making the test more resilient, but I do have to wonder why we have multiple jstatd processes as that would seem to indicate another problem that needs addressing. David On 4/04/2014 11:25 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8031766/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8031766 > > The bug is not visible. But short summary is as follows. > sun/tools/jstatd/TestJstatdPort.java, TestJstatdPortAndServer.java, > TestJstatdServer.java have been failing because they expect only one > jstad process running. I've added a unique identifier for the jstad > process tests start. So the tests will no more care about how many other > jstad processes are running. > > Thanks, > Katja From serguei.spitsyn at oracle.com Mon Apr 7 07:05:57 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 07 Apr 2014 00:05:57 -0700 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> <533514F4.8050906@oracle.com> <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com> Message-ID: <53424E55.1020907@oracle.com> On 4/3/14 2:31 AM, Staffan Larsen wrote: > Thanks Serguei, > > I don?t think it is necessary to initialize ?end? since strtol will always set it. Ok. > > I still need an official Reviewer for this change. I'm not an official reviewer yet. Thanks, Serguei > > Thanks, > /Staffan > > On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote: > >> On 3/27/14 12:55 AM, Staffan Larsen wrote: >>> Here is an updated webrev which incorporates Dmitry?s feedback: >>> >>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/ >> >> It looks good. >> The only suggestion is to initialize the 'end': >> char* end; >> >> Not sure what value is better to use for initialization. >> Probably, end = probe would work Ok. >> >> Thanks, >> Serguei >>> Thanks, >>> /Staffan >>> >>> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: >>> >>>> Staffan, >>>> >>>>> Yes, that will find problems when trying to convert something like >>>>> ?bla?. It will not capture the case where the input string is a too >>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>>> both cases it looks like we need something like: >>>>> errno = 0; >>>>> char* end; >>>>> int probe_typess = (int) strtol(probe, &end, 10); >>>>> if (end == probe || errno) { >>>>> return JNI_ERR; >>>>> } >>>> As probe_typess is positive and you are converting long to int >>>> It's be better to check value boundaries explicitly: >>>> >>>> char* end; >>>> long ptl = strtol(probe, &end, 10); >>>> if (end == probe || ptl < 0 || ptl > MAX_INT) { >>>> return JNI_ERR; >>>> } >>>> >>>> int probe_typess = (int) ptl; >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-25 17:35, Staffan Larsen wrote: >>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff >>>>> wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> strtol() sets errno in two cases - >>>>>> >>>>>> ERANGE if supplied value is less then LONG_MIN or greater than >>>>>> LONG_MAX EINVAL if supplied base is not supported. >>>>>> >>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not >>>>>> be set. So I'm not sure that check for errno has any value here. >>>>>> >>>>>> One of possible way to check that supplied value is convertible to >>>>>> long is >>>>>> >>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>>>>> probe) { // we can't convert supplied value return JNI_ERR; } >>>>> Yes, that will find problems when trying to convert something like >>>>> ?bla?. It will not capture the case where the input string is a too >>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>>>> both cases it looks like we need something like: >>>>> >>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >>>>> 10); if (end == probe || errno) { return JNI_ERR; } >>>>> >>>>> >>>>> /Staffan >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>>>>> see if any errors occurred. The problem is that atoi() does not >>>>>>> set errno, so some old value of errno is checked which sometimes >>>>>>> causes the function to fail. >>>>>>> >>>>>>> The fix is to replace atoi() with strtol() which does set errno. >>>>>>> But errno is only set if an error occurred and not set to 0 in >>>>>>> case of success. Thus, I set errno to 0 before calling strtol() >>>>>>> and check the value afterwards. >>>>>>> >>>>>>> Verified with a JPRT run. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>>>>> >>>>>>> Thanks, /Staffan >>>>>>> >>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>>> Russia * I would love to change the world, but they won't give me >>>>>> the sources. >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Mon Apr 7 07:12:15 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 07 Apr 2014 00:12:15 -0700 Subject: Should we get rid of libnpt.so ? In-Reply-To: <60C36D53-0F77-412C-8B18-1D9880178AA7@oracle.com> References: <533EDDB1.2030307@oracle.com> <60C36D53-0F77-412C-8B18-1D9880178AA7@oracle.com> Message-ID: <53424FCF.8090502@oracle.com> On 4/6/14 11:13 PM, Staffan Larsen wrote: > Curious: What does NPT stand for? This is from Kelly: > The original purpose of this library was to provide some generic*native platform tools* > for dealing with things that will happen BEFORE the JVM is started and Java code can be called. Thanks, Serguei > > On 4 apr 2014, at 18:52, Kelly O'Hair wrote: > >> Just as background information... >> >> The serviceability team should do what they think is right here, I'll just provide some history... ;) >> >> The original purpose of this library was to provide some generic native platform tools for dealing with things that will happen BEFORE the JVM is started and Java code can be called. >> >> This was necessary for JVM agents (hprof, debugger backend, jvmti demo agents) and any native code that was executed before the JVM had gotten off the ground. >> Doing arbitrary character encoding conversions to/from the various flavors of UTF-8 is a nightmare outside Java. >> And since the characters typed in on a java commandline is in the OS's default platform encoding, and not in UTF-8, they need to be converted. >> Since this native code was not part of hotspot, and was written in C, using the hotspot functionality for this was not possible at the time. >> >> This logic was isolated because it was so OS specific and ugly, and we (maybe just me) had visions of needed more in this library, and that maybe we could limit the ifdef-mania to this library rather than scatter the same ifdef-mania all over the rest of the JDK native code that lives outside hotspot. >> So it seemed natural to isolate it as a separate little library that could be unit tested on it's own. >> >> It's extremely likely that it could be trimmed down, and as more and more OS default encodings become UTF-8, maybe it' will eventually become obsolete. >> >> Hope this helps. >> >> -kto >> >> On Apr 4, 2014, at 9:28 AM, Dmitry Samersoff wrote: >> >>> Hi Everybody, >>> >>> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >>> related functions. On a brief investigation it looks like most of these >>> functions are not used. Six functions below called one time each from >>> share/back/* and hprof_init.c [2] >>> >>> Should I file a CR to have it cleaned up - remove npt library as a >>> separate entity and move few utf functions that really used to place >>> where it actually called. >>> >>> >>> [1] Library sources location >>> >>> src/share/npt >>> src/solaris/npt >>> src/windows/npt >>> >>> [2] Library usage >>> >>> src/share/back/transport.c: >>> >>> utf8FromPlatform >>> utf8ToPlatform >>> >>> src/share/back/inStream.c: >>> >>> utf8sToUtf8m >>> utf8sToUtf8mLength >>> >>> src/share/back/outStream.c: >>> >>> utf8mToUtf8s >>> utf8mToUtf8sLength >>> >>> >>> src/share/demo/jvmti/hprof/hprof_init.c >>> >>> utf8ToPlatform >>> >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Mon Apr 7 08:49:20 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 7 Apr 2014 01:49:20 -0700 (PDT) Subject: Testlibrary changes need their own changesets Message-ID: <2b65a081-b79b-4ee6-b3d2-d4c501cbb64f@default> Since the testlibrary exists even in the JDK part I would like to add the Serviceability and Corelibs teams to this discussion. Thanks, Katja ----- Original Message ----- From: david.holmes at oracle.com To: hotspot-dev at openjdk.java.net Sent: Monday, April 7, 2014 3:50:14 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Testlibrary changes need their own changesets Unfortunately enhancements to the testlibrary infrastructure code tend to be done in conjunction with the changes to the tests (and sometimes corresponding VM changes) that need the enhancement. This makes it very difficult (sometimes impossible) to backport updates to the testlibrary. Can I suggest that all updates to the testlibrary classes be done under their own CR (they can still be reviewed alongside the main changes) and committed into a distinct changeset so that they can be readily backported. Thanks, David From jaroslav.bachorik at oracle.com Mon Apr 7 10:46:03 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Apr 2014 12:46:03 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> Message-ID: <534281EB.1090102@oracle.com> Hi, Sorry for the noise but I need to get the fix re-reviewed. Due to the way jtreg cooperates with TestNG when runnning in agentvm I can not use package private methods or constructor or fields. The updated patch - http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the JInfo constructor a private one and removes the package private getters. The test is using reflection to create new instances of JInfo and to assert its state. Thanks, -JB- From staffan.larsen at oracle.com Mon Apr 7 10:55:29 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 12:55:29 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534281EB.1090102@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> Message-ID: Looks good, but should we maybe have a comment in JInfo.java about the structure being needed for testing? Just looking at the code this is not obvious. /Staffan On 7 apr 2014, at 12:46, Jaroslav Bachorik wrote: > Hi, > > Sorry for the noise but I need to get the fix re-reviewed. > Due to the way jtreg cooperates with TestNG when runnning in agentvm I can not use package private methods or constructor or fields. > > The updated patch - http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the JInfo constructor a private one and removes the package private getters. The test is using reflection to create new instances of JInfo and to assert its state. > > Thanks, > > -JB- From shanliang.jiang at oracle.com Mon Apr 7 12:10:54 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 07 Apr 2014 14:10:54 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534281EB.1090102@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> Message-ID: <534295CE.70603@oracle.com> Jaroslav, Is it necessary to add "ValidationException"? Could we change the constructor JInfo to: private static boolean validateArgs(String[] args); the method returns false if the args are illegal, or throw an IllegalArgumentException and declare the variables "args" and "useSA" as static too, Shanliang Jaroslav Bachorik wrote: > Hi, > > Sorry for the noise but I need to get the fix re-reviewed. > Due to the way jtreg cooperates with TestNG when runnning in agentvm I > can not use package private methods or constructor or fields. > > The updated patch - > http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the > JInfo constructor a private one and removes the package private > getters. The test is using reflection to create new instances of JInfo > and to assert its state. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Apr 7 12:22:21 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Apr 2014 14:22:21 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534295CE.70603@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> Message-ID: <5342987D.1020704@oracle.com> On 7.4.2014 14:10, shanliang wrote: > Jaroslav, > > Is it necessary to add "ValidationException"? Well, for the implementation when the validation is performed at the moment a new instance of JInfo is being created it is necessary. > > Could we change the constructor JInfo to: > private static boolean validateArgs(String[] args); > the method returns false if the args are illegal, or throw an > IllegalArgumentException > > and declare the variables "args" and "useSA" as static too, Yes, of course this could be changed like this. What would be the expected benefits? -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> Hi, >> >> Sorry for the noise but I need to get the fix re-reviewed. >> Due to the way jtreg cooperates with TestNG when runnning in agentvm I >> can not use package private methods or constructor or fields. >> >> The updated patch - >> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >> JInfo constructor a private one and removes the package private >> getters. The test is using reflection to create new instances of JInfo >> and to assert its state. >> >> Thanks, >> >> -JB- > From shanliang.jiang at oracle.com Mon Apr 7 12:23:40 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 07 Apr 2014 14:23:40 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534295CE.70603@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> Message-ID: <534298CC.2050608@oracle.com> shanliang wrote: > Jaroslav, > > Is it necessary to add "ValidationException"? > > Could we change the constructor JInfo to: > private static boolean validateArgs(String[] args); > the method returns false if the args are illegal, or throw an > IllegalArgumentException > > and declare the variables "args" and "useSA" as static too, Static variables may have problem if called with multi-thread, but we still could do: private static Map validate(String[] args) throws IllegalArgumentException; the return map contains args(String[]) and useSA(boolean). Or put "USE_SA" as a new arg into the args list, then the method becomes: private static String[] validate(String[] args) throws IllegalArgumentException; Shanliang > > Shanliang > > Jaroslav Bachorik wrote: >> Hi, >> >> Sorry for the noise but I need to get the fix re-reviewed. >> Due to the way jtreg cooperates with TestNG when runnning in agentvm >> I can not use package private methods or constructor or fields. >> >> The updated patch - >> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >> JInfo constructor a private one and removes the package private >> getters. The test is using reflection to create new instances of >> JInfo and to assert its state. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Mon Apr 7 12:25:52 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Apr 2014 14:25:52 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534298CC.2050608@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> <534298CC.2050608@oracle.com> Message-ID: <53429950.5000806@oracle.com> On 7.4.2014 14:23, shanliang wrote: > shanliang wrote: >> Jaroslav, >> >> Is it necessary to add "ValidationException"? >> >> Could we change the constructor JInfo to: >> private static boolean validateArgs(String[] args); >> the method returns false if the args are illegal, or throw an >> IllegalArgumentException >> >> and declare the variables "args" and "useSA" as static too, > Static variables may have problem if called with multi-thread, but we > still could do: > > private static Map validate(String[] args) throws > IllegalArgumentException; > > the return map contains args(String[]) and useSA(boolean). ... or just keep them as instance variables. -JB- > > Or put "USE_SA" as a new arg into the args list, then the method becomes: > private static String[] validate(String[] args) throws > IllegalArgumentException; > > Shanliang > >> >> Shanliang >> >> Jaroslav Bachorik wrote: >>> Hi, >>> >>> Sorry for the noise but I need to get the fix re-reviewed. >>> Due to the way jtreg cooperates with TestNG when runnning in agentvm >>> I can not use package private methods or constructor or fields. >>> >>> The updated patch - >>> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >>> JInfo constructor a private one and removes the package private >>> getters. The test is using reflection to create new instances of >>> JInfo and to assert its state. >>> >>> Thanks, >>> >>> -JB- >> > From shanliang.jiang at oracle.com Mon Apr 7 12:34:53 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 07 Apr 2014 14:34:53 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <5342987D.1020704@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> <5342987D.1020704@oracle.com> Message-ID: <53429B6D.2080302@oracle.com> Jaroslav Bachorik wrote: > On 7.4.2014 14:10, shanliang wrote: >> Jaroslav, >> >> Is it necessary to add "ValidationException"? > Well, for the implementation when the validation is performed at the > moment a new instance of JInfo is being created it is necessary. Could not use an existing Exception? like IllegalArgumentException? I did not see your constructor throw a same exception. > >> >> Could we change the constructor JInfo to: >> private static boolean validateArgs(String[] args); >> the method returns false if the args are illegal, or throw an >> IllegalArgumentException >> >> and declare the variables "args" and "useSA" as static too, > > Yes, of course this could be changed like this. What would be the > expected benefits? The code will be simpler with one less inner class Shanliang > > -JB- > >> >> Shanliang >> >> Jaroslav Bachorik wrote: >>> Hi, >>> >>> Sorry for the noise but I need to get the fix re-reviewed. >>> Due to the way jtreg cooperates with TestNG when runnning in agentvm I >>> can not use package private methods or constructor or fields. >>> >>> The updated patch - >>> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >>> JInfo constructor a private one and removes the package private >>> getters. The test is using reflection to create new instances of JInfo >>> and to assert its state. >>> >>> Thanks, >>> >>> -JB- >> > From dmitry.samersoff at oracle.com Mon Apr 7 12:56:09 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Apr 2014 16:56:09 +0400 Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior Message-ID: <5342A069.3000205@oracle.com> Hi Everybody, Please review the patch http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ it's based on the patch contributed by Carlos Santos (see CR) and all credentials belong to him. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Apr 7 13:28:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Apr 2014 17:28:10 +0400 Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> References: <5342A069.3000205@oracle.com> <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> Message-ID: <5342A7EA.2040007@oracle.com> Carlos, I'd droppend changes in libproc_impl.c as it seems to be not related to prelink issue. PS: (from proposed patch) libproc_impl.c : + if (namelen >= sizeof(newlib->name)) { sizeof(newlib->name) is PATH_MAX + NAME_MAX Are you able to reproduce the issue with too long library name? if yes - I'll file the separate CR. -Dmitry On 2014-04-07 17:16, Carlos Santos wrote: > ----- Original Message ----- >> Hi Everybody, >> >> Please review the patch >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ > > The fix in agent/src/os/linux/libproc_impl.c contained in my original patch is missing. Was it included in a separate patch? > > Carlos Santos (casantos) > Senior *Software* Maintenance Engineer > (no, I'm not going to fix your roof) > Red Hat, Inc > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yekaterina.kantserova at oracle.com Mon Apr 7 14:31:33 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 07 Apr 2014 16:31:33 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <533EBBE1.1000806@oracle.com> References: <533EB2B5.9030909@oracle.com> <533EB466.5070404@oracle.com> <533EBB87.70009@oracle.com> <533EBBE1.1000806@oracle.com> Message-ID: <5342B6C5.7090107@oracle.com> Jaroslav, Staffan, thanks for the reviews! Jaroslav, could you please be my sponsor and apply the patch attached to this mail? Best regards, Katja On 04/04/2014 04:04 PM, Jaroslav Bachorik wrote: > No more comments. > > -JB- > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8031766.full.patch Type: text/x-patch Size: 2922 bytes Desc: not available URL: From dmitry.samersoff at oracle.com Mon Apr 7 14:54:29 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Apr 2014 18:54:29 +0400 Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <861501320.367137.1396878397993.JavaMail.zimbra@redhat.com> References: <5342A069.3000205@oracle.com> <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> <5342A7EA.2040007@oracle.com> <861501320.367137.1396878397993.JavaMail.zimbra@redhat.com> Message-ID: <5342BC25.8050600@oracle.com> Carlos, I might be missing something. Sorry about that. Looking at openjdk7 code http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/9b0ca45cd756/agent/src/os/linux/libproc_impl.c newlib->base is unconditionally initialized at ll. 157 so if we move it after symtab initialization at ll. 181 it shouldn't change things. -Dmitry On 2014-04-07 17:46, Carlos Santos wrote: > Dmitry, > > The main problem in libproc_impl.c is that newlib->base is left uninitialized. > > The check for the name length is just a safety measure. We can live without it but I'd prefer to avoid the risk. > > Carlos Santos (casantos) > Senior *Software* Maintenance Engineer > (no, I'm not going to fix your roof) > Red Hat, Inc > > > ----- Original Message ----- >> Carlos, >> >> I'd droppend changes in libproc_impl.c as it seems to be not related to >> prelink issue. >> >> PS: >> >> (from proposed patch) libproc_impl.c : >> + if (namelen >= sizeof(newlib->name)) { >> >> sizeof(newlib->name) is PATH_MAX + NAME_MAX >> >> Are you able to reproduce the issue with too long library name? if yes - >> I'll file the separate CR. >> >> -Dmitry >> >> On 2014-04-07 17:16, Carlos Santos wrote: >>> ----- Original Message ----- >>>> Hi Everybody, >>>> >>>> Please review the patch >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>> >>> The fix in agent/src/os/linux/libproc_impl.c contained in my original patch >>> is missing. Was it included in a separate patch? >>> >>> Carlos Santos (casantos) >>> Senior *Software* Maintenance Engineer >>> (no, I'm not going to fix your roof) >>> Red Hat, Inc >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Mon Apr 7 14:59:19 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Apr 2014 16:59:19 +0200 Subject: RFR: 8031766: jstatd nightly tests failing with Expected one jstatd process, got 2. Test will be canceled. In-Reply-To: <5342B6C5.7090107@oracle.com> References: <533EB2B5.9030909@oracle.com> <533EB466.5070404@oracle.com> <533EBB87.70009@oracle.com> <533EBBE1.1000806@oracle.com> <5342B6C5.7090107@oracle.com> Message-ID: <5342BD47.7060204@oracle.com> On 7.4.2014 16:31, Yekaterina Kantserova wrote: > Jaroslav, Staffan, thanks for the reviews! > > Jaroslav, could you please be my sponsor and apply the patch attached to > this mail? Yep, will do that. -JB- > > Best regards, > Katja > > > > On 04/04/2014 04:04 PM, Jaroslav Bachorik wrote: >> No more comments. >> >> -JB- >> > From kellyohair at gmail.com Mon Apr 7 15:59:24 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Mon, 7 Apr 2014 08:59:24 -0700 Subject: Should we get rid of libnpt.so ? In-Reply-To: <53424FCF.8090502@oracle.com> References: <533EDDB1.2030307@oracle.com> <60C36D53-0F77-412C-8B18-1D9880178AA7@oracle.com> <53424FCF.8090502@oracle.com> Message-ID: Might have been native platform toolkit... ;) -kto On Apr 7, 2014, at 12:12 AM, serguei.spitsyn at oracle.com wrote: > On 4/6/14 11:13 PM, Staffan Larsen wrote: >> Curious: What does NPT stand for? > > This is from Kelly: > > > The original purpose of this library was to provide some generic native platform tools > > for dealing with things that will happen BEFORE the JVM is started and Java code can be called. > > Thanks, > Serguei > >> >> On 4 apr 2014, at 18:52, Kelly O'Hair wrote: >> >>> Just as background information... >>> >>> The serviceability team should do what they think is right here, I'll just provide some history... ;) >>> >>> The original purpose of this library was to provide some generic native platform tools for dealing with things that will happen BEFORE the JVM is started and Java code can be called. >>> >>> This was necessary for JVM agents (hprof, debugger backend, jvmti demo agents) and any native code that was executed before the JVM had gotten off the ground. >>> Doing arbitrary character encoding conversions to/from the various flavors of UTF-8 is a nightmare outside Java. >>> And since the characters typed in on a java commandline is in the OS's default platform encoding, and not in UTF-8, they need to be converted. >>> Since this native code was not part of hotspot, and was written in C, using the hotspot functionality for this was not possible at the time. >>> >>> This logic was isolated because it was so OS specific and ugly, and we (maybe just me) had visions of needed more in this library, and that maybe we could limit the ifdef-mania to this library rather than scatter the same ifdef-mania all over the rest of the JDK native code that lives outside hotspot. >>> So it seemed natural to isolate it as a separate little library that could be unit tested on it's own. >>> >>> It's extremely likely that it could be trimmed down, and as more and more OS default encodings become UTF-8, maybe it' will eventually become obsolete. >>> >>> Hope this helps. >>> >>> -kto >>> >>> On Apr 4, 2014, at 9:28 AM, Dmitry Samersoff wrote: >>> >>>> Hi Everybody, >>>> >>>> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >>>> related functions. On a brief investigation it looks like most of these >>>> functions are not used. Six functions below called one time each from >>>> share/back/* and hprof_init.c [2] >>>> >>>> Should I file a CR to have it cleaned up - remove npt library as a >>>> separate entity and move few utf functions that really used to place >>>> where it actually called. >>>> >>>> >>>> [1] Library sources location >>>> >>>> src/share/npt >>>> src/solaris/npt >>>> src/windows/npt >>>> >>>> [2] Library usage >>>> >>>> src/share/back/transport.c: >>>> >>>> utf8FromPlatform >>>> utf8ToPlatform >>>> >>>> src/share/back/inStream.c: >>>> >>>> utf8sToUtf8m >>>> utf8sToUtf8mLength >>>> >>>> src/share/back/outStream.c: >>>> >>>> utf8mToUtf8s >>>> utf8mToUtf8sLength >>>> >>>> >>>> src/share/demo/jvmti/hprof/hprof_init.c >>>> >>>> utf8ToPlatform >>>> >>>> >>>> -Dmitry >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kellyohair at gmail.com Mon Apr 7 16:07:30 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Mon, 7 Apr 2014 09:07:30 -0700 Subject: Should we get rid of libnpt.so ? In-Reply-To: <011B69CF-4FD6-4B66-9256-C981F28EA196@oracle.com> References: <533EDDB1.2030307@oracle.com> <011B69CF-4FD6-4B66-9256-C981F28EA196@oracle.com> Message-ID: <056CFF47-BF20-40BF-905E-07D18C7BDE4A@gmail.com> Keep in mind that there are 3 sets of sources for npt, share/npt, solaris/npt and windows/npt it is quite platform specific, using iconv libraries on solaris/linux, and multi/wide byte strangeness on windows. So it wasn't just the functionality that drove it into it's own library, the implementation of how you have to deal with utf8 in a native world made it ugly, and isolating it was the only way to put lipstick on this pig. You need to look at all the code before you start doing cut&paste on the source. -kto On Apr 6, 2014, at 11:16 AM, Staffan Larsen wrote: > It makes sense to have this code separated out. But I?m not sure it makes sense to compile it into a separate library. We could just as well compile in the necessary source files where needed. And if there are unused functions, I think they could be removed to decrease the maintenance burden. > > /Staffan > > On 4 apr 2014, at 18:28, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >> related functions. On a brief investigation it looks like most of these >> functions are not used. Six functions below called one time each from >> share/back/* and hprof_init.c [2] >> >> Should I file a CR to have it cleaned up - remove npt library as a >> separate entity and move few utf functions that really used to place >> where it actually called. >> >> >> [1] Library sources location >> >> src/share/npt >> src/solaris/npt >> src/windows/npt >> >> [2] Library usage >> >> src/share/back/transport.c: >> >> utf8FromPlatform >> utf8ToPlatform >> >> src/share/back/inStream.c: >> >> utf8sToUtf8m >> utf8sToUtf8mLength >> >> src/share/back/outStream.c: >> >> utf8mToUtf8s >> utf8mToUtf8sLength >> >> >> src/share/demo/jvmti/hprof/hprof_init.c >> >> utf8ToPlatform >> >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > From casantos at redhat.com Mon Apr 7 13:16:25 2014 From: casantos at redhat.com (Carlos Santos) Date: Mon, 7 Apr 2014 09:16:25 -0400 (EDT) Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <5342A069.3000205@oracle.com> References: <5342A069.3000205@oracle.com> Message-ID: <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Everybody, > > Please review the patch > > http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ The fix in agent/src/os/linux/libproc_impl.c contained in my original patch is missing. Was it included in a separate patch? Carlos Santos (casantos) Senior *Software* Maintenance Engineer (no, I'm not going to fix your roof) Red Hat, Inc From casantos at redhat.com Mon Apr 7 13:46:37 2014 From: casantos at redhat.com (Carlos Santos) Date: Mon, 7 Apr 2014 09:46:37 -0400 (EDT) Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <5342A7EA.2040007@oracle.com> References: <5342A069.3000205@oracle.com> <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> <5342A7EA.2040007@oracle.com> Message-ID: <861501320.367137.1396878397993.JavaMail.zimbra@redhat.com> Dmitry, The main problem in libproc_impl.c is that newlib->base is left uninitialized. The check for the name length is just a safety measure. We can live without it but I'd prefer to avoid the risk. Carlos Santos (casantos) Senior *Software* Maintenance Engineer (no, I'm not going to fix your roof) Red Hat, Inc ----- Original Message ----- > Carlos, > > I'd droppend changes in libproc_impl.c as it seems to be not related to > prelink issue. > > PS: > > (from proposed patch) libproc_impl.c : > + if (namelen >= sizeof(newlib->name)) { > > sizeof(newlib->name) is PATH_MAX + NAME_MAX > > Are you able to reproduce the issue with too long library name? if yes - > I'll file the separate CR. > > -Dmitry > > On 2014-04-07 17:16, Carlos Santos wrote: > > ----- Original Message ----- > >> Hi Everybody, > >> > >> Please review the patch > >> > >> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ > > > > The fix in agent/src/os/linux/libproc_impl.c contained in my original patch > > is missing. Was it included in a separate patch? > > > > Carlos Santos (casantos) > > Senior *Software* Maintenance Engineer > > (no, I'm not going to fix your roof) > > Red Hat, Inc > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From casantos at redhat.com Mon Apr 7 16:17:37 2014 From: casantos at redhat.com (Carlos Santos) Date: Mon, 7 Apr 2014 12:17:37 -0400 (EDT) Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <5342BC25.8050600@oracle.com> References: <5342A069.3000205@oracle.com> <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> <5342A7EA.2040007@oracle.com> <861501320.367137.1396878397993.JavaMail.zimbra@redhat.com> <5342BC25.8050600@oracle.com> Message-ID: <124004836.459954.1396887457405.JavaMail.zimbra@redhat.com> Dmitry, You are right. I got confused because a previous version of the patch incorrectly removed the assignment that existed in line 157, so I added it back later. Carlos Santos (casantos) Senior *Software* Maintenance Engineer (no, I'm not going to fix your roof) Red Hat, Inc ----- Original Message ----- > Carlos, > > I might be missing something. Sorry about that. > > Looking at openjdk7 code > > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/9b0ca45cd756/agent/src/os/linux/libproc_impl.c > > newlib->base is unconditionally initialized at ll. 157 > > so if we move it after symtab initialization at ll. 181 it shouldn't > change things. > > -Dmitry > > > On 2014-04-07 17:46, Carlos Santos wrote: > > Dmitry, > > > > The main problem in libproc_impl.c is that newlib->base is left > > uninitialized. > > > > The check for the name length is just a safety measure. We can live without > > it but I'd prefer to avoid the risk. > > > > Carlos Santos (casantos) > > Senior *Software* Maintenance Engineer > > (no, I'm not going to fix your roof) > > Red Hat, Inc > > > > > > ----- Original Message ----- > >> Carlos, > >> > >> I'd droppend changes in libproc_impl.c as it seems to be not related to > >> prelink issue. > >> > >> PS: > >> > >> (from proposed patch) libproc_impl.c : > >> + if (namelen >= sizeof(newlib->name)) { > >> > >> sizeof(newlib->name) is PATH_MAX + NAME_MAX > >> > >> Are you able to reproduce the issue with too long library name? if yes - > >> I'll file the separate CR. > >> > >> -Dmitry > >> > >> On 2014-04-07 17:16, Carlos Santos wrote: > >>> ----- Original Message ----- > >>>> Hi Everybody, > >>>> > >>>> Please review the patch > >>>> > >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ > >>> > >>> The fix in agent/src/os/linux/libproc_impl.c contained in my original > >>> patch > >>> is missing. Was it included in a separate patch? > >>> > >>> Carlos Santos (casantos) > >>> Senior *Software* Maintenance Engineer > >>> (no, I'm not going to fix your roof) > >>> Red Hat, Inc > >>> > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From dmitry.samersoff at oracle.com Mon Apr 7 16:47:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Apr 2014 20:47:53 +0400 Subject: RFR(S): JDK-8038392 Generating prelink cache breaks JAVA 'jinfo' utility normal behavior In-Reply-To: <124004836.459954.1396887457405.JavaMail.zimbra@redhat.com> References: <5342A069.3000205@oracle.com> <50735227.341197.1396876585958.JavaMail.zimbra@redhat.com> <5342A7EA.2040007@oracle.com> <861501320.367137.1396878397993.JavaMail.zimbra@redhat.com> <5342BC25.8050600@oracle.com> <124004836.459954.1396887457405.JavaMail.zimbra@redhat.com> Message-ID: <5342D6B9.8060801@oracle.com> Carlos, Are you OK with proposed changes? -Dmitry On 2014-04-07 20:17, Carlos Santos wrote: > Dmitry, > > You are right. I got confused because a previous version of the patch incorrectly removed the assignment that existed in line 157, so I added it back later. > > Carlos Santos (casantos) > Senior *Software* Maintenance Engineer > (no, I'm not going to fix your roof) > Red Hat, Inc > > > ----- Original Message ----- >> Carlos, >> >> I might be missing something. Sorry about that. >> >> Looking at openjdk7 code >> >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/9b0ca45cd756/agent/src/os/linux/libproc_impl.c >> >> newlib->base is unconditionally initialized at ll. 157 >> >> so if we move it after symtab initialization at ll. 181 it shouldn't >> change things. >> >> -Dmitry >> >> >> On 2014-04-07 17:46, Carlos Santos wrote: >>> Dmitry, >>> >>> The main problem in libproc_impl.c is that newlib->base is left >>> uninitialized. >>> >>> The check for the name length is just a safety measure. We can live without >>> it but I'd prefer to avoid the risk. >>> >>> Carlos Santos (casantos) >>> Senior *Software* Maintenance Engineer >>> (no, I'm not going to fix your roof) >>> Red Hat, Inc >>> >>> >>> ----- Original Message ----- >>>> Carlos, >>>> >>>> I'd droppend changes in libproc_impl.c as it seems to be not related to >>>> prelink issue. >>>> >>>> PS: >>>> >>>> (from proposed patch) libproc_impl.c : >>>> + if (namelen >= sizeof(newlib->name)) { >>>> >>>> sizeof(newlib->name) is PATH_MAX + NAME_MAX >>>> >>>> Are you able to reproduce the issue with too long library name? if yes - >>>> I'll file the separate CR. >>>> >>>> -Dmitry >>>> >>>> On 2014-04-07 17:16, Carlos Santos wrote: >>>>> ----- Original Message ----- >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the patch >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8038392/webrev.02/ >>>>> >>>>> The fix in agent/src/os/linux/libproc_impl.c contained in my original >>>>> patch >>>>> is missing. Was it included in a separate patch? >>>>> >>>>> Carlos Santos (casantos) >>>>> Senior *Software* Maintenance Engineer >>>>> (no, I'm not going to fix your roof) >>>>> Red Hat, Inc >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Apr 7 17:05:20 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Apr 2014 21:05:20 +0400 Subject: Should we get rid of libnpt.so ? In-Reply-To: <056CFF47-BF20-40BF-905E-07D18C7BDE4A@gmail.com> References: <533EDDB1.2030307@oracle.com> <011B69CF-4FD6-4B66-9256-C981F28EA196@oracle.com> <056CFF47-BF20-40BF-905E-07D18C7BDE4A@gmail.com> Message-ID: <5342DAD0.5010608@oracle.com> Kelly, Thank you for the reminder. I'd checked it before posting this letter - platform specific code is used in two places: 1) in src/share/back/transport.c the use of utf-8 here is not consistent e.g. ll. 621 /* Construct complete command line (all in UTF-8) */ commandLine = jvmtiAllocate((int)strlen(command) + (int)strlen(name) + (int)strlen(address) + 3); and should be carefully evaluated. 2) in src/share/demo/jvmti/hprof/hprof_init.c we can put all platform depended code under #ifdef windows right there, without extra layer of abstraction. -Dmitry On 2014-04-07 20:07, Kelly O'Hair wrote: > Keep in mind that there are 3 sets of sources for npt, share/npt, solaris/npt and windows/npt > it is quite platform specific, using iconv libraries on solaris/linux, and multi/wide byte strangeness on windows. > > So it wasn't just the functionality that drove it into it's own library, the implementation of how you have to deal with utf8 in a native world made it ugly, and isolating it was the only way to put lipstick on this pig. > > You need to look at all the code before you start doing cut&paste on the source. > > -kto > > On Apr 6, 2014, at 11:16 AM, Staffan Larsen wrote: > >> It makes sense to have this code separated out. But I?m not sure it makes sense to compile it into a separate library. We could just as well compile in the necessary source files where needed. And if there are unused functions, I think they could be removed to decrease the maintenance burden. >> >> /Staffan >> >> On 4 apr 2014, at 18:28, Dmitry Samersoff wrote: >> >>> Hi Everybody, >>> >>> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >>> related functions. On a brief investigation it looks like most of these >>> functions are not used. Six functions below called one time each from >>> share/back/* and hprof_init.c [2] >>> >>> Should I file a CR to have it cleaned up - remove npt library as a >>> separate entity and move few utf functions that really used to place >>> where it actually called. >>> >>> >>> [1] Library sources location >>> >>> src/share/npt >>> src/solaris/npt >>> src/windows/npt >>> >>> [2] Library usage >>> >>> src/share/back/transport.c: >>> >>> utf8FromPlatform >>> utf8ToPlatform >>> >>> src/share/back/inStream.c: >>> >>> utf8sToUtf8m >>> utf8sToUtf8mLength >>> >>> src/share/back/outStream.c: >>> >>> utf8mToUtf8s >>> utf8mToUtf8sLength >>> >>> >>> src/share/demo/jvmti/hprof/hprof_init.c >>> >>> utf8ToPlatform >>> >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kellyohair at gmail.com Mon Apr 7 17:14:47 2014 From: kellyohair at gmail.com (Kelly O'Hair) Date: Mon, 7 Apr 2014 10:14:47 -0700 Subject: Should we get rid of libnpt.so ? In-Reply-To: <5342DAD0.5010608@oracle.com> References: <533EDDB1.2030307@oracle.com> <011B69CF-4FD6-4B66-9256-C981F28EA196@oracle.com> <056CFF47-BF20-40BF-905E-07D18C7BDE4A@gmail.com> <5342DAD0.5010608@oracle.com> Message-ID: <26257311-07AC-4606-A134-A314A34C9B0F@gmail.com> I thought the debugger backend too, you might check src/share/back, inside util.h and debugInit.h Grep for gdata->npt But I've been away from the code for a long time, so my knowledge might be dusty. -kto On Apr 7, 2014, at 10:05 AM, Dmitry Samersoff wrote: > Kelly, > > Thank you for the reminder. > > I'd checked it before posting this letter - platform specific code is > used in two places: > > 1) > in src/share/back/transport.c > > the use of utf-8 here is not consistent e.g. > > ll. 621 > > /* Construct complete command line (all in UTF-8) */ > commandLine = jvmtiAllocate((int)strlen(command) + > (int)strlen(name) + > (int)strlen(address) + 3); > > > and should be carefully evaluated. > > 2) > in src/share/demo/jvmti/hprof/hprof_init.c > > we can put all platform depended code under #ifdef windows right there, > without extra layer of abstraction. > > > -Dmitry > > > > On 2014-04-07 20:07, Kelly O'Hair wrote: >> Keep in mind that there are 3 sets of sources for npt, share/npt, solaris/npt and windows/npt >> it is quite platform specific, using iconv libraries on solaris/linux, and multi/wide byte strangeness on windows. >> >> So it wasn't just the functionality that drove it into it's own library, the implementation of how you have to deal with utf8 in a native world made it ugly, and isolating it was the only way to put lipstick on this pig. >> >> You need to look at all the code before you start doing cut&paste on the source. >> >> -kto >> >> On Apr 6, 2014, at 11:16 AM, Staffan Larsen wrote: >> >>> It makes sense to have this code separated out. But I?m not sure it makes sense to compile it into a separate library. We could just as well compile in the necessary source files where needed. And if there are unused functions, I think they could be removed to decrease the maintenance burden. >>> >>> /Staffan >>> >>> On 4 apr 2014, at 18:28, Dmitry Samersoff wrote: >>> >>>> Hi Everybody, >>>> >>>> We have an libnpt.so[1] in JDK. This library contains bunch of UTF >>>> related functions. On a brief investigation it looks like most of these >>>> functions are not used. Six functions below called one time each from >>>> share/back/* and hprof_init.c [2] >>>> >>>> Should I file a CR to have it cleaned up - remove npt library as a >>>> separate entity and move few utf functions that really used to place >>>> where it actually called. >>>> >>>> >>>> [1] Library sources location >>>> >>>> src/share/npt >>>> src/solaris/npt >>>> src/windows/npt >>>> >>>> [2] Library usage >>>> >>>> src/share/back/transport.c: >>>> >>>> utf8FromPlatform >>>> utf8ToPlatform >>>> >>>> src/share/back/inStream.c: >>>> >>>> utf8sToUtf8m >>>> utf8sToUtf8mLength >>>> >>>> src/share/back/outStream.c: >>>> >>>> utf8mToUtf8s >>>> utf8mToUtf8sLength >>>> >>>> >>>> src/share/demo/jvmti/hprof/hprof_init.c >>>> >>>> utf8ToPlatform >>>> >>>> >>>> -Dmitry >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Apr 7 18:08:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 20:08:34 +0200 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms Message-ID: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan From staffan.larsen at oracle.com Mon Apr 7 19:19:03 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 21:19:03 +0200 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> Message-ID: <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen wrote: > > The problem here is that the code for finding local VMs is not looking for the data in the correct place. > > When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. > > (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. > > The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. > > (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). > > The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. > > Thanks, > /Staffan From staffan.larsen at oracle.com Tue Apr 8 09:04:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Apr 2014 11:04:09 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 Message-ID: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> This test causes exceptions that looks like this: java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:259) at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) at TraceJFrame.main(TraceJFrame.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) at java.lang.Thread.run(Thread.java:744) The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. Please review the fix below, Thanks, /Staffan diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java --- a/test/demo/jvmti/mtrace/TraceJFrame.java +++ b/test/demo/jvmti/mtrace/TraceJFrame.java @@ -36,7 +36,7 @@ public class TraceJFrame { public static void main(String args[]) throws Exception { - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { + if (GraphicsEnvironment.isHeadless()) { System.out.println("JFrame test was skipped due to headless mode"); } else { DemoRun demo; From jaroslav.bachorik at oracle.com Tue Apr 8 11:31:15 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 08 Apr 2014 13:31:15 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <53429950.5000806@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> <534298CC.2050608@oracle.com> <53429950.5000806@oracle.com> Message-ID: <5343DE03.7060904@oracle.com> On 7.4.2014 14:25, Jaroslav Bachorik wrote: > On 7.4.2014 14:23, shanliang wrote: >> shanliang wrote: >>> Jaroslav, >>> >>> Is it necessary to add "ValidationException"? Replaced the custom ValidationException with IllegalArgumentException() to remove an unnecessary inner class. http://cr.openjdk.java.net/~jbachorik/8039080/webrev.02 -JB- >>> >>> Could we change the constructor JInfo to: >>> private static boolean validateArgs(String[] args); >>> the method returns false if the args are illegal, or throw an >>> IllegalArgumentException >>> >>> and declare the variables "args" and "useSA" as static too, >> Static variables may have problem if called with multi-thread, but we >> still could do: >> >> private static Map validate(String[] args) throws >> IllegalArgumentException; >> >> the return map contains args(String[]) and useSA(boolean). > > ... or just keep them as instance variables. > > -JB- > >> >> Or put "USE_SA" as a new arg into the args list, then the method becomes: >> private static String[] validate(String[] args) throws >> IllegalArgumentException; >> >> Shanliang >> >>> >>> Shanliang >>> >>> Jaroslav Bachorik wrote: >>>> Hi, >>>> >>>> Sorry for the noise but I need to get the fix re-reviewed. >>>> Due to the way jtreg cooperates with TestNG when runnning in agentvm >>>> I can not use package private methods or constructor or fields. >>>> >>>> The updated patch - >>>> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >>>> JInfo constructor a private one and removes the package private >>>> getters. The test is using reflection to create new instances of >>>> JInfo and to assert its state. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From markus.gronlund at oracle.com Tue Apr 8 11:52:09 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 8 Apr 2014 04:52:09 -0700 (PDT) Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> Message-ID: <5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default> Hi Staffan, I think it looks good. Some minor things: src/share/native/sun/misc/VMSupport.c: line 60: There is some weirdness with the indentation. src/share/javavm/export/jvm.h (both Hotspot and JDK): You might want to consider co-locating 114 JNIEXPORT jstring JNICALL 115 JVM_GetTemporaryDirectory(JNIEnv *env); with 1334 JNIEXPORT jobject JNICALL 1335 JVM_InitAgentProperties(JNIEnv *env, jobject agent_props); Other than that I thinks good - thanks for fixing this. /Markus -----Original Message----- From: Staffan Larsen Sent: den 7 april 2014 21:19 To: Staffan Larsen Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen wrote: > > The problem here is that the code for finding local VMs is not looking for the data in the correct place. > > When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. > > (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. > > The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. > > (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). > > The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. > > Thanks, > /Staffan From staffan.larsen at oracle.com Tue Apr 8 12:07:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Apr 2014 14:07:18 +0200 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' Message-ID: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8038947 Thanks, /Staffan From jaroslav.bachorik at oracle.com Tue Apr 8 12:16:43 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 08 Apr 2014 14:16:43 +0200 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> Message-ID: <5343E8AB.8020601@oracle.com> Looks good! -JB- On 8.4.2014 14:07, Staffan Larsen wrote: > This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. > > This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. > > webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038947 > > Thanks, > /Staffan > From vladimir.kempik at oracle.com Tue Apr 8 15:30:56 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Tue, 08 Apr 2014 19:30:56 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c Message-ID: <53441630.2030506@oracle.com> Hello Please review this changeset: File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. bug: https://bugs.openjdk.java.net/browse/JDK-8039368 webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ Thanks, Vladimir. From staffan.larsen at oracle.com Tue Apr 8 14:21:47 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Apr 2014 16:21:47 +0200 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default> Message-ID: <1D53CA94-1A49-457E-A6F9-8B94A17B2B66@oracle.com> Thanks Marcus, I will fix those two issues before pushing. /Staffan On 8 apr 2014, at 13:52, Markus Gr?nlund wrote: > Hi Staffan, > > I think it looks good. > > Some minor things: > > src/share/native/sun/misc/VMSupport.c: > > line 60: There is some weirdness with the indentation. > > src/share/javavm/export/jvm.h (both Hotspot and JDK): > > You might want to consider co-locating > > 114 JNIEXPORT jstring JNICALL > 115 JVM_GetTemporaryDirectory(JNIEnv *env); > > with > > 1334 JNIEXPORT jobject JNICALL > 1335 JVM_InitAgentProperties(JNIEnv *env, jobject agent_props); > > > Other than that I thinks good - thanks for fixing this. > > /Markus > > > -----Original Message----- > From: Staffan Larsen > Sent: den 7 april 2014 21:19 > To: Staffan Larsen > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev > Subject: Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms > > And the links: > > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ > > Sorry about that, > /Staffan > > On 7 apr 2014, at 20:08, Staffan Larsen wrote: > >> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >> >> Thanks, >> /Staffan > From shanliang.jiang at oracle.com Tue Apr 8 20:10:10 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 08 Apr 2014 22:10:10 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> Message-ID: <534457A2.7080407@oracle.com> Hi Staffan, I did work on this bug and I thought the problem was from a bad DISPLAY setting (see my comments in the bug), I might miss something here. I looked at the class GraphicsEnvironment.java, getLocalGraphicsEnvironment() calls createGE(), and the latter has the following code: Class geCls; ...... ge = geCls.newInstance(); // long t1 = System.currentTimeMillis(); // System.out.println("GE creation took " + (t1-t0)+ "ms."); if (isHeadless()) { ge = new HeadlessGraphicsEnvironment(ge); } so we should not get an AWTError in case of headless, instead we get a HeadlessGraphicsEnvironment. Look at the following 2 methods: public static boolean isHeadless() { return getHeadlessProperty(); } public boolean isHeadlessInstance() { // By default (local graphics environment), simply check the // headless property. return getHeadlessProperty(); } it seems no difference to call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() and GraphicsEnvironment.isHeadless() yes better to cal the static method, but I am not sure that the direct call would fix the failure. Thanks, Shanliang Staffan Larsen wrote: > This test causes exceptions that looks like this: > > java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) > at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) > at java.security.AccessController.doPrivileged(Native Method) > at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:259) > at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) > at TraceJFrame.main(TraceJFrame.java:39) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) > > > The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. > > Please review the fix below, > > Thanks, > /Staffan > > > > diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java > --- a/test/demo/jvmti/mtrace/TraceJFrame.java > +++ b/test/demo/jvmti/mtrace/TraceJFrame.java > @@ -36,7 +36,7 @@ > > public class TraceJFrame { > public static void main(String args[]) throws Exception { > - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { > + if (GraphicsEnvironment.isHeadless()) { > System.out.println("JFrame test was skipped due to headless mode"); > } else { > DemoRun demo; From staffan.larsen at oracle.com Wed Apr 9 07:11:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 09:11:43 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <534457A2.7080407@oracle.com> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <534457A2.7080407@oracle.com> Message-ID: On 8 apr 2014, at 22:10, shanliang wrote: > Hi Staffan, > > I did work on this bug and I thought the problem was from a bad DISPLAY setting (see my comments in the bug), I might miss something here. > > I looked at the class GraphicsEnvironment.java, getLocalGraphicsEnvironment() calls createGE(), and the latter has the following code: > > Class geCls; > ...... > ge = geCls.newInstance(); > // long t1 = System.currentTimeMillis(); > // System.out.println("GE creation took " + (t1-t0)+ "ms."); > if (isHeadless()) { > ge = new HeadlessGraphicsEnvironment(ge); > } > > so we should not get an AWTError in case of headless, instead we get a HeadlessGraphicsEnvironment. If you look at the exception you can see that it is Class.forName() inside createGE() that throws the AWTError. We never get to the if(isHeadless()) statement. /Staffan > > Look at the following 2 methods: > > public static boolean isHeadless() { > return getHeadlessProperty(); > } > > public boolean isHeadlessInstance() { > // By default (local graphics environment), simply check the > // headless property. > return getHeadlessProperty(); > } > > it seems no difference to call > GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() > and > GraphicsEnvironment.isHeadless() > yes better to cal the static method, but I am not sure that the direct call would fix the failure. > > Thanks, > Shanliang > > > Staffan Larsen wrote: >> This test causes exceptions that looks like this: >> >> java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. >> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >> at java.security.AccessController.doPrivileged(Native Method) >> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:259) >> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >> at TraceJFrame.main(TraceJFrame.java:39) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >> at java.lang.Thread.run(Thread.java:744) >> >> >> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >> >> Please review the fix below, >> >> Thanks, >> /Staffan >> >> >> >> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >> @@ -36,7 +36,7 @@ >> >> public class TraceJFrame { >> public static void main(String args[]) throws Exception { >> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >> + if (GraphicsEnvironment.isHeadless()) { >> System.out.println("JFrame test was skipped due to headless mode"); >> } else { >> DemoRun demo; > From staffan.larsen at oracle.com Wed Apr 9 07:12:45 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 09:12:45 +0200 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <53441630.2030506@oracle.com> References: <53441630.2030506@oracle.com> Message-ID: <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> It?s been a very useful little test when changing the code in utf.c. Not sure why it has to be removed. /Staffan On 8 apr 2014, at 17:30, Vladimir Kempik wrote: > Hello > > Please review this changeset: > > File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. > > bug: https://bugs.openjdk.java.net/browse/JDK-8039368 > webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ > > Thanks, Vladimir. > > From shanliang.jiang at oracle.com Wed Apr 9 08:24:00 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Apr 2014 10:24:00 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <534457A2.7080407@oracle.com> Message-ID: <534503A0.4070300@oracle.com> Staffan Larsen wrote: > On 8 apr 2014, at 22:10, shanliang wrote: > > >> Hi Staffan, >> >> I did work on this bug and I thought the problem was from a bad DISPLAY setting (see my comments in the bug), I might miss something here. >> >> I looked at the class GraphicsEnvironment.java, getLocalGraphicsEnvironment() calls createGE(), and the latter has the following code: >> >> Class geCls; >> ...... >> ge = geCls.newInstance(); >> // long t1 = System.currentTimeMillis(); >> // System.out.println("GE creation took " + (t1-t0)+ "ms."); >> if (isHeadless()) { >> ge = new HeadlessGraphicsEnvironment(ge); >> } >> >> so we should not get an AWTError in case of headless, instead we get a HeadlessGraphicsEnvironment. >> > > If you look at the exception you can see that it is Class.forName() inside createGE() that throws the AWTError. We never get to the if(isHeadless()) statement. > Yes the exception was thrown before calling isHeadless(), does this mean a possible bug in the createGE implementation? should we check isHeadLess() before calling Class.forName() ? I repeated my old test, it did call GraphicsEnvironment.isHeadless(): ------------------------------- public class Test extends JFrame { public Test() { setTitle("Simple example"); setSize(300, 200); setLocationRelativeTo(null); setDefaultCloseOperation(EXIT_ON_CLOSE); } public static void main(String[] args) { if (GraphicsEnvironment.isHeadless()) { System.out.println("JFrame test was skipped due to headless mode"); System.exit(0); } SwingUtilities.invokeLater(new Runnable() { @Override public void run() { Test ex = new Test(); ex.setVisible(true); } }); } } ------------------------------- When running the test with X11 and a wrong DISPLAY, isHeadless did not return "true" to stop the test, the test continued and failed later with the exception: Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'toto' as the value of the DISPLAY variable. at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:110) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:190) at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) ... I am wondering that "isHeadLess" would not check a wrong DISPLAY, a quick look at the method implementation seems telling yes. Shanliang > /Staffan > > >> Look at the following 2 methods: >> >> public static boolean isHeadless() { >> return getHeadlessProperty(); >> } >> >> public boolean isHeadlessInstance() { >> // By default (local graphics environment), simply check the >> // headless property. >> return getHeadlessProperty(); >> } >> >> it seems no difference to call >> GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() >> and >> GraphicsEnvironment.isHeadless() >> yes better to cal the static method, but I am not sure that the direct call would fix the failure. >> >> Thanks, >> Shanliang >> >> >> Staffan Larsen wrote: >> >>> This test causes exceptions that looks like this: >>> >>> java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. >>> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >>> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >>> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >>> at java.lang.Class.forName0(Native Method) >>> at java.lang.Class.forName(Class.java:259) >>> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >>> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >>> at TraceJFrame.main(TraceJFrame.java:39) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:484) >>> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> >>> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >>> >>> Please review the fix below, >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >>> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >>> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >>> @@ -36,7 +36,7 @@ >>> >>> public class TraceJFrame { >>> public static void main(String args[]) throws Exception { >>> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >>> + if (GraphicsEnvironment.isHeadless()) { >>> System.out.println("JFrame test was skipped due to headless mode"); >>> } else { >>> DemoRun demo; >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Apr 9 08:40:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 10:40:42 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <534503A0.4070300@oracle.com> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <534457A2.7080407@oracle.com> <534503A0.4070300@oracle.com> Message-ID: On 9 apr 2014, at 10:24, shanliang wrote: > Staffan Larsen wrote: >> >> On 8 apr 2014, at 22:10, shanliang wrote: >> >> >>> Hi Staffan, >>> >>> I did work on this bug and I thought the problem was from a bad DISPLAY setting (see my comments in the bug), I might miss something here. >>> >>> I looked at the class GraphicsEnvironment.java, getLocalGraphicsEnvironment() calls createGE(), and the latter has the following code: >>> >>> Class geCls; >>> ...... >>> ge = geCls.newInstance(); >>> // long t1 = System.currentTimeMillis(); >>> // System.out.println("GE creation took " + (t1-t0)+ "ms."); >>> if (isHeadless()) { >>> ge = new HeadlessGraphicsEnvironment(ge); >>> } >>> >>> so we should not get an AWTError in case of headless, instead we get a HeadlessGraphicsEnvironment. >>> >> If you look at the exception you can see that it is Class.forName() inside createGE() that throws the AWTError. We never get to the if(isHeadless()) statement. >> > Yes the exception was thrown before calling isHeadless(), does this mean a possible bug in the createGE implementation? should we check isHeadLess() before calling Class.forName() ? > > I repeated my old test, it did call GraphicsEnvironment.isHeadless(): > ------------------------------- > public class Test extends JFrame { > public Test() { > setTitle("Simple example"); > setSize(300, 200); > setLocationRelativeTo(null); > setDefaultCloseOperation(EXIT_ON_CLOSE); > } > > public static void main(String[] args) { > if (GraphicsEnvironment.isHeadless()) { > System.out.println("JFrame test was skipped due to headless mode"); > > System.exit(0); > } > > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() { > Test ex = new Test(); > ex.setVisible(true); > } > }); > } > } > ------------------------------- > When running the test with X11 and a wrong DISPLAY, isHeadless did not return "true" to stop the test, the test continued and failed later with the exception: > Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'toto' as the value of the DISPLAY variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) > at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:190) > at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) > ... > > I am wondering that "isHeadLess" would not check a wrong DISPLAY, a quick look at the method implementation seems telling yes. It assumes that if you have DISPLAY set, that it is the correct value. Which is a fair assumption, I think. With my change, the test now passes in JPRT which it did not before. /Staffan > > Shanliang >> /Staffan >> >> >>> Look at the following 2 methods: >>> >>> public static boolean isHeadless() { >>> return getHeadlessProperty(); >>> } >>> >>> public boolean isHeadlessInstance() { >>> // By default (local graphics environment), simply check the >>> // headless property. >>> return getHeadlessProperty(); >>> } >>> >>> it seems no difference to call >>> GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() >>> and >>> GraphicsEnvironment.isHeadless() >>> yes better to cal the static method, but I am not sure that the direct call would fix the failure. >>> >>> Thanks, >>> Shanliang >>> >>> >>> Staffan Larsen wrote: >>> >>>> This test causes exceptions that looks like this: >>>> >>>> java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. >>>> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >>>> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >>>> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >>>> at java.lang.Class.forName0(Native Method) >>>> at java.lang.Class.forName(Class.java:259) >>>> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >>>> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >>>> at TraceJFrame.main(TraceJFrame.java:39) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:484) >>>> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> >>>> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >>>> >>>> Please review the fix below, >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >>>> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >>>> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >>>> @@ -36,7 +36,7 @@ >>>> >>>> public class TraceJFrame { >>>> public static void main(String args[]) throws Exception { >>>> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >>>> + if (GraphicsEnvironment.isHeadless()) { >>>> System.out.println("JFrame test was skipped due to headless mode"); >>>> } else { >>>> DemoRun demo; >>>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Wed Apr 9 08:56:46 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Apr 2014 10:56:46 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <534457A2.7080407@oracle.com> <534503A0.4070300@oracle.com> Message-ID: <53450B4E.6010608@oracle.com> Staffan Larsen wrote: > > On 9 apr 2014, at 10:24, shanliang > wrote: > >> Staffan Larsen wrote: >>> On 8 apr 2014, at 22:10, shanliang wrote: >>> >>> >>>> Hi Staffan, >>>> >>>> I did work on this bug and I thought the problem was from a bad DISPLAY setting (see my comments in the bug), I might miss something here. >>>> >>>> I looked at the class GraphicsEnvironment.java, getLocalGraphicsEnvironment() calls createGE(), and the latter has the following code: >>>> >>>> Class geCls; >>>> ...... >>>> ge = geCls.newInstance(); >>>> // long t1 = System.currentTimeMillis(); >>>> // System.out.println("GE creation took " + (t1-t0)+ "ms."); >>>> if (isHeadless()) { >>>> ge = new HeadlessGraphicsEnvironment(ge); >>>> } >>>> >>>> so we should not get an AWTError in case of headless, instead we get a HeadlessGraphicsEnvironment. >>>> >>> If you look at the exception you can see that it is Class.forName() inside createGE() that throws the AWTError. We never get to the if(isHeadless()) statement. >>> >> Yes the exception was thrown before calling isHeadless(), does this >> mean a possible bug in the createGE implementation? should we check >> isHeadLess() before calling Class.forName() ? >> >> I repeated my old test, it did call GraphicsEnvironment.isHeadless(): >> ------------------------------- >> public class Test extends JFrame { >> public Test() { >> setTitle("Simple example"); >> setSize(300, 200); >> setLocationRelativeTo(null); >> setDefaultCloseOperation(EXIT_ON_CLOSE); >> } >> >> public static void main(String[] args) { >> if (GraphicsEnvironment.isHeadless()) { >> System.out.println("JFrame test was skipped due to >> headless mode"); >> >> System.exit(0); >> } >> >> SwingUtilities.invokeLater(new Runnable() { >> @Override >> public void run() { >> Test ex = new Test(); >> ex.setVisible(true); >> } >> }); >> } >> } >> ------------------------------- >> When running the test with X11 and a wrong DISPLAY, isHeadless did >> not return "true" to stop the test, the test continued and failed >> later with the exception: >> Exception in thread "main" java.lang.InternalError: Can't connect >> to X11 window server using 'toto' as the value of the DISPLAY variable. >> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >> at >> sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >> at >> sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:110) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:190) >> at >> java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >> at >> java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >> ... >> >> I am wondering that "isHeadLess" would not check a wrong DISPLAY, a >> quick look at the method implementation seems telling yes. > > It assumes that if you have DISPLAY set, that it is the correct value. > Which is a fair assumption, I think. Yes we do have to set DISPLAY for this issue, I set a wrong DISPLAY to reproduce the bug. > > With my change, the test now passes in JPRT which it did not before. Good to hear that the test passes! Thanks, Shanliang > > /Staffan > >> >> Shanliang >>> /Staffan >>> >>> >>>> Look at the following 2 methods: >>>> >>>> public static boolean isHeadless() { >>>> return getHeadlessProperty(); >>>> } >>>> >>>> public boolean isHeadlessInstance() { >>>> // By default (local graphics environment), simply check the >>>> // headless property. >>>> return getHeadlessProperty(); >>>> } >>>> >>>> it seems no difference to call >>>> GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() >>>> and >>>> GraphicsEnvironment.isHeadless() >>>> yes better to cal the static method, but I am not sure that the direct call would fix the failure. >>>> >>>> Thanks, >>>> Shanliang >>>> >>>> >>>> Staffan Larsen wrote: >>>> >>>>> This test causes exceptions that looks like this: >>>>> >>>>> java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. >>>>> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >>>>> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >>>>> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >>>>> at java.lang.Class.forName0(Native Method) >>>>> at java.lang.Class.forName(Class.java:259) >>>>> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >>>>> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >>>>> at TraceJFrame.main(TraceJFrame.java:39) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:484) >>>>> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >>>>> at java.lang.Thread.run(Thread.java:744) >>>>> >>>>> >>>>> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >>>>> >>>>> Please review the fix below, >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >>>>> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >>>>> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >>>>> @@ -36,7 +36,7 @@ >>>>> >>>>> public class TraceJFrame { >>>>> public static void main(String args[]) throws Exception { >>>>> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >>>>> + if (GraphicsEnvironment.isHeadless()) { >>>>> System.out.println("JFrame test was skipped due to headless mode"); >>>>> } else { >>>>> DemoRun demo; >>>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Apr 9 12:03:23 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 16:03:23 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> Message-ID: <5345370B.4010408@oracle.com> Staffan, We can move it to separate file and put to test directory (with no intention to run it automatically). Other options is just change define to keep the test code but don't compile it to production libnpt. -Dmitry On 2014-04-09 11:12, Staffan Larsen wrote: > It?s been a very useful little test when changing the code in utf.c. Not sure why it has to be removed. > > /Staffan > > On 8 apr 2014, at 17:30, Vladimir Kempik wrote: > >> Hello >> >> Please review this changeset: >> >> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >> >> Thanks, Vladimir. >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Apr 9 12:20:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 14:20:07 +0200 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <5345370B.4010408@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> Message-ID: <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> I would prefer to keep the test where it is but change the ?#if 1? to ?#if 0? on line 399. Thanks, /Staffan On 9 apr 2014, at 14:03, Dmitry Samersoff wrote: > Staffan, > > We can move it to separate file and put to test directory (with no > intention to run it automatically). > > Other options is just change define to keep the test code but don't > compile it to production libnpt. > > -Dmitry > > > On 2014-04-09 11:12, Staffan Larsen wrote: >> It?s been a very useful little test when changing the code in utf.c. Not sure why it has to be removed. >> >> /Staffan >> >> On 8 apr 2014, at 17:30, Vladimir Kempik wrote: >> >>> Hello >>> >>> Please review this changeset: >>> >>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>> >>> Thanks, Vladimir. >>> >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Apr 9 12:24:39 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 16:24:39 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> Message-ID: <53453C07.5050109@oracle.com> Staffan, On 2014-04-09 16:20, Staffan Larsen wrote: > I would prefer to keep the test where it is but change the ?#if 1? to ?#if 0? on line 399. Are you OK with #ifdef COMPILE_WITH_UTF_TEST -Dmitry > > Thanks, > /Staffan > > On 9 apr 2014, at 14:03, Dmitry Samersoff wrote: > >> Staffan, >> >> We can move it to separate file and put to test directory (with no >> intention to run it automatically). >> >> Other options is just change define to keep the test code but don't >> compile it to production libnpt. >> >> -Dmitry >> >> >> On 2014-04-09 11:12, Staffan Larsen wrote: >>> It?s been a very useful little test when changing the code in utf.c. Not sure why it has to be removed. >>> >>> /Staffan >>> >>> On 8 apr 2014, at 17:30, Vladimir Kempik wrote: >>> >>>> Hello >>>> >>>> Please review this changeset: >>>> >>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>> >>>> Thanks, Vladimir. >>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Apr 9 12:28:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 14:28:55 +0200 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <53453C07.5050109@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> Message-ID: <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> Sure. On 9 apr 2014, at 14:24, Dmitry Samersoff wrote: > Staffan, > > On 2014-04-09 16:20, Staffan Larsen wrote: >> I would prefer to keep the test where it is but change the ?#if 1? to ?#if 0? on line 399. > > Are you OK with > > #ifdef COMPILE_WITH_UTF_TEST > > -Dmitry > >> >> Thanks, >> /Staffan >> >> On 9 apr 2014, at 14:03, Dmitry Samersoff wrote: >> >>> Staffan, >>> >>> We can move it to separate file and put to test directory (with no >>> intention to run it automatically). >>> >>> Other options is just change define to keep the test code but don't >>> compile it to production libnpt. >>> >>> -Dmitry >>> >>> >>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>> It?s been a very useful little test when changing the code in utf.c. Not sure why it has to be removed. >>>> >>>> /Staffan >>>> >>>> On 8 apr 2014, at 17:30, Vladimir Kempik wrote: >>>> >>>>> Hello >>>>> >>>>> Please review this changeset: >>>>> >>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in production library. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>> >>>>> Thanks, Vladimir. >>>>> >>>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Apr 9 12:32:16 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 16:32:16 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> Message-ID: <53453DD0.8020000@oracle.com> Vladimir, Please change define to #ifdef COMPILE_WITH_UTF_TEST -Dmitry On 2014-04-09 16:28, Staffan Larsen wrote: > Sure. > > On 9 apr 2014, at 14:24, Dmitry Samersoff > wrote: > >> Staffan, >> >> On 2014-04-09 16:20, Staffan Larsen wrote: >>> I would prefer to keep the test where it is but change the ?#if 1? to >>> ?#if 0? on line 399. >> >> Are you OK with >> >> #ifdef COMPILE_WITH_UTF_TEST >> >> -Dmitry >> >>> >>> Thanks, >>> /Staffan >>> >>> On 9 apr 2014, at 14:03, Dmitry Samersoff >>> > wrote: >>> >>>> Staffan, >>>> >>>> We can move it to separate file and put to test directory (with no >>>> intention to run it automatically). >>>> >>>> Other options is just change define to keep the test code but don't >>>> compile it to production libnpt. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>>> It?s been a very useful little test when changing the code in >>>>> utf.c. Not sure why it has to be removed. >>>>> >>>>> /Staffan >>>>> >>>>> On 8 apr 2014, at 17:30, Vladimir Kempik >>>>> > wrote: >>>>> >>>>>> Hello >>>>>> >>>>>> Please review this changeset: >>>>>> >>>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be >>>>>> in production library. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>>> >>>>>> Thanks, Vladimir. >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kempik at oracle.com Wed Apr 9 12:49:36 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 09 Apr 2014 16:49:36 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <53453DD0.8020000@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> <53453DD0.8020000@oracle.com> Message-ID: <534541E0.6090906@oracle.com> Hello Thanks for comments. Updated webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.01/ Vladimir. On 09.04.2014 16:32, Dmitry Samersoff wrote: > Vladimir, > > Please change define to > > #ifdef COMPILE_WITH_UTF_TEST > > -Dmitry > > > On 2014-04-09 16:28, Staffan Larsen wrote: >> Sure. >> >> On 9 apr 2014, at 14:24, Dmitry Samersoff > > wrote: >> >>> Staffan, >>> >>> On 2014-04-09 16:20, Staffan Larsen wrote: >>>> I would prefer to keep the test where it is but change the ?#if 1? to >>>> ?#if 0? on line 399. >>> Are you OK with >>> >>> #ifdef COMPILE_WITH_UTF_TEST >>> >>> -Dmitry >>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 9 apr 2014, at 14:03, Dmitry Samersoff >>>> > wrote: >>>> >>>>> Staffan, >>>>> >>>>> We can move it to separate file and put to test directory (with no >>>>> intention to run it automatically). >>>>> >>>>> Other options is just change define to keep the test code but don't >>>>> compile it to production libnpt. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>>>> It?s been a very useful little test when changing the code in >>>>>> utf.c. Not sure why it has to be removed. >>>>>> >>>>>> /Staffan >>>>>> >>>>>> On 8 apr 2014, at 17:30, Vladimir Kempik >>>>>> > wrote: >>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Please review this changeset: >>>>>>> >>>>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be >>>>>>> in production library. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>>>> >>>>>>> Thanks, Vladimir. >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the sources. >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > From staffan.larsen at oracle.com Wed Apr 9 13:01:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Apr 2014 15:01:14 +0200 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <534541E0.6090906@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> <53453DD0.8020000@oracle.com> <534541E0.6090906@oracle.com> Message-ID: <1C0E14CB-D699-44E2-9D4C-4081E24D0F9B@oracle.com> Reviewed. Thanks, /Staffan On 9 apr 2014, at 14:49, Vladimir Kempik wrote: > Hello > > Thanks for comments. > > Updated webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.01/ > > Vladimir. > On 09.04.2014 16:32, Dmitry Samersoff wrote: >> Vladimir, >> >> Please change define to >> >> #ifdef COMPILE_WITH_UTF_TEST >> >> -Dmitry >> >> >> On 2014-04-09 16:28, Staffan Larsen wrote: >>> Sure. >>> >>> On 9 apr 2014, at 14:24, Dmitry Samersoff >> > wrote: >>> >>>> Staffan, >>>> >>>> On 2014-04-09 16:20, Staffan Larsen wrote: >>>>> I would prefer to keep the test where it is but change the ?#if 1? to >>>>> ?#if 0? on line 399. >>>> Are you OK with >>>> >>>> #ifdef COMPILE_WITH_UTF_TEST >>>> >>>> -Dmitry >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 9 apr 2014, at 14:03, Dmitry Samersoff >>>>> > wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> We can move it to separate file and put to test directory (with no >>>>>> intention to run it automatically). >>>>>> >>>>>> Other options is just change define to keep the test code but don't >>>>>> compile it to production libnpt. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>>>>> It?s been a very useful little test when changing the code in >>>>>>> utf.c. Not sure why it has to be removed. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 8 apr 2014, at 17:30, Vladimir Kempik >>>>>>> > wrote: >>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review this changeset: >>>>>>>> >>>>>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be >>>>>>>> in production library. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>>>>> >>>>>>>> Thanks, Vladimir. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the sources. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > From dmitry.samersoff at oracle.com Wed Apr 9 13:44:22 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Apr 2014 17:44:22 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <534541E0.6090906@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> <53453DD0.8020000@oracle.com> <534541E0.6090906@oracle.com> Message-ID: <53454EB6.7070803@oracle.com> Vladimir, Looks good for me! -Dmitry On 2014-04-09 16:49, Vladimir Kempik wrote: > Hello > > Thanks for comments. > > Updated webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.01/ > > Vladimir. > On 09.04.2014 16:32, Dmitry Samersoff wrote: >> Vladimir, >> >> Please change define to >> >> #ifdef COMPILE_WITH_UTF_TEST >> >> -Dmitry >> >> >> On 2014-04-09 16:28, Staffan Larsen wrote: >>> Sure. >>> >>> On 9 apr 2014, at 14:24, Dmitry Samersoff >> > wrote: >>> >>>> Staffan, >>>> >>>> On 2014-04-09 16:20, Staffan Larsen wrote: >>>>> I would prefer to keep the test where it is but change the ?#if 1? to >>>>> ?#if 0? on line 399. >>>> Are you OK with >>>> >>>> #ifdef COMPILE_WITH_UTF_TEST >>>> >>>> -Dmitry >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 9 apr 2014, at 14:03, Dmitry Samersoff >>>>> > >>>>> wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> We can move it to separate file and put to test directory (with no >>>>>> intention to run it automatically). >>>>>> >>>>>> Other options is just change define to keep the test code but don't >>>>>> compile it to production libnpt. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>>>>> It?s been a very useful little test when changing the code in >>>>>>> utf.c. Not sure why it has to be removed. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 8 apr 2014, at 17:30, Vladimir Kempik >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review this changeset: >>>>>>>> >>>>>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be >>>>>>>> in production library. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>>>>> >>>>>>>> Thanks, Vladimir. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the >>>>>> sources. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Apr 10 14:17:52 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Apr 2014 18:17:52 +0400 Subject: RFR: 8039368 Remove testcase from npt utf.c In-Reply-To: <534541E0.6090906@oracle.com> References: <53441630.2030506@oracle.com> <4BE66922-F9FF-4870-9B6B-E4E3714310FE@oracle.com> <5345370B.4010408@oracle.com> <8C0344A0-F0FE-40F6-B99B-2BB66B713CF1@oracle.com> <53453C07.5050109@oracle.com> <18D82499-FC81-4570-93AF-E23F9118A4DD@oracle.com> <53453DD0.8020000@oracle.com> <534541E0.6090906@oracle.com> Message-ID: <5346A810.6090109@oracle.com> Vladimir, The fix is pushed to jdk9, jdk9 changeset is http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b2627ad873c So you can go ahead with backports. -Dmitry On 2014-04-09 16:49, Vladimir Kempik wrote: > Hello > > Thanks for comments. > > Updated webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.01/ > > Vladimir. > On 09.04.2014 16:32, Dmitry Samersoff wrote: >> Vladimir, >> >> Please change define to >> >> #ifdef COMPILE_WITH_UTF_TEST >> >> -Dmitry >> >> >> On 2014-04-09 16:28, Staffan Larsen wrote: >>> Sure. >>> >>> On 9 apr 2014, at 14:24, Dmitry Samersoff >> > wrote: >>> >>>> Staffan, >>>> >>>> On 2014-04-09 16:20, Staffan Larsen wrote: >>>>> I would prefer to keep the test where it is but change the ?#if 1? to >>>>> ?#if 0? on line 399. >>>> Are you OK with >>>> >>>> #ifdef COMPILE_WITH_UTF_TEST >>>> >>>> -Dmitry >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 9 apr 2014, at 14:03, Dmitry Samersoff >>>>> > >>>>> wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> We can move it to separate file and put to test directory (with no >>>>>> intention to run it automatically). >>>>>> >>>>>> Other options is just change define to keep the test code but don't >>>>>> compile it to production libnpt. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-04-09 11:12, Staffan Larsen wrote: >>>>>>> It?s been a very useful little test when changing the code in >>>>>>> utf.c. Not sure why it has to be removed. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 8 apr 2014, at 17:30, Vladimir Kempik >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>>> Hello >>>>>>>> >>>>>>>> Please review this changeset: >>>>>>>> >>>>>>>> File jdk/src/share/npt/utf.c contains a testcase that shouldn't be >>>>>>>> in production library. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039368 >>>>>>>> webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/ >>>>>>>> >>>>>>>> Thanks, Vladimir. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the >>>>>> sources. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Fri Apr 11 07:16:00 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Apr 2014 09:16:00 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> Message-ID: Here is a new version where the 200 char cap is removed: http://cr.openjdk.java.net/~sla/8039173/webrev.02/ Thanks, /Staffan On 4 apr 2014, at 16:27, Staffan Larsen wrote: > Thanks Ivan. > > I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. > > (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). > > So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). > > If someone has a better solution for propagating error messages from the operations, I?m all ears. > > Thanks, > /Staffan > > > > On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: > >> An alternative, more compact variant might be >> >> ------------------------ >> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >> int n, off = 0, len = maxlen + 1; >> byte b[] = new byte[len]; >> while ((n = sis.read(b, off, len - off)) > 0) >> off += n; >> return (off == 0) ? null >> : (off < len) >> ? new String(b, 0, off, "UTF-8") >> : new String(b, 0, maxlen, "UTF-8") + " ..."; >> } >> ------------------------ >> >> Not a big deal, of course. >> >> Sincerely yours, >> Ivan >> >> >> >> On 04.04.2014 16:24, Ivan Gerasimov wrote: >>> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >>> The dots will be appended to the message, even though it's not necessary. >>> >>> I think the only reliable way to deal with it is to try to read one extra character from sis. >>> >>> Something like this should do: >>> ------------------------ >>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>> byte b[] = new byte[maxlen + 1]; >>> int n, off = 0, len = b.length; >>> do { >>> n = sis.read(b, off, len); >>> if (n == -1) { >>> break; >>> } >>> off += n; >>> len -= n; >>> } while (off < maxlen); >>> >>> String message = null; >>> if (off > 0) { >>> message = (off > maxlen) >>> ? new String(b, 0, maxlen, "UTF-8") + " ..." >>> : new String(b, 0, off, "UTF-8"); >>> } >>> return message; >>> } >>> ------------------------ >>> >>> Sincerely yours, >>> Ivan >>> >>> On 04.04.2014 16:08, Staffan Larsen wrote: >>>> I?m afraid you are right! Doh. Need to add more testing... >>>> >>>> How about this change: >>>> >>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>> @@ -267,9 +267,11 @@ >>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>> byte b[] = new byte[maxlen]; >>>> int n, off = 0, len = maxlen; >>>> + boolean complete = false; >>>> do { >>>> n = sis.read(b, off, len); >>>> if (n == -1) { >>>> + complete = true; >>>> break; >>>> } >>>> off += n; >>>> @@ -280,7 +282,7 @@ >>>> if (off > 0) { >>>> message = new String(b, 0, off, "UTF-8"); >>>> } >>>> - if (off > b.length && message != null) { >>>> + if (!complete && message != null) { >>>> message += " ..."; >>>> } >>>> return message; >>>> >>>> >>>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>>> >>>>> Thank you Staffan for fixing them! >>>>> >>>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>>> Thanks for finding these bugs, Ivan! >>>>>> >>>>>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>>> >>>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>> @@ -266,18 +266,21 @@ >>>>>> */ >>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>> byte b[] = new byte[maxlen]; >>>>>> - int n, off = 0, len = b.length; >>>>>> + int n, off = 0, len = maxlen; >>>>>> do { >>>>>> n = sis.read(b, off, len); >>>>>> + if (n == -1) { >>>>>> + break; >>>>>> + } >>>>>> off += n; >>>>>> len -= n; >>>>>> - } while (n >= 0 && off < b.length); >>>>>> + } while (off < maxlen); >>>>>> >>>>>> String message = null; >>>>>> if (off > 0) { >>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>> } >>>>>> - if (off == b.length && message != null) { >>>>>> + if (off > b.length && message != null) { >>>>>> message += " ..."; >>>>>> } >>>>>> return message; >>>>>> >>>>>> >>>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>>> >>>>>>> Hi Staffan! >>>>>>> >>>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>>> >>>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>> >>>> >>>> >>> >>> >>> >> > From ivan.gerasimov at oracle.com Fri Apr 11 07:32:26 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Apr 2014 11:32:26 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> Message-ID: <53479A8A.5070803@oracle.com> Hi Staffan! Isn't the second read in line# 268 erroneous? 267 while ((n = sis.read(b)) != -1) { 268 n = sis.read(b); Sincerely yours, Ivan On 11.04.2014 11:16, Staffan Larsen wrote: > Here is a new version where the 200 char cap is removed: > > http://cr.openjdk.java.net/~sla/8039173/webrev.02/ > > Thanks, > /Staffan > > On 4 apr 2014, at 16:27, Staffan Larsen wrote: > >> Thanks Ivan. >> >> I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. >> >> (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). >> >> So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). >> >> If someone has a better solution for propagating error messages from the operations, I?m all ears. >> >> Thanks, >> /Staffan >> >> >> >> On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: >> >>> An alternative, more compact variant might be >>> >>> ------------------------ >>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>> int n, off = 0, len = maxlen + 1; >>> byte b[] = new byte[len]; >>> while ((n = sis.read(b, off, len - off)) > 0) >>> off += n; >>> return (off == 0) ? null >>> : (off < len) >>> ? new String(b, 0, off, "UTF-8") >>> : new String(b, 0, maxlen, "UTF-8") + " ..."; >>> } >>> ------------------------ >>> >>> Not a big deal, of course. >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> >>> On 04.04.2014 16:24, Ivan Gerasimov wrote: >>>> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >>>> The dots will be appended to the message, even though it's not necessary. >>>> >>>> I think the only reliable way to deal with it is to try to read one extra character from sis. >>>> >>>> Something like this should do: >>>> ------------------------ >>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>> byte b[] = new byte[maxlen + 1]; >>>> int n, off = 0, len = b.length; >>>> do { >>>> n = sis.read(b, off, len); >>>> if (n == -1) { >>>> break; >>>> } >>>> off += n; >>>> len -= n; >>>> } while (off < maxlen); >>>> >>>> String message = null; >>>> if (off > 0) { >>>> message = (off > maxlen) >>>> ? new String(b, 0, maxlen, "UTF-8") + " ..." >>>> : new String(b, 0, off, "UTF-8"); >>>> } >>>> return message; >>>> } >>>> ------------------------ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 04.04.2014 16:08, Staffan Larsen wrote: >>>>> I?m afraid you are right! Doh. Need to add more testing... >>>>> >>>>> How about this change: >>>>> >>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>> @@ -267,9 +267,11 @@ >>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>> byte b[] = new byte[maxlen]; >>>>> int n, off = 0, len = maxlen; >>>>> + boolean complete = false; >>>>> do { >>>>> n = sis.read(b, off, len); >>>>> if (n == -1) { >>>>> + complete = true; >>>>> break; >>>>> } >>>>> off += n; >>>>> @@ -280,7 +282,7 @@ >>>>> if (off > 0) { >>>>> message = new String(b, 0, off, "UTF-8"); >>>>> } >>>>> - if (off > b.length && message != null) { >>>>> + if (!complete && message != null) { >>>>> message += " ..."; >>>>> } >>>>> return message; >>>>> >>>>> >>>>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>>>> >>>>>> Thank you Staffan for fixing them! >>>>>> >>>>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>>>> Thanks for finding these bugs, Ivan! >>>>>>> >>>>>>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>>>> >>>>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>> @@ -266,18 +266,21 @@ >>>>>>> */ >>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>> byte b[] = new byte[maxlen]; >>>>>>> - int n, off = 0, len = b.length; >>>>>>> + int n, off = 0, len = maxlen; >>>>>>> do { >>>>>>> n = sis.read(b, off, len); >>>>>>> + if (n == -1) { >>>>>>> + break; >>>>>>> + } >>>>>>> off += n; >>>>>>> len -= n; >>>>>>> - } while (n >= 0 && off < b.length); >>>>>>> + } while (off < maxlen); >>>>>>> >>>>>>> String message = null; >>>>>>> if (off > 0) { >>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>> } >>>>>>> - if (off == b.length && message != null) { >>>>>>> + if (off > b.length && message != null) { >>>>>>> message += " ..."; >>>>>>> } >>>>>>> return message; >>>>>>> >>>>>>> >>>>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>>>> >>>>>>>> Hi Staffan! >>>>>>>> >>>>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>>>> >>>>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>> >>>> >>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 11 07:51:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Apr 2014 09:51:42 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <53479A8A.5070803@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> <53479A8A.5070803@oracle.com> Message-ID: <0CAC3A3A-6698-4BB6-97AC-F27FE0BAB47A@oracle.com> Of course?This is getting embarrassing. :) http://cr.openjdk.java.net/~sla/8039173/webrev.03/ /Staffan On 11 apr 2014, at 09:32, Ivan Gerasimov wrote: > Hi Staffan! > > Isn't the second read in line# 268 erroneous? > > 267 while ((n = sis.read(b)) != -1) { > 268 n = sis.read(b); > > Sincerely yours, > Ivan > > On 11.04.2014 11:16, Staffan Larsen wrote: >> Here is a new version where the 200 char cap is removed: >> >> http://cr.openjdk.java.net/~sla/8039173/webrev.02/ >> >> Thanks, >> /Staffan >> >> On 4 apr 2014, at 16:27, Staffan Larsen wrote: >> >>> Thanks Ivan. >>> >>> I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. >>> >>> (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). >>> >>> So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). >>> >>> If someone has a better solution for propagating error messages from the operations, I?m all ears. >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: >>> >>>> An alternative, more compact variant might be >>>> >>>> ------------------------ >>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>> int n, off = 0, len = maxlen + 1; >>>> byte b[] = new byte[len]; >>>> while ((n = sis.read(b, off, len - off)) > 0) >>>> off += n; >>>> return (off == 0) ? null >>>> : (off < len) >>>> ? new String(b, 0, off, "UTF-8") >>>> : new String(b, 0, maxlen, "UTF-8") + " ..."; >>>> } >>>> ------------------------ >>>> >>>> Not a big deal, of course. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> >>>> On 04.04.2014 16:24, Ivan Gerasimov wrote: >>>>> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >>>>> The dots will be appended to the message, even though it's not necessary. >>>>> >>>>> I think the only reliable way to deal with it is to try to read one extra character from sis. >>>>> >>>>> Something like this should do: >>>>> ------------------------ >>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>> byte b[] = new byte[maxlen + 1]; >>>>> int n, off = 0, len = b.length; >>>>> do { >>>>> n = sis.read(b, off, len); >>>>> if (n == -1) { >>>>> break; >>>>> } >>>>> off += n; >>>>> len -= n; >>>>> } while (off < maxlen); >>>>> >>>>> String message = null; >>>>> if (off > 0) { >>>>> message = (off > maxlen) >>>>> ? new String(b, 0, maxlen, "UTF-8") + " ..." >>>>> : new String(b, 0, off, "UTF-8"); >>>>> } >>>>> return message; >>>>> } >>>>> ------------------------ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 04.04.2014 16:08, Staffan Larsen wrote: >>>>>> I?m afraid you are right! Doh. Need to add more testing... >>>>>> >>>>>> How about this change: >>>>>> >>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>> @@ -267,9 +267,11 @@ >>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>> byte b[] = new byte[maxlen]; >>>>>> int n, off = 0, len = maxlen; >>>>>> + boolean complete = false; >>>>>> do { >>>>>> n = sis.read(b, off, len); >>>>>> if (n == -1) { >>>>>> + complete = true; >>>>>> break; >>>>>> } >>>>>> off += n; >>>>>> @@ -280,7 +282,7 @@ >>>>>> if (off > 0) { >>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>> } >>>>>> - if (off > b.length && message != null) { >>>>>> + if (!complete && message != null) { >>>>>> message += " ..."; >>>>>> } >>>>>> return message; >>>>>> >>>>>> >>>>>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>>>>> >>>>>>> Thank you Staffan for fixing them! >>>>>>> >>>>>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>>>>> Thanks for finding these bugs, Ivan! >>>>>>>> >>>>>>>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>>>>> >>>>>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>> @@ -266,18 +266,21 @@ >>>>>>>> */ >>>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>>> byte b[] = new byte[maxlen]; >>>>>>>> - int n, off = 0, len = b.length; >>>>>>>> + int n, off = 0, len = maxlen; >>>>>>>> do { >>>>>>>> n = sis.read(b, off, len); >>>>>>>> + if (n == -1) { >>>>>>>> + break; >>>>>>>> + } >>>>>>>> off += n; >>>>>>>> len -= n; >>>>>>>> - } while (n >= 0 && off < b.length); >>>>>>>> + } while (off < maxlen); >>>>>>>> >>>>>>>> String message = null; >>>>>>>> if (off > 0) { >>>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>>> } >>>>>>>> - if (off == b.length && message != null) { >>>>>>>> + if (off > b.length && message != null) { >>>>>>>> message += " ..."; >>>>>>>> } >>>>>>>> return message; >>>>>>>> >>>>>>>> >>>>>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>>>>> >>>>>>>>> Hi Staffan! >>>>>>>>> >>>>>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>>>>> >>>>>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>> >>>>> >>>>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Fri Apr 11 08:36:17 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 11 Apr 2014 12:36:17 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <0CAC3A3A-6698-4BB6-97AC-F27FE0BAB47A@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> <53479A8A.5070803@oracle.com> <0CAC3A3A-6698-4BB6-97AC-F27FE0BAB47A@oracle.com> Message-ID: <5347A981.4040202@oracle.com> On 11.04.2014 11:51, Staffan Larsen wrote: > Of course?This is getting embarrassing. :) > > http://cr.openjdk.java.net/~sla/8039173/webrev.03/ > > Now it looks fine to me :) Not a reviewer though. There are a few minor formatting glitches, but I don't have a strong opinion whether they should be changed or not. Here they are anyway, in case you need it: 1) src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java 267 while ((n = sis.read(b)) != -1) { two spaces before the curly brace 2) src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java, src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java, src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java src/windows/classes/sun/tools/attach/WindowsVirtualMachine.java 212 } 213 else { looks inconsistent with other else clauses in these files. Shouldn't it be places on the same line? Personally, I would prefer throw new AttachOperationFailedException(message != null ?message : "Command failed in target VM"); Sincerely yours, Ivan > /Staffan > > On 11 apr 2014, at 09:32, Ivan Gerasimov > wrote: > >> Hi Staffan! >> >> Isn't the second read in line# 268 erroneous? >> >> 267 while ((n = sis.read(b)) != -1) { >> 268 n = sis.read(b); >> >> Sincerely yours, >> Ivan >> >> On 11.04.2014 11:16, Staffan Larsen wrote: >>> Here is a new version where the 200 char cap is removed: >>> >>> http://cr.openjdk.java.net/~sla/8039173/webrev.02/ >>> >>> Thanks, >>> /Staffan >>> >>> On 4 apr 2014, at 16:27, Staffan Larsen wrote: >>> >>>> Thanks Ivan. >>>> >>>> I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. >>>> >>>> (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). >>>> >>>> So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). >>>> >>>> If someone has a better solution for propagating error messages from the operations, I?m all ears. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>> On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: >>>> >>>>> An alternative, more compact variant might be >>>>> >>>>> ------------------------ >>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>> int n, off = 0, len = maxlen + 1; >>>>> byte b[] = new byte[len]; >>>>> while ((n = sis.read(b, off, len - off)) > 0) >>>>> off += n; >>>>> return (off == 0) ? null >>>>> : (off < len) >>>>> ? new String(b, 0, off, "UTF-8") >>>>> : new String(b, 0, maxlen, "UTF-8") + " ..."; >>>>> } >>>>> ------------------------ >>>>> >>>>> Not a big deal, of course. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> >>>>> On 04.04.2014 16:24, Ivan Gerasimov wrote: >>>>>> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >>>>>> The dots will be appended to the message, even though it's not necessary. >>>>>> >>>>>> I think the only reliable way to deal with it is to try to read one extra character from sis. >>>>>> >>>>>> Something like this should do: >>>>>> ------------------------ >>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>> byte b[] = new byte[maxlen + 1]; >>>>>> int n, off = 0, len = b.length; >>>>>> do { >>>>>> n = sis.read(b, off, len); >>>>>> if (n == -1) { >>>>>> break; >>>>>> } >>>>>> off += n; >>>>>> len -= n; >>>>>> } while (off < maxlen); >>>>>> >>>>>> String message = null; >>>>>> if (off > 0) { >>>>>> message = (off > maxlen) >>>>>> ? new String(b, 0, maxlen, "UTF-8") + " ..." >>>>>> : new String(b, 0, off, "UTF-8"); >>>>>> } >>>>>> return message; >>>>>> } >>>>>> ------------------------ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 04.04.2014 16:08, Staffan Larsen wrote: >>>>>>> I?m afraid you are right! Doh. Need to add more testing... >>>>>>> >>>>>>> How about this change: >>>>>>> >>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>> @@ -267,9 +267,11 @@ >>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>> byte b[] = new byte[maxlen]; >>>>>>> int n, off = 0, len = maxlen; >>>>>>> + boolean complete = false; >>>>>>> do { >>>>>>> n = sis.read(b, off, len); >>>>>>> if (n == -1) { >>>>>>> + complete = true; >>>>>>> break; >>>>>>> } >>>>>>> off += n; >>>>>>> @@ -280,7 +282,7 @@ >>>>>>> if (off > 0) { >>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>> } >>>>>>> - if (off > b.length && message != null) { >>>>>>> + if (!complete && message != null) { >>>>>>> message += " ..."; >>>>>>> } >>>>>>> return message; >>>>>>> >>>>>>> >>>>>>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>>>>>> >>>>>>>> Thank you Staffan for fixing them! >>>>>>>> >>>>>>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>>>>>> Thanks for finding these bugs, Ivan! >>>>>>>>> >>>>>>>>> I have updated the webrev at:http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>>>>>> >>>>>>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>> @@ -266,18 +266,21 @@ >>>>>>>>> */ >>>>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>>>> byte b[] = new byte[maxlen]; >>>>>>>>> - int n, off = 0, len = b.length; >>>>>>>>> + int n, off = 0, len = maxlen; >>>>>>>>> do { >>>>>>>>> n = sis.read(b, off, len); >>>>>>>>> + if (n == -1) { >>>>>>>>> + break; >>>>>>>>> + } >>>>>>>>> off += n; >>>>>>>>> len -= n; >>>>>>>>> - } while (n >= 0 && off < b.length); >>>>>>>>> + } while (off < maxlen); >>>>>>>>> >>>>>>>>> String message = null; >>>>>>>>> if (off > 0) { >>>>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>>>> } >>>>>>>>> - if (off == b.length && message != null) { >>>>>>>>> + if (off > b.length && message != null) { >>>>>>>>> message += " ..."; >>>>>>>>> } >>>>>>>>> return message; >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>>>>>> >>>>>>>>>> Hi Staffan! >>>>>>>>>> >>>>>>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>>>>>> >>>>>>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 11 08:59:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Apr 2014 10:59:12 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <5347A981.4040202@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <533E78F5.4030800@oracle.com> <533E9DA0.2080200@oracle.com> <904B9369-C34B-4ECE-90AC-44D159F6CBA0@oracle.com> <533EA49A.6000609@oracle.com> <533EA866.5060404@oracle.com> <53479A8A.5070803@oracle.com> <0CAC3A3A-6698-4BB6-97AC-F27FE0BAB47A@oracle.com> <5347A981.4040202@oracle.com> Message-ID: <1651E7BB-97CE-4DA6-BF13-D7F1426F6F58@oracle.com> On 11 apr 2014, at 10:36, Ivan Gerasimov wrote: > > On 11.04.2014 11:51, Staffan Larsen wrote: >> Of course?This is getting embarrassing. :) >> >> http://cr.openjdk.java.net/~sla/8039173/webrev.03/ >> > Now it looks fine to me :) Thanks. > Not a reviewer though. > > > There are a few minor formatting glitches, but I don't have a strong opinion whether they should be changed or not. > > Here they are anyway, in case you need it: > 1) > src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > 267 while ((n = sis.read(b)) != -1) { > two spaces before the curly brace Will fix. > > 2) > src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java, > src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java, > src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java > src/windows/classes/sun/tools/attach/WindowsVirtualMachine.java > 212 } > 213 else { > looks inconsistent with other else clauses in these files. > Shouldn't it be places on the same line? Will fix. > > Personally, I would prefer > throw new AttachOperationFailedException(message != null ? message : "Command failed in target VM?); I went back and forth on that one. The above would lead to a longer line which I would then have to break and I would be back where I started. I don?t have a strong opinion, though. /Staffan > Sincerely yours, > Ivan > > >> /Staffan >> >> On 11 apr 2014, at 09:32, Ivan Gerasimov wrote: >> >>> Hi Staffan! >>> >>> Isn't the second read in line# 268 erroneous? >>> >>> 267 while ((n = sis.read(b)) != -1) { >>> 268 n = sis.read(b); >>> >>> Sincerely yours, >>> Ivan >>> >>> On 11.04.2014 11:16, Staffan Larsen wrote: >>>> Here is a new version where the 200 char cap is removed: >>>> >>>> http://cr.openjdk.java.net/~sla/8039173/webrev.02/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 4 apr 2014, at 16:27, Staffan Larsen wrote: >>>> >>>>> Thanks Ivan. >>>>> >>>>> I?ve been thinking a bit more about this and discussing with people here. I?m not sure anymore that it is a good idea to cap the error message. My original thought was that it made sense to not overflow the client with tons of output if something went wrong in the target. On the other hand, there is nothing that says that the error message will be in the first 200 characters. It is perfectly possible for an operation to successfully run for a while and only at the end run into a problem. In that case the output will have the exception at the end, following any amount of output. Capping the message in that case would hide the error. >>>>> >>>>> (My second thought was: let?s only take the last 200 chars, but there is no guarantee that that will contain the complete error message either). >>>>> >>>>> So the "keep it simple? principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). >>>>> >>>>> If someone has a better solution for propagating error messages from the operations, I?m all ears. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> On 4 apr 2014, at 14:41, Ivan Gerasimov wrote: >>>>> >>>>>> An alternative, more compact variant might be >>>>>> >>>>>> ------------------------ >>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>> int n, off = 0, len = maxlen + 1; >>>>>> byte b[] = new byte[len]; >>>>>> while ((n = sis.read(b, off, len - off)) > 0) >>>>>> off += n; >>>>>> return (off == 0) ? null >>>>>> : (off < len) >>>>>> ? new String(b, 0, off, "UTF-8") >>>>>> : new String(b, 0, maxlen, "UTF-8") + " ..."; >>>>>> } >>>>>> ------------------------ >>>>>> >>>>>> Not a big deal, of course. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> >>>>>> On 04.04.2014 16:24, Ivan Gerasimov wrote: >>>>>>> Now you reintroduced the smallish issue, when the message is exactly 200 characters (or whatever maxlen is). >>>>>>> The dots will be appended to the message, even though it's not necessary. >>>>>>> >>>>>>> I think the only reliable way to deal with it is to try to read one extra character from sis. >>>>>>> >>>>>>> Something like this should do: >>>>>>> ------------------------ >>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>> byte b[] = new byte[maxlen + 1]; >>>>>>> int n, off = 0, len = b.length; >>>>>>> do { >>>>>>> n = sis.read(b, off, len); >>>>>>> if (n == -1) { >>>>>>> break; >>>>>>> } >>>>>>> off += n; >>>>>>> len -= n; >>>>>>> } while (off < maxlen); >>>>>>> >>>>>>> String message = null; >>>>>>> if (off > 0) { >>>>>>> message = (off > maxlen) >>>>>>> ? new String(b, 0, maxlen, "UTF-8") + " ..." >>>>>>> : new String(b, 0, off, "UTF-8"); >>>>>>> } >>>>>>> return message; >>>>>>> } >>>>>>> ------------------------ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 04.04.2014 16:08, Staffan Larsen wrote: >>>>>>>> I?m afraid you are right! Doh. Need to add more testing... >>>>>>>> >>>>>>>> How about this change: >>>>>>>> >>>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>> @@ -267,9 +267,11 @@ >>>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>>> byte b[] = new byte[maxlen]; >>>>>>>> int n, off = 0, len = maxlen; >>>>>>>> + boolean complete = false; >>>>>>>> do { >>>>>>>> n = sis.read(b, off, len); >>>>>>>> if (n == -1) { >>>>>>>> + complete = true; >>>>>>>> break; >>>>>>>> } >>>>>>>> off += n; >>>>>>>> @@ -280,7 +282,7 @@ >>>>>>>> if (off > 0) { >>>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>>> } >>>>>>>> - if (off > b.length && message != null) { >>>>>>>> + if (!complete && message != null) { >>>>>>>> message += " ..."; >>>>>>>> } >>>>>>>> return message; >>>>>>>> >>>>>>>> >>>>>>>> On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: >>>>>>>> >>>>>>>>> Thank you Staffan for fixing them! >>>>>>>>> >>>>>>>>> But I'm afraid that now the function will never add ellipsis to the message, even if it gets truncated. >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 04.04.2014 15:47, Staffan Larsen wrote: >>>>>>>>>> Thanks for finding these bugs, Ivan! >>>>>>>>>> >>>>>>>>>> I have updated the webrev at: http://cr.openjdk.java.net/~sla/8039173/webrev.01/, and I have also included the diff below. >>>>>>>>>> >>>>>>>>>> The updated webrev also has some changes in the javadoc for VirtualMachine to clarify that some methods can now throw AttachOperationFailedException. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> diff --git a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>>> --- a/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>>> +++ b/src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java >>>>>>>>>> @@ -266,18 +266,21 @@ >>>>>>>>>> */ >>>>>>>>>> String getErrorMessage(InputStream sis, int maxlen) throws IOException { >>>>>>>>>> byte b[] = new byte[maxlen]; >>>>>>>>>> - int n, off = 0, len = b.length; >>>>>>>>>> + int n, off = 0, len = maxlen; >>>>>>>>>> do { >>>>>>>>>> n = sis.read(b, off, len); >>>>>>>>>> + if (n == -1) { >>>>>>>>>> + break; >>>>>>>>>> + } >>>>>>>>>> off += n; >>>>>>>>>> len -= n; >>>>>>>>>> - } while (n >= 0 && off < b.length); >>>>>>>>>> + } while (off < maxlen); >>>>>>>>>> >>>>>>>>>> String message = null; >>>>>>>>>> if (off > 0) { >>>>>>>>>> message = new String(b, 0, off, "UTF-8"); >>>>>>>>>> } >>>>>>>>>> - if (off == b.length && message != null) { >>>>>>>>>> + if (off > b.length && message != null) { >>>>>>>>>> message += " ..."; >>>>>>>>>> } >>>>>>>>>> return message; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: >>>>>>>>>> >>>>>>>>>>> Hi Staffan! >>>>>>>>>>> >>>>>>>>>>> I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). >>>>>>>>>>> >>>>>>>>>>> 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, >>>>>>>>>>> 2) If maxlen is greater than needed, then sis.read(b, off, len) at the line #271 will eventually return -1, and it will cause the message to lose its last character. >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Apr 11 14:48:17 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Apr 2014 10:48:17 -0400 Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated" Message-ID: <534800B1.5060201@oracle.com> Summary: Dtrace monitoring uses size before mirror size is set. The refactoring I did for bug https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The size of the mirror is filled in by the InstanceMirrorKlass allocation but was used for dtrace probes before it in the normal allocation pass. Pass the allocated size to dtrace function instead. Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist also. open webrev at http://cr.openjdk.java.net/~coleenp/8039904/ bug link https://bugs.openjdk.java.net/browse/JDK-8039904 Thanks, Coleen From kmcguigan at twitter.com Fri Apr 11 16:00:02 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Fri, 11 Apr 2014 12:00:02 -0400 Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated" In-Reply-To: <534800B1.5060201@oracle.com> References: <534800B1.5060201@oracle.com> Message-ID: Looks good, but why are you not using a newer version of webrev with "next" links?? -- - Keith On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > Summary: Dtrace monitoring uses size before mirror size is set. > > The refactoring I did for bug https://bugs.openjdk.java.net/ > browse/JDK-8028497 caused this bug. The size of the mirror is filled in > by the InstanceMirrorKlass allocation but was used for dtrace probes before > it in the normal allocation pass. Pass the allocated size to dtrace > function instead. > > Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist also. > > open webrev at http://cr.openjdk.java.net/~coleenp/8039904/ > bug link https://bugs.openjdk.java.net/browse/JDK-8039904 > > Thanks, > Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Apr 11 16:22:28 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Apr 2014 12:22:28 -0400 Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated" In-Reply-To: References: <534800B1.5060201@oracle.com> Message-ID: <534816C4.9070904@oracle.com> On 4/11/14, 12:00 PM, Keith McGuigan wrote: > Looks good, but why are you not using a newer version of webrev with > "next" links?? Thanks Keith. The private copy I had of the "next" link webrev that I had broke for me for some mysterious reason. I filed a bug to see if the "official" version of webrev could have "next" links instead of debugging my own. Thanks! Coleen > > -- > - Keith > > > On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore > > > wrote: > > Summary: Dtrace monitoring uses size before mirror size is set. > > The refactoring I did for bug > https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. > The size of the mirror is filled in by the InstanceMirrorKlass > allocation but was used for dtrace probes before it in the normal > allocation pass. Pass the allocated size to dtrace function instead. > > Tested by dtrace tests on solaris sparcv9, testbase > vm.quick.testlist also. > > open webrev at http://cr.openjdk.java.net/~coleenp/8039904/ > > bug link https://bugs.openjdk.java.net/browse/JDK-8039904 > > Thanks, > Coleen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Apr 11 16:28:57 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Apr 2014 10:28:57 -0600 Subject: RFR: 8038963 com/sun/jdi tests fail because cygwin's ps sometimes misses processes In-Reply-To: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> References: <175F19F1-D118-4979-A7EA-E8E40C2FE8DE@oracle.com> Message-ID: <53481849.6040909@oracle.com> > webrev: http://cr.openjdk.java.net/~sla/8038963/webrev.00/ test/com/sun/jdi/ShellScaffold.sh No comments other than thinking about those Win98 fixes brought back painful memories... Thumbs up! Dan On 4/2/14 5:26 AM, Staffan Larsen wrote: > We have had many intermittent failures in the com/sun/jdi tests recently. After much debugging it turns out that the cygwin version of ps sometimes misses some processes. Since the output of ps is used to determine if the tests should exit, this causes some problems? I suspect a recent update to cygwin, but haven?t been able to confirm that. > > This change stops using ps on cygwin and instead uses the builtin tasklist program on windows. > > I have also removed some old supporting code for Windows 98 (!). > > Tested by running the jdi tests over and over locally many times and also in jprt. > > webrev: http://cr.openjdk.java.net/~sla/8038963/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038963 > > Thanks, > /Staffan From serguei.spitsyn at oracle.com Fri Apr 11 19:49:18 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 11 Apr 2014 12:49:18 -0700 Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated" In-Reply-To: <534800B1.5060201@oracle.com> References: <534800B1.5060201@oracle.com> Message-ID: <5348473E.3070701@oracle.com> The fix looks good. Thanks, Serguei On 4/11/14 7:48 AM, Coleen Phillimore wrote: > Summary: Dtrace monitoring uses size before mirror size is set. > > The refactoring I did for bug > https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The > size of the mirror is filled in by the InstanceMirrorKlass allocation > but was used for dtrace probes before it in the normal allocation > pass. Pass the allocated size to dtrace function instead. > > Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist > also. > > open webrev at http://cr.openjdk.java.net/~coleenp/8039904/ > bug link https://bugs.openjdk.java.net/browse/JDK-8039904 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Apr 11 20:42:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Apr 2014 16:42:42 -0400 Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with "assert(s > 0) failed: Bad size calculated" In-Reply-To: <5348473E.3070701@oracle.com> References: <534800B1.5060201@oracle.com> <5348473E.3070701@oracle.com> Message-ID: <534853C2.60007@oracle.com> Thank you Serguei. Coleen On 4/11/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: > The fix looks good. > > Thanks, > Serguei > > On 4/11/14 7:48 AM, Coleen Phillimore wrote: >> Summary: Dtrace monitoring uses size before mirror size is set. >> >> The refactoring I did for bug >> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The >> size of the mirror is filled in by the InstanceMirrorKlass allocation >> but was used for dtrace probes before it in the normal allocation >> pass. Pass the allocated size to dtrace function instead. >> >> Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist >> also. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8039904 >> >> Thanks, >> Coleen > From Alan.Bateman at oracle.com Mon Apr 14 15:17:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Apr 2014 16:17:59 +0100 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> Message-ID: <534BFC27.6000206@oracle.com> On 03/04/2014 15:23, Staffan Larsen wrote: > All, > > In the attach framework, the result is sent back to the attaching process as a stream. The first value in the stream is an integer that is interpreted as the completion status. For successful operations, this value is 0. In that case the attaching process continues to read output from the stream and displays that as the result of the operation. > > When the completion status signals an error, the rest of the stream output is ignored. This means that there is currently no way for an attach operation to signal an error and provide an error message. > > : > > At a later stage, I am planning to change the hotspot code so that exceptions in Diagnostic Commands actually set the completion status to an error. Today, the completation status is set to success, just because we want the error message to propagate. > > bug: https://bugs.openjdk.java.net/browse/JDK-8039173 > webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.00/ > For someone looking at the Virtualmachine API then I don't think the javadoc is clear enough to understand when one might get the specific AttachOperationFailedException vs. the more general IOException. I think it means that there was communication with the target VM but that the operation failed for some reason but I don't think this will be obvious to the reader. For the new exception then it would be good to add @since and also a copyright header. Sorry I don't have time to look at the implementation at this time. -Alan. From jaroslav.bachorik at oracle.com Tue Apr 15 08:21:56 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Apr 2014 10:21:56 +0200 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS Message-ID: <534CEC24.5000907@oracle.com> Please, review this simple doc change. Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ Currently, the generated JDWP documentation falsely states that the InvokeMethod command "Invokes a static method. The method must be member of the class type or one of its superclasses, *superinterfaces*, or implemented interfaces." Up till JDK8 this was almost non-problem since interfaces could not specify static methods. For JDK8 this brings in ambiguity and contradicts JLS. The JDI docs (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) state correctly that the InvokeMethod can be uses only on static methods from the class or its superclasses (no mention of interface) - following the JLS (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) rules. The fix is to change the line to read "Invokes a static method. The method must be member of the class type or one of its superclasses." instead. Thanks, -JB- From serguei.spitsyn at oracle.com Tue Apr 15 09:20:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 15 Apr 2014 02:20:04 -0700 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS In-Reply-To: <534CEC24.5000907@oracle.com> References: <534CEC24.5000907@oracle.com> Message-ID: <534CF9C4.30105@oracle.com> Reviewed. Thanks, Serguei On 4/15/14 1:21 AM, Jaroslav Bachorik wrote: > Please, review this simple doc change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 > Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ > > Currently, the generated JDWP documentation falsely states that the > InvokeMethod command > "Invokes a static method. The method must be member of the class type > or one of its superclasses, > *superinterfaces*, or implemented interfaces." > > Up till JDK8 this was almost non-problem since interfaces could not > specify static methods. For JDK8 this brings in ambiguity and > contradicts JLS. > > The JDI docs > (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) > state correctly that the InvokeMethod can be uses only on static > methods from the class or its superclasses (no mention of interface) - > following the JLS > (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) rules. > > > The fix is to change the line to read > "Invokes a static method. The method must be member of the class type > or one of its superclasses." instead. > > Thanks, > > -JB- From staffan.larsen at oracle.com Tue Apr 15 09:21:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Apr 2014 11:21:26 +0200 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS In-Reply-To: <534CEC24.5000907@oracle.com> References: <534CEC24.5000907@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 15 apr 2014, at 10:21, Jaroslav Bachorik wrote: > Please, review this simple doc change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 > Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ > > Currently, the generated JDWP documentation falsely states that the InvokeMethod command > "Invokes a static method. The method must be member of the class type or one of its superclasses, > *superinterfaces*, or implemented interfaces." > > Up till JDK8 this was almost non-problem since interfaces could not specify static methods. For JDK8 this brings in ambiguity and contradicts JLS. > > The JDI docs (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) state correctly that the InvokeMethod can be uses only on static methods from the class or its superclasses (no mention of interface) - following the JLS (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) rules. > > The fix is to change the line to read > "Invokes a static method. The method must be member of the class type or one of its superclasses." instead. > > Thanks, > > -JB- From david.holmes at oracle.com Tue Apr 15 09:43:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Apr 2014 19:43:59 +1000 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS In-Reply-To: <534CEC24.5000907@oracle.com> References: <534CEC24.5000907@oracle.com> Message-ID: <534CFF5F.9070008@oracle.com> Jaroslav, Even though a seemingly trivial correction this needs a CCC request. David On 15/04/2014 6:21 PM, Jaroslav Bachorik wrote: > Please, review this simple doc change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 > Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ > > Currently, the generated JDWP documentation falsely states that the > InvokeMethod command > "Invokes a static method. The method must be member of the class type or > one of its superclasses, > *superinterfaces*, or implemented interfaces." > > Up till JDK8 this was almost non-problem since interfaces could not > specify static methods. For JDK8 this brings in ambiguity and > contradicts JLS. > > The JDI docs > (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) > state correctly that the InvokeMethod can be uses only on static methods > from the class or its superclasses (no mention of interface) - following > the JLS > (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) > rules. > > The fix is to change the line to read > "Invokes a static method. The method must be member of the class type or > one of its superclasses." instead. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Apr 15 09:49:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Apr 2014 11:49:31 +0200 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS In-Reply-To: <534CFF5F.9070008@oracle.com> References: <534CEC24.5000907@oracle.com> <534CFF5F.9070008@oracle.com> Message-ID: <534D00AB.1010205@oracle.com> Bummer .. I've already pushed the JDK9 fix. I didn't realize the CCC was necessary when fixing obviously incorrect doc. Sorry :( I will ask for CCC review ASAP. -JB- On 15.4.2014 11:43, David Holmes wrote: > Jaroslav, > > Even though a seemingly trivial correction this needs a CCC request. > > David > > On 15/04/2014 6:21 PM, Jaroslav Bachorik wrote: >> Please, review this simple doc change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ >> >> Currently, the generated JDWP documentation falsely states that the >> InvokeMethod command >> "Invokes a static method. The method must be member of the class type or >> one of its superclasses, >> *superinterfaces*, or implemented interfaces." >> >> Up till JDK8 this was almost non-problem since interfaces could not >> specify static methods. For JDK8 this brings in ambiguity and >> contradicts JLS. >> >> The JDI docs >> (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) >> >> state correctly that the InvokeMethod can be uses only on static methods >> from the class or its superclasses (no mention of interface) - following >> the JLS >> (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) >> rules. >> >> The fix is to change the line to read >> "Invokes a static method. The method must be member of the class type or >> one of its superclasses." instead. >> >> Thanks, >> >> -JB- From yunda.mly at taobao.com Tue Apr 15 09:54:38 2014 From: yunda.mly at taobao.com (=?GBK?B?w7fCt41pKNTGtO8p?=) Date: Tue, 15 Apr 2014 17:54:38 +0800 Subject: Missing ResourceMark in TraceStream::print_val() Message-ID: Hi all, In TraceStream::print_val(const char* label, const Klass* const val) and TraceStream::print_val(const char* label, const Method* const val), Symbol::as_C_string() and Method::name_and_sig_as_C_string() are called in line 93 and 106 of traceStream.hpp , respectively. Since they both use NEW_RESOURCE_ARRAY to allocate memory, I think ResourceMark should be used. Please see the patch below: diff -r 4dedef5e51ed src/share/vm/trace/traceStream.hpp --- a/src/share/vm/trace/traceStream.hpp Fri Apr 11 11:23:30 2014 -0700 +++ b/src/share/vm/trace/traceStream.hpp Tue Apr 15 15:50:31 2014 +0800 @@ -86,6 +86,7 @@ // necessary ResourceMark for the resource allocations below. // See traceEventClasses.xsl for details. void print_val(const char* label, const Klass* const val) { + ResourceMark rm; const char* description = "NULL"; if (val != NULL) { Symbol* name = val->name(); @@ -101,6 +102,7 @@ // necessary ResourceMark for the resource allocations below. // See traceEventClasses.xsl for details. void print_val(const char* label, const Method* const val) { + ResourceMark rm; const char* description = "NULL"; if (val != NULL) { description = val->name_and_sig_as_C_string(); Regards, Yunda -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Apr 15 10:57:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Apr 2014 12:57:40 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <5343DE03.7060904@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> <534298CC.2050608@oracle.com> <53429950.5000806@oracle.com> <5343DE03.7060904@oracle.com> Message-ID: <534D10A4.2090102@oracle.com> Hi, On 8.4.2014 13:31, Jaroslav Bachorik wrote: > On 7.4.2014 14:25, Jaroslav Bachorik wrote: >> On 7.4.2014 14:23, shanliang wrote: >>> shanliang wrote: >>>> Jaroslav, >>>> >>>> Is it necessary to add "ValidationException"? > > Replaced the custom ValidationException with IllegalArgumentException() > to remove an unnecessary inner class. > > http://cr.openjdk.java.net/~jbachorik/8039080/webrev.02 Could I get the latest changes reviewed, please? Thanks, -JB- > > -JB- > >>>> >>>> Could we change the constructor JInfo to: >>>> private static boolean validateArgs(String[] args); >>>> the method returns false if the args are illegal, or throw an >>>> IllegalArgumentException >>>> >>>> and declare the variables "args" and "useSA" as static too, >>> Static variables may have problem if called with multi-thread, but we >>> still could do: >>> >>> private static Map validate(String[] args) throws >>> IllegalArgumentException; >>> >>> the return map contains args(String[]) and useSA(boolean). >> >> ... or just keep them as instance variables. >> >> -JB- >> >>> >>> Or put "USE_SA" as a new arg into the args list, then the method >>> becomes: >>> private static String[] validate(String[] args) throws >>> IllegalArgumentException; >>> >>> Shanliang >>> >>>> >>>> Shanliang >>>> >>>> Jaroslav Bachorik wrote: >>>>> Hi, >>>>> >>>>> Sorry for the noise but I need to get the fix re-reviewed. >>>>> Due to the way jtreg cooperates with TestNG when runnning in agentvm >>>>> I can not use package private methods or constructor or fields. >>>>> >>>>> The updated patch - >>>>> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >>>>> JInfo constructor a private one and removes the package private >>>>> getters. The test is using reflection to create new instances of >>>>> JInfo and to assert its state. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From staffan.larsen at oracle.com Tue Apr 15 10:57:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Apr 2014 12:57:53 +0200 Subject: Missing ResourceMark in TraceStream::print_val() In-Reply-To: References: Message-ID: <4EFB81DA-2375-4502-902A-07AA49423A22@oracle.com> The comment in code to says that the necessary ResourceMark is in the generated code: // Caller is machine generated code located in traceEventClasses.hpp // Event::writeEvent() (pseudocode) contains the // necessary ResourceMark for the resource allocations below. // See traceEventClasses.xsl for details. void print_val(const char* label, const Klass* const val) { /Staffan On 15 apr 2014, at 11:54, ???(??) wrote: > Hi all, > > In TraceStream::print_val(const char* label, const Klass* const val) and TraceStream::print_val(const char* label, const Method* const val), Symbol::as_C_string() and Method::name_and_sig_as_C_string() are called in line 93 and 106 of traceStream.hpp, respectively. Since they both use NEW_RESOURCE_ARRAY to allocate memory, I think ResourceMark should be used. Please see the patch below: > > diff -r 4dedef5e51ed src/share/vm/trace/traceStream.hpp > --- a/src/share/vm/trace/traceStream.hpp Fri Apr 11 11:23:30 2014 -0700 > +++ b/src/share/vm/trace/traceStream.hpp Tue Apr 15 15:50:31 2014 +0800 > @@ -86,6 +86,7 @@ > // necessary ResourceMark for the resource allocations below. > // See traceEventClasses.xsl for details. > void print_val(const char* label, const Klass* const val) { > + ResourceMark rm; > const char* description = "NULL"; > if (val != NULL) { > Symbol* name = val->name(); > @@ -101,6 +102,7 @@ > // necessary ResourceMark for the resource allocations below. > // See traceEventClasses.xsl for details. > void print_val(const char* label, const Method* const val) { > + ResourceMark rm; > const char* description = "NULL"; > if (val != NULL) { > description = val->name_and_sig_as_C_string(); > > > > Regards, > Yunda -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Apr 15 11:03:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Apr 2014 13:03:59 +0200 Subject: RFR 8039080: "jinfo server_id@host" fails with "Invalid process identifier" In-Reply-To: <534D10A4.2090102@oracle.com> References: <533D45A2.4040300@oracle.com> <533D4F45.4010701@oracle.com> <533D51F5.8090008@oracle.com> <883C85C3-0A4F-4C6F-B959-29362A694960@oracle.com> <533D586C.6090901@oracle.com> <709C73F9-8C51-49F5-A7EB-6D709367205E@oracle.com> <534281EB.1090102@oracle.com> <534295CE.70603@oracle.com> <534298CC.2050608@oracle.com> <53429950.5000806@oracle.com> <5343DE03.7060904@oracle.com> <534D10A4.2090102@oracle.com> Message-ID: Good to me, /Staffan On 15 apr 2014, at 12:57, Jaroslav Bachorik wrote: > Hi, > > On 8.4.2014 13:31, Jaroslav Bachorik wrote: >> On 7.4.2014 14:25, Jaroslav Bachorik wrote: >>> On 7.4.2014 14:23, shanliang wrote: >>>> shanliang wrote: >>>>> Jaroslav, >>>>> >>>>> Is it necessary to add "ValidationException"? >> >> Replaced the custom ValidationException with IllegalArgumentException() >> to remove an unnecessary inner class. >> >> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.02 > > Could I get the latest changes reviewed, please? > > Thanks, > > -JB- > >> >> -JB- >> >>>>> >>>>> Could we change the constructor JInfo to: >>>>> private static boolean validateArgs(String[] args); >>>>> the method returns false if the args are illegal, or throw an >>>>> IllegalArgumentException >>>>> >>>>> and declare the variables "args" and "useSA" as static too, >>>> Static variables may have problem if called with multi-thread, but we >>>> still could do: >>>> >>>> private static Map validate(String[] args) throws >>>> IllegalArgumentException; >>>> >>>> the return map contains args(String[]) and useSA(boolean). >>> >>> ... or just keep them as instance variables. >>> >>> -JB- >>> >>>> >>>> Or put "USE_SA" as a new arg into the args list, then the method >>>> becomes: >>>> private static String[] validate(String[] args) throws >>>> IllegalArgumentException; >>>> >>>> Shanliang >>>> >>>>> >>>>> Shanliang >>>>> >>>>> Jaroslav Bachorik wrote: >>>>>> Hi, >>>>>> >>>>>> Sorry for the noise but I need to get the fix re-reviewed. >>>>>> Due to the way jtreg cooperates with TestNG when runnning in agentvm >>>>>> I can not use package private methods or constructor or fields. >>>>>> >>>>>> The updated patch - >>>>>> http://cr.openjdk.java.net/~jbachorik/8039080/webrev.01 - makes the >>>>>> JInfo constructor a private one and removes the package private >>>>>> getters. The test is using reflection to create new instances of >>>>>> JInfo and to assert its state. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From yunda.mly at taobao.com Tue Apr 15 15:01:50 2014 From: yunda.mly at taobao.com (=?GBK?B?w7fCt41pKNTGtO8p?=) Date: Tue, 15 Apr 2014 23:01:50 +0800 Subject: Missing ResourceMark in TraceStream::print_val() In-Reply-To: <4EFB81DA-2375-4502-902A-07AA49423A22@oracle.com> Message-ID: Hi Staffan, Thanks for pointing this out. How can I be so blind? Regards, Yunda ???: Staffan Larsen ??: 2014?4?15? ??? ??6:57 ?: Luyao Mei ??: "serviceability-dev at openjdk.java.net" ??: Re: Missing ResourceMark in TraceStream::print_val() The comment in code to says that the necessary ResourceMark is in the generated code: // Caller is machine generated code located in traceEventClasses.hpp // Event::writeEvent() (pseudocode) contains the // necessary ResourceMark for the resource allocations below. // See traceEventClasses.xsl for details. void print_val(const char* label, const Klass* const val) { /Staffan On 15 apr 2014, at 11:54, ???(??) wrote: > Hi all, > > In TraceStream::print_val(const char* label, const Klass* const val) and > TraceStream::print_val(const char* label, const Method* const val), > Symbol::as_C_string() and Method::name_and_sig_as_C_string() are called in > line 93 and 106 of traceStream.hpp > race/traceStream.hpp> , respectively. Since they both use NEW_RESOURCE_ARRAY > to allocate memory, I think ResourceMark should be used. Please see the patch > below: > > diff -r 4dedef5e51ed src/share/vm/trace/traceStream.hpp > --- a/src/share/vm/trace/traceStream.hpp Fri Apr 11 11:23:30 2014 -0700 > +++ b/src/share/vm/trace/traceStream.hpp Tue Apr 15 15:50:31 2014 +0800 > @@ -86,6 +86,7 @@ > // necessary ResourceMark for the resource allocations below. > // See traceEventClasses.xsl for details. > void print_val(const char* label, const Klass* const val) { > + ResourceMark rm; > const char* description = "NULL"; > if (val != NULL) { > Symbol* name = val->name(); > @@ -101,6 +102,7 @@ > // necessary ResourceMark for the resource allocations below. > // See traceEventClasses.xsl for details. > void print_val(const char* label, const Method* const val) { > + ResourceMark rm; > const char* description = "NULL"; > if (val != NULL) { > description = val->name_and_sig_as_C_string(); > > > > Regards, > Yunda -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Apr 16 09:21:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Apr 2014 11:21:42 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <534BFC27.6000206@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> Message-ID: <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> On 14 apr 2014, at 17:17, Alan Bateman wrote: > On 03/04/2014 15:23, Staffan Larsen wrote: >> All, >> >> In the attach framework, the result is sent back to the attaching process as a stream. The first value in the stream is an integer that is interpreted as the completion status. For successful operations, this value is 0. In that case the attaching process continues to read output from the stream and displays that as the result of the operation. >> >> When the completion status signals an error, the rest of the stream output is ignored. This means that there is currently no way for an attach operation to signal an error and provide an error message. >> >> : >> >> At a later stage, I am planning to change the hotspot code so that exceptions in Diagnostic Commands actually set the completion status to an error. Today, the completation status is set to success, just because we want the error message to propagate. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8039173 >> webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.00/ >> > For someone looking at the Virtualmachine API then I don't think the javadoc is clear enough to understand when one might get the specific AttachOperationFailedException vs. the more general IOException. I think it means that there was communication with the target VM but that the operation failed for some reason but I don't think this will be obvious to the reader. I have tried to clarify the wording in the javadoc. Suggestions for improvements are welcome. > > For the new exception then it would be good to add @since and also a copyright header. Fixed. new webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.04/ Thanks, /Staffan > > Sorry I don't have time to look at the implementation at this time. > > -Alan. > From mattias.tobiasson at oracle.com Wed Apr 16 13:17:25 2014 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 16 Apr 2014 06:17:25 -0700 (PDT) Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Message-ID: <0a01cb4e-2978-4ed5-9f94-21cba08e3735@default> Hi Mandy, Could you please sponsor this attached patch. It has been updated with all review comments. jcheck is ok, except for missing reviewer. webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04 bug: https://bugs.openjdk.java.net/browse/JDK-8030628 repositry: http://hg.openjdk.java.net/jdk9/dev/jdk Mattias ----- Original Message ----- From: mattias.tobiasson at oracle.com To: serviceability-dev at openjdk.java.net Sent: Friday, April 4, 2014 2:12:51 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Hi, I have updated the patch with the following changes: Util.java line 130 - Moved Pattern from function to "private static final" RunUtil.java line 64 - Use diamond operator. webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04 I have created an enhancement for porting the other shell scripts to java (https://bugs.openjdk.java.net/browse/JDK-8039257) Mattias ----- Original Message ----- From: mandy.chung at oracle.com To: mattias.tobiasson at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Wednesday, April 2, 2014 12:22:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing Hi Mattias, On 4/1/14 3:11 AM, Mattias Tobiasson wrote: > Hi Mandy, > I have moved the common code to a new utility class. Thanks for the refactoring. Looks much better. Nit: RunUtil.java line 64 - you can use diamond operator. No need to generate a new webrev. > > The shell script tests work as they are, they do not fail. > The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. > Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. > We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. Can you file a bug to replace the shell script tests with the new RunUtil class? @requires could be done independent with the shell script test conversion. thanks Mandy > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net > Cc: leonid.mesnik at oracle.com > Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: >> Hi, >> I have updated the patch to include all failing tests for this bug. >> >> The tests currently fail because their GC options collide with GC options from the test framework. >> The fix will launch the tests in a separate JVM with controlled GC options. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > Thanks for updating other failing tests. I think we are not sure when > the proper configuration support is in place and this temporary solution > to allow the tests to run is reasonable. > > It'd be better to refactor the common code to launch the test with all > GC configurations shared by jdk/test/java/lang/management/MemoryMXBean > tests. > > There are other shell tests that can be removed if the corresponding > java tests are modified to use your utility class. It's probably out > of the scope of this fix. Do you have cycles to clean them up as well? > They probably fail in VM nightlies like the ones you fixed if it > overrides with a different GC. > > LowMemoryTest2.sh > MemoryManagementParallelGC.sh > MemoryManagementConcMarkSweepGC.sh > MemoryManagementSerialGC.sh > PendingAllGC.sh > > Mandy > >> Mattias >> >> >> ----- Original Message ----- >> From: mattias.tobiasson at oracle.com >> To: mandy.chung at oracle.com >> Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com >> Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mandy, >> I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. >> >> I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. >> >> I did not notice that there are more tests in the same dir. I will change them too. >> >> Mattias >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com >> Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mattias, >> >> Have you discussed with Jon Gibbons about the jtreg @requires support? >> I thought it was partly motivated by the requirement to specify a test >> to run in different collector. >> >> The reason why these regression tests explicitly specifies different GC >> flags was to increase the coverage and ensure to catch regression early >> during development cycle. At that time, the VM nightly testing rotates >> the test execution with different GC configuration that delayed to catch >> a regression that occurs in one collector while the nightly testing is >> testing another collector. For integration, I don't recall if different >> collectors are tested rather than default. It may be time to revisit >> the test execution with different collectors. If the verification of >> different collectors is well covered in nightly, perhaps these tests no >> longer need one @run per each collector. >> >> There are other regression tests that specifies the -XX:+UseXXGC flag in >> the @run tag. It makes sense to modify them in the same patch (perhaps >> at least tests under test/java/lang/management). >> >> Mandy >> >> On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >>> Hi, >>> Could you please review this test fix. >>> >>> The test fails because it specifies its own GC command line options, for example: >>> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >>> >>> When the framework also specifies GC version, then the test will fail with this log: >>> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >>> >>> The solution is to run the test in a separate JVM with controlled GC options. >>> The test will be run multiple times. >>> First with the command line specified from the framework, without test specific GC options. >>> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >>> >>> Mattias >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: 8030628.diff Type: text/x-patch Size: 25079 bytes Desc: not available URL: From daniel.daugherty at oracle.com Wed Apr 16 14:58:35 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Apr 2014 08:58:35 -0600 Subject: RFR 8040167: JDWP spec for ClassType#InvokeMethod contradicts JLS In-Reply-To: <534D00AB.1010205@oracle.com> References: <534CEC24.5000907@oracle.com> <534CFF5F.9070008@oracle.com> <534D00AB.1010205@oracle.com> Message-ID: <534E9A9B.7070006@oracle.com> Also, docs are not normally updated in Update releases. If you need this updated doc pushed to the web, then you'll need to contact the docs folks. Dan On 4/15/14 3:49 AM, Jaroslav Bachorik wrote: > Bummer .. I've already pushed the JDK9 fix. > I didn't realize the CCC was necessary when fixing obviously incorrect > doc. Sorry :( > > I will ask for CCC review ASAP. > > -JB- > > On 15.4.2014 11:43, David Holmes wrote: >> Jaroslav, >> >> Even though a seemingly trivial correction this needs a CCC request. >> >> David >> >> On 15/04/2014 6:21 PM, Jaroslav Bachorik wrote: >>> Please, review this simple doc change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8040167 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8040167/webrev.00/ >>> >>> Currently, the generated JDWP documentation falsely states that the >>> InvokeMethod command >>> "Invokes a static method. The method must be member of the class >>> type or >>> one of its superclasses, >>> *superinterfaces*, or implemented interfaces." >>> >>> Up till JDK8 this was almost non-problem since interfaces could not >>> specify static methods. For JDK8 this brings in ambiguity and >>> contradicts JLS. >>> >>> The JDI docs >>> (http://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/ClassType.html#invokeMethod-com.sun.jdi.ThreadReference-com.sun.jdi.Method-java.util.List-int-) >>> >>> >>> state correctly that the InvokeMethod can be uses only on static >>> methods >>> from the class or its superclasses (no mention of interface) - >>> following >>> the JLS >>> (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.8) >>> rules. >>> >>> The fix is to change the line to read >>> "Invokes a static method. The method must be member of the class >>> type or >>> one of its superclasses." instead. >>> >>> Thanks, >>> >>> -JB- > From mikael.auno at oracle.com Wed Apr 16 17:50:49 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 16 Apr 2014 19:50:49 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore Message-ID: <534EC2F9.9000305@oracle.com> Please, review the following fix adding the @ignore tag to a couple of serviceability tests Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ Thanks, Mikael From mandy.chung at oracle.com Wed Apr 16 20:10:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 16 Apr 2014 13:10:00 -0700 Subject: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing In-Reply-To: <0a01cb4e-2978-4ed5-9f94-21cba08e3735@default> References: <0a01cb4e-2978-4ed5-9f94-21cba08e3735@default> Message-ID: <534EE398.3000903@oracle.com> Hi Mattias, Sorry for the delay. I just pushed the changeset. Mandy On 4/16/2014 6:17 AM, Mattias Tobiasson wrote: > Hi Mandy, > Could you please sponsor this attached patch. > It has been updated with all review comments. > jcheck is ok, except for missing reviewer. > > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04 > bug: https://bugs.openjdk.java.net/browse/JDK-8030628 > repositry: http://hg.openjdk.java.net/jdk9/dev/jdk > > Mattias > > ----- Original Message ----- > From: mattias.tobiasson at oracle.com > To: serviceability-dev at openjdk.java.net > Sent: Friday, April 4, 2014 2:12:51 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi, > I have updated the patch with the following changes: > Util.java line 130 - Moved Pattern from function to "private static final" > RunUtil.java line 64 - Use diamond operator. > > webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04 > > I have created an enhancement for porting the other > shell scripts to java (https://bugs.openjdk.java.net/browse/JDK-8039257) > > Mattias > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: mattias.tobiasson at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Wednesday, April 2, 2014 12:22:43 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing > > Hi Mattias, > > On 4/1/14 3:11 AM, Mattias Tobiasson wrote: >> Hi Mandy, >> I have moved the common code to a new utility class. > Thanks for the refactoring. Looks much better. > > Nit: RunUtil.java line 64 - you can use diamond operator. No need to > generate a new webrev. > >> The shell script tests work as they are, they do not fail. >> The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}. >> Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests. > >> We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg. > Can you file a bug to replace the shell script tests with the new > RunUtil class? @requires could be done independent with the shell > script test conversion. > > thanks > Mandy > >> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03 >> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >> >> Mattias >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net >> Cc: leonid.mesnik at oracle.com >> Sent: Wednesday, March 19, 2014 6:45:27 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >> >> Hi Mattias, >> >> On 3/14/2014 6:21 AM, Mattias Tobiasson wrote: >>> Hi, >>> I have updated the patch to include all failing tests for this bug. >>> >>> The tests currently fail because their GC options collide with GC options from the test framework. >>> The fix will launch the tests in a separate JVM with controlled GC options. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >> Thanks for updating other failing tests. I think we are not sure when >> the proper configuration support is in place and this temporary solution >> to allow the tests to run is reasonable. >> >> It'd be better to refactor the common code to launch the test with all >> GC configurations shared by jdk/test/java/lang/management/MemoryMXBean >> tests. >> >> There are other shell tests that can be removed if the corresponding >> java tests are modified to use your utility class. It's probably out >> of the scope of this fix. Do you have cycles to clean them up as well? >> They probably fail in VM nightlies like the ones you fixed if it >> overrides with a different GC. >> >> LowMemoryTest2.sh >> MemoryManagementParallelGC.sh >> MemoryManagementConcMarkSweepGC.sh >> MemoryManagementSerialGC.sh >> PendingAllGC.sh >> >> Mandy >> >>> Mattias >>> >>> >>> ----- Original Message ----- >>> From: mattias.tobiasson at oracle.com >>> To: mandy.chung at oracle.com >>> Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com >>> Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >>> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >>> >>> Hi Mandy, >>> I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix. >>> >>> I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second. >>> >>> I did not notice that there are more tests in the same dir. I will change them too. >>> >>> Mattias >>> >>> ----- Original Message ----- >>> From: mandy.chung at oracle.com >>> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com >>> Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna >>> Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing >>> >>> Hi Mattias, >>> >>> Have you discussed with Jon Gibbons about the jtreg @requires support? >>> I thought it was partly motivated by the requirement to specify a test >>> to run in different collector. >>> >>> The reason why these regression tests explicitly specifies different GC >>> flags was to increase the coverage and ensure to catch regression early >>> during development cycle. At that time, the VM nightly testing rotates >>> the test execution with different GC configuration that delayed to catch >>> a regression that occurs in one collector while the nightly testing is >>> testing another collector. For integration, I don't recall if different >>> collectors are tested rather than default. It may be time to revisit >>> the test execution with different collectors. If the verification of >>> different collectors is well covered in nightly, perhaps these tests no >>> longer need one @run per each collector. >>> >>> There are other regression tests that specifies the -XX:+UseXXGC flag in >>> the @run tag. It makes sense to modify them in the same patch (perhaps >>> at least tests under test/java/lang/management). >>> >>> Mandy >>> >>> On 3/11/14 6:15 AM, Mattias Tobiasson wrote: >>>> Hi, >>>> Could you please review this test fix. >>>> >>>> The test fails because it specifies its own GC command line options, for example: >>>> @run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC CollectionUsageThreshold >>>> >>>> When the framework also specifies GC version, then the test will fail with this log: >>>> "Conflicting collector combinations in option list; Error: Could not create the Java Virtual Machine." >>>> >>>> The solution is to run the test in a separate JVM with controlled GC options. >>>> The test will be run multiple times. >>>> First with the command line specified from the framework, without test specific GC options. >>>> Then once for each GC version specified in the test. When the test specifies the GC, any GC options from the framework are removed. >>>> >>>> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030628 >>>> >>>> Mattias >>>> From vladimir.kempik at oracle.com Thu Apr 17 11:47:48 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 17 Apr 2014 15:47:48 +0400 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary Message-ID: <534FBF64.1010906@oracle.com> Hello Please review this patch. We've recently backported changes to testlibrary from jdk8 to jdk7 and now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already has these tests, it's only hotspot that missing them. Its partially backport of 8024677, but I don't remove old files and don't edit TEST.groups as these files don't exist in jdk7/hotspot. I want to push these changes as backport of 8024677 to jdk7/hotspot, but since I've removed part of original patch (as mentioned before) I think I need to get a review. Original fix: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ Thanks. Vladimir. From stefan.sarne at oracle.com Tue Apr 22 15:12:38 2014 From: stefan.sarne at oracle.com (=?iso-8859-1?B?U3RlZmFuIFPkcm5l?=) Date: Tue, 22 Apr 2014 08:12:38 -0700 (PDT) Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore In-Reply-To: <534EC2F9.9000305@oracle.com> References: <534EC2F9.9000305@oracle.com> Message-ID: <9178805f-7014-45ae-9c16-884c282dd045@default> Hi Mikael, I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: @key quarantine Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. Best regards, Stefan -----Original Message----- From: Mikael Auno Sent: den 16 april 2014 19:51 To: serviceability-dev at openjdk.java.net Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore Please, review the following fix adding the @ignore tag to a couple of serviceability tests Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ Thanks, Mikael From dmitry.samersoff at oracle.com Wed Apr 23 15:03:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Apr 2014 19:03:49 +0400 Subject: RFR(M): JDK-8041498 Remove npt library Message-ID: <5357D655.7090600@oracle.com> Hi Everybody, Please review the fix that removes npt library from jdk. CR link: https://bugs.openjdk.java.net/browse/JDK-8041498 Webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8041498/webrev.01/ Testing: nsk.jdwp I plan to submit a separate aurora run when I get all concerns. Fix details: * Today libnpt is a set of UTF related function and only few of them is actually used. The only users of npt is JDWP and hprof. So it's not necessary to keep it as a separate library. * Relevant code moved from npt to src/share/back/utf_util.c platfrom specific part is under #ifdef _WINDOWS initialization step is removed. * hprof changed to don't do any conversion. The only place where hrpof care about encoding is an output filename. Conversion from platform to UTF8 assume that filesystem does support UTF8 but command line doesn't. This assumption is obviously not correct in all cases and therefore handling of non-ascii filenames is incomplete. We should file a separate RFE if we need to handle no-ascii filenames by hprof. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From vladimir.kempik at oracle.com Wed Apr 23 16:20:59 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 23 Apr 2014 20:20:59 +0400 Subject: RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary In-Reply-To: <534FBF64.1010906@oracle.com> References: <534FBF64.1010906@oracle.com> Message-ID: <5357E86B.8010104@oracle.com> Hello Can I have a couple of reviews for this please? Thanks. On 17.04.2014 15:47, Vladimir Kempik wrote: > Hello > > Please review this patch. > We've recently backported changes to testlibrary from jdk8 to jdk7 and > now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already > has these tests, it's only hotspot that missing them. > Its partially backport of 8024677, but I don't remove old files and > don't edit TEST.groups as these files don't exist in jdk7/hotspot. > I want to push these changes as backport of 8024677 to jdk7/hotspot, > but since I've removed part of original patch (as mentioned before) I > think I need to get a review. > > Original fix: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b > Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/ > > Thanks. Vladimir. From daniel.daugherty at oracle.com Wed Apr 23 20:16:58 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Apr 2014 14:16:58 -0600 Subject: sawindbg.dll - compilation option for debugging support in Java6 In-Reply-To: <53581BDB.6010409@Oracle.COM> References: <53581BDB.6010409@Oracle.COM> Message-ID: <53581FBA.10604@oracle.com> Adding Serviceability to the thread since this is SA (Serviceability Agent) code... Dan On 4/23/14 2:00 PM, Miroslaw Niemiec wrote: > > Hi, > > In Java6 hotspot > I have change compilation option for sawindbg.dll > from /ZI (enable Edit and Continue debug info) > to /Zi (enable debugging information) > > in order to force Visual Studio 2003 (Java6) > include a table of safe exceptions handlers in sawindbg.dll. > > While working on: > https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=18420609 > > > > Can anyone evaluate this fix: > https://java.se.oracle.com/code/cru/CR-JDK6UCPU-329 > > if this option change won't break SA functionality > > > Thank you > Miroslaw From staffan.larsen at oracle.com Thu Apr 24 09:52:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Apr 2014 11:52:28 +0200 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <5357D655.7090600@oracle.com> References: <5357D655.7090600@oracle.com> Message-ID: <2BF3D28F-5553-4E61-AE11-EED5DDDCFDD8@oracle.com> Dmitry, src/share/demo/jvmti/hprof/hprof_init.c L743-744: Indentation looks wrong src/share/back/utf_util.h L1: Missing copyright header. L14: UTF_ERROR and UTF_ASSERT are only used in utf_util.c, so they can be defined in that file instead of the header file. src/share/back/utf_util.c L297: Wouldn?t it make sense to cache the result of getCodepage() in a static variable so we don?t need to call this code for each UTF conversion? L492: skeep -> skip L492: This TODO should be fixed. I also have the same worry here as for the windows code: that we should cache data so that we don?t run this unnecessarily. In the original code we did: /* Set the locale from the environment */ (void)setlocale(LC_ALL, "?); but that is missing from the new code. I don?t know if it matters? Thanks, /Staffan On 23 apr 2014, at 17:03, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the fix that removes npt library from jdk. > > CR link: > > https://bugs.openjdk.java.net/browse/JDK-8041498 > > Webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8041498/webrev.01/ > > > Testing: > > nsk.jdwp > > I plan to submit a separate aurora run when I get all concerns. > > Fix details: > > * Today libnpt is a set of UTF related function and only few of them is > actually used. The only users of npt is JDWP and hprof. So it's not > necessary to keep it as a separate library. > > * Relevant code moved from npt to src/share/back/utf_util.c > platfrom specific part is under #ifdef _WINDOWS initialization step > is removed. > > * hprof changed to don't do any conversion. > > The only place where hrpof care about encoding is an output > filename. Conversion from platform to UTF8 assume that > filesystem does support UTF8 but command line doesn't. > This assumption is obviously not correct in all cases and > therefore handling of non-ascii filenames is incomplete. > We should file a separate RFE if we need to handle no-ascii > filenames by hprof. > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu Apr 24 10:43:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Apr 2014 11:43:39 +0100 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <5357D655.7090600@oracle.com> References: <5357D655.7090600@oracle.com> Message-ID: <5358EADB.5030608@oracle.com> On 23/04/2014 16:03, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the fix that removes npt library from jdk. > No objection to removing the npt library but what is the motivation? -Alan. From dmitry.samersoff at oracle.com Thu Apr 24 11:34:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Apr 2014 15:34:40 +0400 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <5358EADB.5030608@oracle.com> References: <5357D655.7090600@oracle.com> <5358EADB.5030608@oracle.com> Message-ID: <5358F6D0.8090205@oracle.com> Alan, > No objection to removing the npt library but what is the motivation? It's the part of the test stabilization. Next step is revisit UTF8 usage in JDWP and fix related tests when necessary. -Dmitry On 2014-04-24 14:43, Alan Bateman wrote: > On 23/04/2014 16:03, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix that removes npt library from jdk. >> > No objection to removing the npt library but what is the motivation? > > -Alan. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu Apr 24 11:39:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Apr 2014 12:39:31 +0100 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <5358F6D0.8090205@oracle.com> References: <5357D655.7090600@oracle.com> <5358EADB.5030608@oracle.com> <5358F6D0.8090205@oracle.com> Message-ID: <5358F7F3.2070406@oracle.com> On 24/04/2014 12:34, Dmitry Samersoff wrote: > Alan, > >> No objection to removing the npt library but what is the motivation? > It's the part of the test stabilization. Next step is revisit UTF8 usage > in JDWP and fix related tests when necessary. > Could you clarify this a bit more? It's not initially obvious how this is related to tests. -Alan From dmitry.samersoff at oracle.com Thu Apr 24 12:30:16 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 24 Apr 2014 16:30:16 +0400 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <5358F7F3.2070406@oracle.com> References: <5357D655.7090600@oracle.com> <5358EADB.5030608@oracle.com> <5358F6D0.8090205@oracle.com> <5358F7F3.2070406@oracle.com> Message-ID: <535903D8.3080103@oracle.com> Alan, On 2014-04-24 15:39, Alan Bateman wrote: > On 24/04/2014 12:34, Dmitry Samersoff wrote: >> Alan, >> >>> No objection to removing the npt library but what is the motivation? >> It's the part of the test stabilization. Next step is revisit UTF8 usage >> in JDWP and fix related tests when necessary. >> > Could you clarify this a bit more? It's not initially obvious how this > is related to tests. We have couple (about two hundreds) of intermittent JDWP test failures that have to be investigated. Some of them might be related to NPT initialization and deinitialization code (no strong evidence, just a speculation for today). Besides that there are couple of places in NPT-related code that should be re-evaluated and probably fixed. So I have an impression that if I clean it up today it saves me debugging efforts later. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Apr 24 12:52:07 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 24 Apr 2014 14:52:07 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB Message-ID: <535908F7.4040000@oracle.com> Please, review the following patch: Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 With JDK8 it became possible to have methods with implementation in interfaces - static and default interface methods. However the JDI and JDWP were not updated to reflect these capabilities so it is not currently possible to invoke a static or default interface method programatically from the debugger. This patch adds support for static and default interface methods to JDI, JDWP and JDB. Thanks, -JB- From daniel.daugherty at oracle.com Thu Apr 24 13:57:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Apr 2014 07:57:07 -0600 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535908F7.4040000@oracle.com> References: <535908F7.4040000@oracle.com> Message-ID: <53591833.7060103@oracle.com> Jaroslav, It looks like you are adding APIs here so you'll need to bump at least the minor version numbers here. Also, I think you need a CCC request for this work. Dan On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: > Please, review the following patch: > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 > > With JDK8 it became possible to have methods with implementation in > interfaces - static and default interface methods. However the JDI and > JDWP were not updated to reflect these capabilities so it is not > currently possible to invoke a static or default interface method > programatically from the debugger. > > This patch adds support for static and default interface methods to > JDI, JDWP and JDB. > > Thanks, > > -JB- From staffan.larsen at oracle.com Thu Apr 24 14:09:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Apr 2014 16:09:31 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <53591833.7060103@oracle.com> References: <535908F7.4040000@oracle.com> <53591833.7060103@oracle.com> Message-ID: <8C825954-B2F6-46C9-98FB-9A8D52619F4C@oracle.com> I can see version numbers bumped in com/sun/tools/jdi/VirtualMachineManagerImpl.java as well as in src/share/back/VirtualMachineImpl.c. Are there other places that need fixing? A CCC has been filed and approved. Thanks, /Staffan On 24 apr 2014, at 15:57, Daniel D. Daugherty wrote: > Jaroslav, > > It looks like you are adding APIs here so you'll need to bump at > least the minor version numbers here. Also, I think you need a > CCC request for this work. > > Dan > > > On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >> Please, review the following patch: >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >> >> With JDK8 it became possible to have methods with implementation in interfaces - static and default interface methods. However the JDI and JDWP were not updated to reflect these capabilities so it is not currently possible to invoke a static or default interface method programatically from the debugger. >> >> This patch adds support for static and default interface methods to JDI, JDWP and JDB. >> >> Thanks, >> >> -JB- > From daniel.daugherty at oracle.com Thu Apr 24 14:16:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Apr 2014 08:16:38 -0600 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <8C825954-B2F6-46C9-98FB-9A8D52619F4C@oracle.com> References: <535908F7.4040000@oracle.com> <53591833.7060103@oracle.com> <8C825954-B2F6-46C9-98FB-9A8D52619F4C@oracle.com> Message-ID: <53591CC6.8030408@oracle.com> On 4/24/14 8:09 AM, Staffan Larsen wrote: > I can see version numbers bumped in com/sun/tools/jdi/VirtualMachineManagerImpl.java as well as in src/share/back/VirtualMachineImpl.c. Are there other places that need fixing? No. I redid my searches of the patch and I see them now. This is what I get for trying to do a quick search and post a quick comment without having reviewed the whole webrev. I don't normally do things that way and I apologize for the noise. > A CCC has been filed and approved. I would have mentioned that a CCC has been approved and probably included a line apologizing that the CCC process is still not accessible external to Oracle. Dan > > Thanks, > /Staffan > > On 24 apr 2014, at 15:57, Daniel D. Daugherty wrote: > >> Jaroslav, >> >> It looks like you are adding APIs here so you'll need to bump at >> least the minor version numbers here. Also, I think you need a >> CCC request for this work. >> >> Dan >> >> >> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>> Please, review the following patch: >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>> >>> With JDK8 it became possible to have methods with implementation in interfaces - static and default interface methods. However the JDI and JDWP were not updated to reflect these capabilities so it is not currently possible to invoke a static or default interface method programatically from the debugger. >>> >>> This patch adds support for static and default interface methods to JDI, JDWP and JDB. >>> >>> Thanks, >>> >>> -JB- From jaroslav.bachorik at oracle.com Thu Apr 24 14:50:47 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 24 Apr 2014 16:50:47 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <53591CC6.8030408@oracle.com> References: <535908F7.4040000@oracle.com> <53591833.7060103@oracle.com> <8C825954-B2F6-46C9-98FB-9A8D52619F4C@oracle.com> <53591CC6.8030408@oracle.com> Message-ID: <535924C7.2070506@oracle.com> On 24.4.2014 16:16, Daniel D. Daugherty wrote: > On 4/24/14 8:09 AM, Staffan Larsen wrote: >> I can see version numbers bumped in >> com/sun/tools/jdi/VirtualMachineManagerImpl.java as well as in >> src/share/back/VirtualMachineImpl.c. Are there other places that need >> fixing? > > No. I redid my searches of the patch and I see them now. > > This is what I get for trying to do a quick search and post a quick > comment without having reviewed the whole webrev. I don't normally > do things that way and I apologize for the noise. > >> A CCC has been filed and approved. > > I would have mentioned that a CCC has been approved and probably > included a line apologizing that the CCC process is still not > accessible external to Oracle. Sorry, the CCC has already been approved. And I apologize that the CCC process is still not an open one but I'm afraid it is beyond my powers to make it so. -JB- > > Dan > >> >> Thanks, >> /Staffan >> >> On 24 apr 2014, at 15:57, Daniel D. Daugherty >> wrote: >> >>> Jaroslav, >>> >>> It looks like you are adding APIs here so you'll need to bump at >>> least the minor version numbers here. Also, I think you need a >>> CCC request for this work. >>> >>> Dan >>> >>> >>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>> Please, review the following patch: >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>>> >>>> With JDK8 it became possible to have methods with implementation in >>>> interfaces - static and default interface methods. However the JDI >>>> and JDWP were not updated to reflect these capabilities so it is not >>>> currently possible to invoke a static or default interface method >>>> programatically from the debugger. >>>> >>>> This patch adds support for static and default interface methods to >>>> JDI, JDWP and JDB. >>>> >>>> Thanks, >>>> >>>> -JB- > From markus.gronlund at oracle.com Thu Apr 24 15:42:51 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 24 Apr 2014 08:42:51 -0700 (PDT) Subject: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses Message-ID: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> Greetings, ? Kindly asking for reviews for the following very small fix: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 Webrev: http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ ? Description: The Event Based tracing framework assigns a unique traceid to Klass:es for tracking purposes. Normally, a new Klass is assigned it's traceid inside the Klass constructor. For Klass:es coming into the system via the ClassDataSharing (CDS) mechanism, the old traceid for the Klass will be stale, hence a "new" traceid needs to be (re)assigned to the Klass. ? Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Thu Apr 24 16:30:27 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 24 Apr 2014 18:30:27 +0200 Subject: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses In-Reply-To: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> References: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> Message-ID: <53593C23.3090408@oracle.com> Hi Markus, On 2014-04-24 17:42, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ > > Klass::restore_unshareable_info() might be called multiple times for a given Klass. This can happen if OutOfMemoryErrors is thrown when the Klass is loaded, and we later retry to load the Klass. Is it OK to call TRACE_INIT_ID(this) multiple times for the same Klass? thanks, StefanK > > Description: > > The Event Based tracing framework assigns a unique traceid to Klass:es > for tracking purposes. > Normally, a new Klass is assigned it's traceid inside the Klass > constructor. > For Klass:es coming into the system via the ClassDataSharing (CDS) > mechanism, the old traceid for the Klass will be stale, hence a "new" > traceid needs to be (re)assigned to the Klass. > > Thank you > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Thu Apr 24 16:41:48 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 24 Apr 2014 09:41:48 -0700 (PDT) Subject: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses In-Reply-To: <53593C23.3090408@oracle.com> References: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> <53593C23.3090408@oracle.com> Message-ID: Thanks Stefan, ? Yes, i think it's ok as long as the Klass ?is not able to "do anything" useful ?- i.e. the Klass is not able to execute anything which would involve its traceid. So, I would assume the semantics of Klass::restore_unsharable_info() would be similar in nature to a constructor? It prepares the Klass for use. ? As long as the Klass is coming out "prepared" with a unique ID assigned, this will be fine. ? Thanks Markus ? ? From: Stefan Karlsson Sent: den 24 april 2014 18:30 To: Markus Gr?nlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses ? Hi Markus, On 2014-04-24 17:42, Markus Gr?nlund wrote: Greetings, ? Kindly asking for reviews for the following very small fix: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8041723/webrev01/"http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ Klass::restore_unshareable_info() might be called multiple times for a given Klass. This can happen if OutOfMemoryErrors is thrown when the Klass is loaded, and we later retry to load the Klass. Is it OK to call TRACE_INIT_ID(this) multiple times for the same Klass? thanks, StefanK ? Description: The Event Based tracing framework assigns a unique traceid to Klass:es for tracking purposes. Normally, a new Klass is assigned it's traceid inside the Klass constructor. For Klass:es coming into the system via the ClassDataSharing (CDS) mechanism, the old traceid for the Klass will be stale, hence a "new" traceid needs to be (re)assigned to the Klass. ? Thank you Markus ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Thu Apr 24 18:01:36 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 24 Apr 2014 20:01:36 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore In-Reply-To: <9178805f-7014-45ae-9c16-884c282dd045@default> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> Message-ID: <53595180.40906@oracle.com> I've now added the keyword "quarantine" as well as fixed an issue with placement of the @ignore tag (it's not allowed to come before @library). New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ Local testing: > % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ > Test results: no tests selected > Report written to /localhome/temp/run/JTreport/html/report.html > Results written to /localhome/temp/run/JTwork Thanks, Mikael On 2014-04-22 17:12, Stefan S?rne wrote: > Hi Mikael, > > I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: > @key quarantine > > Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. > > Best regards, > Stefan > > -----Original Message----- > From: Mikael Auno > Sent: den 16 april 2014 19:51 > To: serviceability-dev at openjdk.java.net > Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore > > Please, review the following fix adding the @ignore tag to a couple of serviceability tests > > Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 > Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ > > Thanks, > Mikael > From dmitry.samersoff at oracle.com Thu Apr 24 20:29:33 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Apr 2014 00:29:33 +0400 Subject: RFR(M): JDK-8041498 Remove npt library In-Reply-To: <2BF3D28F-5553-4E61-AE11-EED5DDDCFDD8@oracle.com> References: <5357D655.7090600@oracle.com> <2BF3D28F-5553-4E61-AE11-EED5DDDCFDD8@oracle.com> Message-ID: <5359742D.1070603@oracle.com> Staffan, After some "whitebox" testing, I decided to change conversion code to have consistent error handling and consistent behavior of UNIX and windows parts. http://cr.openjdk.java.net/~dsamersoff/JDK-8041498/webrev.02/ (besides fixed nits only utf_util.c is changed) Changes details: 1. Original code try to convert to/from ANSI_X3.4-1968 (default value returned by nl_langinfo) if no locale set and it's not correct. Modified code check result of setlocale() and don't convert if no locale is set. 2. Original code leaves output empty or uninitialized in case of conversion error. Callers never checks for -1 returned on conversion error so it can cause weird failures. Modified code returns copy of original string in case of conversion error. Also fixed nits below. On 2014-04-24 13:52, Staffan Larsen wrote: > src/share/demo/jvmti/hprof/hprof_init.c > L743-744: Indentation looks wrong fixed. > > src/share/back/utf_util.h > L1: Missing copyright header. fixed. > > L14: UTF_ERROR and UTF_ASSERT are only used in utf_util.c, so they can be defined in that file instead of the header file. fixed > > src/share/back/utf_util.c > L297: Wouldn?t it make sense to cache the result of getCodepage() in a static variable so we don?t need to call this code for each UTF conversion? fixed. > > L492: skeep -> skip > > L492: This TODO should be fixed. I also have the same worry here as for the windows code: that we should cache data so that we don?t run this unnecessarily. fixed > > In the original code we did: > > /* Set the locale from the environment */ > (void)setlocale(LC_ALL, "?); > > but that is missing from the new code. I don?t know if it matters? It was intentional, but finally after some "whitebox" testing I decided to rewrite conversion code. See above. -Dmitry > > > Thanks, > /Staffan > > > > On 23 apr 2014, at 17:03, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> Please review the fix that removes npt library from jdk. >> >> CR link: >> >> https://bugs.openjdk.java.net/browse/JDK-8041498 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8041498/webrev.01/ >> >> >> Testing: >> >> nsk.jdwp >> >> I plan to submit a separate aurora run when I get all concerns. >> >> Fix details: >> >> * Today libnpt is a set of UTF related function and only few of them is >> actually used. The only users of npt is JDWP and hprof. So it's not >> necessary to keep it as a separate library. >> >> * Relevant code moved from npt to src/share/back/utf_util.c >> platfrom specific part is under #ifdef _WINDOWS initialization step >> is removed. >> >> * hprof changed to don't do any conversion. >> >> The only place where hrpof care about encoding is an output >> filename. Conversion from platform to UTF8 assume that >> filesystem does support UTF8 but command line doesn't. >> This assumption is obviously not correct in all cases and >> therefore handling of non-ascii filenames is incomplete. >> We should file a separate RFE if we need to handle no-ascii >> filenames by hprof. >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Fri Apr 25 06:15:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 08:15:40 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore In-Reply-To: <53595180.40906@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> Message-ID: For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. /Staffan On 24 apr 2014, at 20:01, Mikael Auno wrote: > I've now added the keyword "quarantine" as well as fixed an issue with > placement of the @ignore tag (it's not allowed to come before @library). > > New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ > > Local testing: > >> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >> Test results: no tests selected >> Report written to /localhome/temp/run/JTreport/html/report.html >> Results written to /localhome/temp/run/JTwork > > Thanks, > Mikael > > On 2014-04-22 17:12, Stefan S?rne wrote: >> Hi Mikael, >> >> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >> @key quarantine >> >> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >> >> Best regards, >> Stefan >> >> -----Original Message----- >> From: Mikael Auno >> Sent: den 16 april 2014 19:51 >> To: serviceability-dev at openjdk.java.net >> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >> >> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >> >> Thanks, >> Mikael >> > From staffan.larsen at oracle.com Fri Apr 25 06:19:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 08:19:04 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> Message-ID: Can I have a Review of this small change, please? /Staffan On 8 apr 2014, at 11:04, Staffan Larsen wrote: > This test causes exceptions that looks like this: > > java.awt.AWTError: Can't connect to X11 window server using ?REDACTED:503' as the value of the DISPLAY variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) > at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) > at java.security.AccessController.doPrivileged(Native Method) > at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:259) > at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) > at TraceJFrame.main(TraceJFrame.java:39) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) > > > The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. > > Please review the fix below, > > Thanks, > /Staffan > > > > diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java > --- a/test/demo/jvmti/mtrace/TraceJFrame.java > +++ b/test/demo/jvmti/mtrace/TraceJFrame.java > @@ -36,7 +36,7 @@ > > public class TraceJFrame { > public static void main(String args[]) throws Exception { > - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { > + if (GraphicsEnvironment.isHeadless()) { > System.out.println("JFrame test was skipped due to headless mode"); > } else { > DemoRun demo; From staffan.larsen at oracle.com Fri Apr 25 06:20:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 08:20:31 +0200 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> Message-ID: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> Can I get a Review for this, please? Thanks, /Staffan On 8 apr 2014, at 14:07, Staffan Larsen wrote: > This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. > > This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. > > webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038947 > > Thanks, > /Staffan From mandy.chung at oracle.com Fri Apr 25 06:35:22 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Apr 2014 23:35:22 -0700 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> Message-ID: <535A022A.3050006@oracle.com> The patch looks okay to me. Mandy On 4/24/2014 11:20 PM, Staffan Larsen wrote: > Can I get a Review for this, please? > > Thanks, > /Staffan > > On 8 apr 2014, at 14:07, Staffan Larsen wrote: > >> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. >> >> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. >> >> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8038947 >> >> Thanks, >> /Staffan From markus.gronlund at oracle.com Fri Apr 25 06:54:13 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 24 Apr 2014 23:54:13 -0700 (PDT) Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> Message-ID: <26b5be49-bcfb-4da1-a2c5-9d3662d352a0@default> Looks good Staffan. Unfortunately I can only do (r)eview. /Markus -----Original Message----- From: Staffan Larsen Sent: den 25 april 2014 08:19 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 Can I have a Review of this small change, please? /Staffan On 8 apr 2014, at 11:04, Staffan Larsen wrote: > This test causes exceptions that looks like this: > > java.awt.AWTError: Can't connect to X11 window server using 'REDACTED:503' as the value of the DISPLAY variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) > at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) > at java.security.AccessController.doPrivileged(Native Method) > at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:259) > at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) > at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) > at TraceJFrame.main(TraceJFrame.java:39) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) > > > The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. > > Please review the fix below, > > Thanks, > /Staffan > > > > diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java > --- a/test/demo/jvmti/mtrace/TraceJFrame.java > +++ b/test/demo/jvmti/mtrace/TraceJFrame.java > @@ -36,7 +36,7 @@ > > public class TraceJFrame { > public static void main(String args[]) throws Exception { > - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { > + if (GraphicsEnvironment.isHeadless()) { > System.out.println("JFrame test was skipped due to headless mode"); > } else { > DemoRun demo; From staffan.larsen at oracle.com Fri Apr 25 06:52:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 08:52:17 +0200 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <535A022A.3050006@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> <535A022A.3050006@oracle.com> Message-ID: <8D1FFEF5-3C71-4E45-AB5C-CFEF91276A23@oracle.com> Thanks, Mandy! On 25 apr 2014, at 08:35, Mandy Chung wrote: > The patch looks okay to me. > > Mandy > > On 4/24/2014 11:20 PM, Staffan Larsen wrote: >> Can I get a Review for this, please? >> >> Thanks, >> /Staffan >> >> On 8 apr 2014, at 14:07, Staffan Larsen wrote: >> >>> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. >>> >>> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8038947 >>> >>> Thanks, >>> /Staffan > From Alan.Bateman at oracle.com Fri Apr 25 07:40:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Apr 2014 08:40:13 +0100 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore In-Reply-To: <53595180.40906@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> Message-ID: <535A115D.1060605@oracle.com> On 24/04/2014 19:01, Mikael Auno wrote: > I've now added the keyword "quarantine" as well as fixed an issue with > placement of the @ignore tag (it's not allowed to come before @library). > > New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ > The rational for the keyword "quarantine" is not clear. Is there anything to explain what this is intended to be used for? Also as keywords are test wide then maybe it needs wider discussion. Maybe the quality-discuss list is the place to bring this up? -Alan From erik.helin at oracle.com Fri Apr 25 07:52:33 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 25 Apr 2014 09:52:33 +0200 Subject: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses In-Reply-To: References: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> <53593C23.3090408@oracle.com> <53594209.7000705@oracle.com> Message-ID: <535A1441.3020304@oracle.com> Hi Markus, this looks good. Thanks, Erik On 2014-04-24 19:06, Markus Gr?nlund wrote: > Thanks Coleen, > > It?s just a simple scalar assignment ? it?s ok to take yet another > incremented value if needed. > > /Markus > > *From:*Coleen Phillimore > *Sent:* den 24 april 2014 18:56 > *To:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR(XXS): Event Based tracing framework trace_id's to be > reassigned for CDS klasses > > On 4/24/14, 12:41 PM, Markus Gr?nlund wrote: > > Thanks Stefan, > > Yes, i think it?s ok as long as the Klass is not able to ?do > anything? useful ? i.e. the Klass is not able to execute anything > which would involve its traceid. > > So, I would assume the semantics of Klass::restore_unsharable_info() > would be similar in nature to a constructor? It prepares the Klass > for use. > > Stefan is right. It's sort of a restartable constructor. We keep the > values "restored" so far if you get OOM while restoring the values. You > could conditionally if DumpSharedSpaces not initalize this field in the > Klass constructor and check if it's zero before calling TRACE_INIT_ID, > if TRACE_INIT_ID has side effects you only want once. I was thinking > earlier that it stores some sort of scalar to this field and that would > be ok to do more than once. > > As long as the Klass is coming out ?prepared? with a unique ID assigned, > this will be fine. > > > So in the rare case of OOM during restore_unshareable_info, you might > get an extra unique value if the class is successfully loaded again > (which is also rare except in our testing apparently). > > I think this fix is good. > > Coleen > > > Thanks > > Markus > > *From:*Stefan Karlsson > *Sent:* den 24 april 2014 18:30 > *To:* Markus Gr?nlund; serviceability-dev at openjdk.java.net > > serviceability-dev at openjdk.java.net > ; hotspot-runtime-dev > *Subject:* Re: RFR(XXS): Event Based tracing framework trace_id's to be > reassigned for CDS klasses > > Hi Markus, > > On 2014-04-24 17:42, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ > > > > Klass::restore_unshareable_info() might be called multiple times for a > given Klass. This can happen if OutOfMemoryErrors is thrown when the > Klass is loaded, and we later retry to load the Klass. Is it OK to call > TRACE_INIT_ID(this) multiple times for the same Klass? > > thanks, > StefanK > > > Description: > > The Event Based tracing framework assigns a unique traceid to Klass:es > for tracking purposes. > Normally, a new Klass is assigned it?s traceid inside the Klass > constructor. > For Klass:es coming into the system via the ClassDataSharing (CDS) > mechanism, the old traceid for the Klass will be stale, hence a "new" > traceid needs to be (re)assigned to the Klass. > > Thank you > > Markus > From markus.gronlund at oracle.com Fri Apr 25 08:04:08 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 25 Apr 2014 01:04:08 -0700 (PDT) Subject: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses In-Reply-To: <535A1441.3020304@oracle.com> References: <4739f2b4-e670-47d1-8210-1ac799e5b649@default> <53593C23.3090408@oracle.com> <53594209.7000705@oracle.com> <535A1441.3020304@oracle.com> Message-ID: <1fb57186-1aca-4417-922f-1683b1c9c50e@default> Thanks Erik, Coleen and Stefan. /Markus -----Original Message----- From: Erik Helin Sent: den 25 april 2014 09:53 To: Markus Gr?nlund; Coleen Phillimore Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: RFR(XXS): Event Based tracing framework trace_id's to be reassigned for CDS klasses Hi Markus, this looks good. Thanks, Erik On 2014-04-24 19:06, Markus Gr?nlund wrote: > Thanks Coleen, > > It's just a simple scalar assignment - it's ok to take yet another > incremented value if needed. > > /Markus > > *From:*Coleen Phillimore > *Sent:* den 24 april 2014 18:56 > *To:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR(XXS): Event Based tracing framework trace_id's to > be reassigned for CDS klasses > > On 4/24/14, 12:41 PM, Markus Gr?nlund wrote: > > Thanks Stefan, > > Yes, i think it's ok as long as the Klass is not able to "do > anything" useful - i.e. the Klass is not able to execute anything > which would involve its traceid. > > So, I would assume the semantics of Klass::restore_unsharable_info() > would be similar in nature to a constructor? It prepares the Klass > for use. > > Stefan is right. It's sort of a restartable constructor. We keep the > values "restored" so far if you get OOM while restoring the values. > You could conditionally if DumpSharedSpaces not initalize this field > in the Klass constructor and check if it's zero before calling > TRACE_INIT_ID, if TRACE_INIT_ID has side effects you only want once. > I was thinking earlier that it stores some sort of scalar to this > field and that would be ok to do more than once. > > As long as the Klass is coming out "prepared" with a unique ID > assigned, this will be fine. > > > So in the rare case of OOM during restore_unshareable_info, you might > get an extra unique value if the class is successfully loaded again > (which is also rare except in our testing apparently). > > I think this fix is good. > > Coleen > > > Thanks > > Markus > > *From:*Stefan Karlsson > *Sent:* den 24 april 2014 18:30 > *To:* Markus Gr?nlund; serviceability-dev at openjdk.java.net > > serviceability-dev at openjdk.java.net > ; hotspot-runtime-dev > *Subject:* Re: RFR(XXS): Event Based tracing framework trace_id's to > be reassigned for CDS klasses > > Hi Markus, > > On 2014-04-24 17:42, Markus Gr?nlund wrote: > > Greetings, > > Kindly asking for reviews for the following very small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041723 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8041723/webrev01/ > > > > Klass::restore_unshareable_info() might be called multiple times for a > given Klass. This can happen if OutOfMemoryErrors is thrown when the > Klass is loaded, and we later retry to load the Klass. Is it OK to > call > TRACE_INIT_ID(this) multiple times for the same Klass? > > thanks, > StefanK > > > Description: > > The Event Based tracing framework assigns a unique traceid to Klass:es > for tracking purposes. > Normally, a new Klass is assigned it's traceid inside the Klass > constructor. > For Klass:es coming into the system via the ClassDataSharing (CDS) > mechanism, the old traceid for the Klass will be stale, hence a "new" > traceid needs to be (re)assigned to the Klass. > > Thank you > > Markus > From daniel.daugherty at oracle.com Fri Apr 25 12:49:57 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 06:49:57 -0600 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <26b5be49-bcfb-4da1-a2c5-9d3662d352a0@default> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <26b5be49-bcfb-4da1-a2c5-9d3662d352a0@default> Message-ID: <535A59F5.60108@oracle.com> Also looks good which give you a (R)eview... Dan On 4/25/14 12:54 AM, Markus Gr?nlund wrote: > Looks good Staffan. > > Unfortunately I can only do (r)eview. > > /Markus > > -----Original Message----- > From: Staffan Larsen > Sent: den 25 april 2014 08:19 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 > > Can I have a Review of this small change, please? > > /Staffan > > On 8 apr 2014, at 11:04, Staffan Larsen wrote: > >> This test causes exceptions that looks like this: >> >> java.awt.AWTError: Can't connect to X11 window server using 'REDACTED:503' as the value of the DISPLAY variable. >> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >> at java.security.AccessController.doPrivileged(Native Method) >> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:259) >> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >> at TraceJFrame.main(TraceJFrame.java:39) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >> at java.lang.Thread.run(Thread.java:744) >> >> >> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >> >> Please review the fix below, >> >> Thanks, >> /Staffan >> >> >> >> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >> @@ -36,7 +36,7 @@ >> >> public class TraceJFrame { >> public static void main(String args[]) throws Exception { >> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >> + if (GraphicsEnvironment.isHeadless()) { >> System.out.println("JFrame test was skipped due to headless mode"); >> } else { >> DemoRun demo; From staffan.larsen at oracle.com Fri Apr 25 12:51:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 14:51:43 +0200 Subject: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 In-Reply-To: <535A59F5.60108@oracle.com> References: <9AF2706F-8F87-47A5-B9E9-2E1554F6D226@oracle.com> <26b5be49-bcfb-4da1-a2c5-9d3662d352a0@default> <535A59F5.60108@oracle.com> Message-ID: <25FEF8AF-1C50-4A84-AD9E-2F4DD01FE4C2@oracle.com> Thanks to both of you! On 25 apr 2014, at 14:49, Daniel D. Daugherty wrote: > Also looks good which give you a (R)eview... > > Dan > > > On 4/25/14 12:54 AM, Markus Gr?nlund wrote: >> Looks good Staffan. >> >> Unfortunately I can only do (r)eview. >> >> /Markus >> >> -----Original Message----- >> From: Staffan Larsen >> Sent: den 25 april 2014 08:19 >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> Subject: Re: RFR: 8039432 demo/jvmti/mtrace/TraceJFrame.java can't connect to X11 >> >> Can I have a Review of this small change, please? >> >> /Staffan >> >> On 8 apr 2014, at 11:04, Staffan Larsen wrote: >> >>> This test causes exceptions that looks like this: >>> >>> java.awt.AWTError: Can't connect to X11 window server using 'REDACTED:503' as the value of the DISPLAY variable. >>> at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) >>> at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65) >>> at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:74) >>> at java.lang.Class.forName0(Native Method) >>> at java.lang.Class.forName(Class.java:259) >>> at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102) >>> at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81) >>> at TraceJFrame.main(TraceJFrame.java:39) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:484) >>> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> >>> The fix seems to be to not call GraphicsEnvironment.getLocalGraphicsEnvironement().isHeadlessInstance() but GraphicsEnvironment.isHeadless() directly. >>> >>> Please review the fix below, >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> diff --git a/test/demo/jvmti/mtrace/TraceJFrame.java b/test/demo/jvmti/mtrace/TraceJFrame.java >>> --- a/test/demo/jvmti/mtrace/TraceJFrame.java >>> +++ b/test/demo/jvmti/mtrace/TraceJFrame.java >>> @@ -36,7 +36,7 @@ >>> >>> public class TraceJFrame { >>> public static void main(String args[]) throws Exception { >>> - if (GraphicsEnvironment.getLocalGraphicsEnvironment().isHeadlessInstance()) { >>> + if (GraphicsEnvironment.isHeadless()) { >>> System.out.println("JFrame test was skipped due to headless mode"); >>> } else { >>> DemoRun demo; > From staffan.larsen at oracle.com Fri Apr 25 12:56:20 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 14:56:20 +0200 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> Message-ID: <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen wrote: > And the links: > > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ > > Sorry about that, > /Staffan > > On 7 apr 2014, at 20:08, Staffan Larsen wrote: > >> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >> >> Thanks, >> /Staffan > From kmcguigan at twitter.com Fri Apr 25 15:02:04 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Fri, 25 Apr 2014 11:02:04 -0400 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> Message-ID: Hi Staffan - It looks good to me. Why is the bug marked "closed" though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: > Still looking for a Review of this change. > > Thanks, > /Staffan > > On 7 apr 2014, at 21:19, Staffan Larsen wrote: > > > And the links: > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 > > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ > > > > Sorry about that, > > /Staffan > > > > On 7 apr 2014, at 20:08, Staffan Larsen > wrote: > > > >> > >> The problem here is that the code for finding local VMs is not looking > for the data in the correct place. > >> > >> When a JVM is started it will create the perf-data file in a > user-specific directory inside /tmp (*). The code in the JDK > (PerfDataFile.java) that lists all active JVMs looks for the user-specific > directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the > command line, the code in PerfDataFile will look in the wrong place. > >> > >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. > On OS X and Windows, there are user-specific temp directories that should > be used, and so the VM queries the OS for these paths. > >> > >> The solution would be for PerfDataFile to use the same locations as the > VM creates them in. The simplest way to guarantee that the same directory > is used is to ask the VM to provide the location. Thus I have introduced a > new JVM_ function: JVM_GetTemporaryDirectory. > >> > >> (Since this change touches both hotspot and jdk repos I will submit the > hotspot part first under a different bug id (provided that the review goes > well)). > >> > >> The newly added test starts two VM with all possible combinations of > setting and not setting java.io.tmpdir to verify that the mechanism is > indeed not looking at that variable. I also removed an if-statement in > BasicTests.java which would have found this issue a long time ago had it > not been there. > >> > >> Thanks, > >> /Staffan > > > > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 25 15:16:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 17:16:50 +0200 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> Message-ID: <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan wrote: > Hi Staffan - > > It looks good to me. Why is the bug marked "closed" though? > > > On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: > Still looking for a Review of this change. > > Thanks, > /Staffan > > On 7 apr 2014, at 21:19, Staffan Larsen wrote: > > > And the links: > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 > > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ > > > > Sorry about that, > > /Staffan > > > > On 7 apr 2014, at 20:08, Staffan Larsen wrote: > > > >> > >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. > >> > >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. > >> > >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. > >> > >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. > >> > >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). > >> > >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. > >> > >> Thanks, > >> /Staffan > > > > > > > -- > > Keith McGuigan > @kamggg > kmcguigan at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Apr 25 15:23:51 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 09:23:51 -0600 Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> Message-ID: <535A7E07.1090206@oracle.com> Looks like when the bug was filed Oracle internal information like hostnames were included in the description section. You can edit it out, but that doesn't remove it from the history so the entire bug has to be marked confidential... We've updated our internal wikis to let folks know that they should put non-Oracle-internal info in the description and then add a separate note for the configuration info with the access level set to "screening required" or "confidential". Getting everyone on the same page is slow process... Dan On 4/25/14 9:16 AM, Staffan Larsen wrote: > Thanks Keith! > > As far as I can tell there was no good reason for making the bug > Confidential, but I can?t undo it. Sorry about that. > > /Staffan > > On 25 apr 2014, at 17:02, Keith McGuigan > wrote: > >> Hi Staffan - >> >> It looks good to me. Why is the bug marked "closed" though? >> >> >> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen >> > wrote: >> >> Still looking for a Review of this change. >> >> Thanks, >> /Staffan >> >> On 7 apr 2014, at 21:19, Staffan Larsen >> > wrote: >> >> > And the links: >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >> >> > >> > Sorry about that, >> > /Staffan >> > >> > On 7 apr 2014, at 20:08, Staffan Larsen >> > wrote: >> > >> >> >> >> The problem here is that the code for finding local VMs is not >> looking for the data in the correct place. >> >> >> >> When a JVM is started it will create the perf-data file in a >> user-specific directory inside /tmp (*). The code in the JDK >> (PerfDataFile.java) that lists all active JVMs looks for the >> user-specific directory inside java.io.tmpdir. If a user sets >> -Djava.io.tmpdir on the command line, the code in PerfDataFile >> will look in the wrong place. >> >> >> >> (*) It's a little bit more complex. /tmp is used on Linux and >> Solaris. On OS X and Windows, there are user-specific temp >> directories that should be used, and so the VM queries the OS for >> these paths. >> >> >> >> The solution would be for PerfDataFile to use the same >> locations as the VM creates them in. The simplest way to >> guarantee that the same directory is used is to ask the VM to >> provide the location. Thus I have introduced a new JVM_ function: >> JVM_GetTemporaryDirectory. >> >> >> >> (Since this change touches both hotspot and jdk repos I will >> submit the hotspot part first under a different bug id (provided >> that the review goes well)). >> >> >> >> The newly added test starts two VM with all possible >> combinations of setting and not setting java.io.tmpdir to verify >> that the mechanism is indeed not looking at that variable. I also >> removed an if-statement in BasicTests.java which would have found >> this issue a long time ago had it not been there. >> >> >> >> Thanks, >> >> /Staffan >> > >> >> >> >> >> -- >> twitter-icon-large.png >> >> Keith McGuigan >> @kamggg >> kmcguigan at twitter.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 25 16:24:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:24:41 +0200 Subject: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> Message-ID: <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen wrote: > Thanks Keith! > > As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. > > /Staffan > > On 25 apr 2014, at 17:02, Keith McGuigan wrote: > >> Hi Staffan - >> >> It looks good to me. Why is the bug marked "closed" though? >> >> >> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >> Still looking for a Review of this change. >> >> Thanks, >> /Staffan >> >> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >> >> > And the links: >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >> > >> > Sorry about that, >> > /Staffan >> > >> > On 7 apr 2014, at 20:08, Staffan Larsen wrote: >> > >> >> >> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >> >> >> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >> >> >> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >> >> >> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >> >> >> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >> >> >> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >> >> >> >> Thanks, >> >> /Staffan >> > >> >> >> >> >> -- >> >> Keith McGuigan >> @kamggg >> kmcguigan at twitter.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 25 16:36:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:36:34 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> Message-ID: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen wrote: > It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. > > Should I push an anti-delta of the patch? I can prepare a review of it in a moment. > > /Staffan > > On 25 apr 2014, at 17:16, Staffan Larsen wrote: > >> Thanks Keith! >> >> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >> >> /Staffan >> >> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >> >>> Hi Staffan - >>> >>> It looks good to me. Why is the bug marked "closed" though? >>> >>> >>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>> Still looking for a Review of this change. >>> >>> Thanks, >>> /Staffan >>> >>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>> >>> > And the links: >>> > >>> > bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>> > webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>> > >>> > Sorry about that, >>> > /Staffan >>> > >>> > On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>> > >>> >> >>> >> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>> >> >>> >> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>> >> >>> >> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>> >> >>> >> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>> >> >>> >> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>> >> >>> >> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>> >> >>> >> Thanks, >>> >> /Staffan >>> > >>> >>> >>> >>> >>> -- >>> >>> Keith McGuigan >>> @kamggg >>> kmcguigan at twitter.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 25 16:43:13 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Apr 2014 09:43:13 -0700 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Message-ID: <535A90A1.2050609@oracle.com> Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: > Here is an anti-delta for the broken push. I prepared it using ?hg backout?. > > webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8041948 > > If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). > > Thanks, > /Staffan > > > On 25 apr 2014, at 18:24, Staffan Larsen wrote: > >> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >> >> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >> >> /Staffan >> >> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >> >>> Thanks Keith! >>> >>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>> >>> /Staffan >>> >>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>> >>>> Hi Staffan - >>>> >>>> It looks good to me. Why is the bug marked "closed" though? >>>> >>>> >>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>> Still looking for a Review of this change. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>> >>>>> And the links: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>> >>>>> Sorry about that, >>>>> /Staffan >>>>> >>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>> >>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>> >>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>> >>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>> >>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>> >>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>> >>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>> >>>> >>>> >>>> -- >>>> >>>> Keith McGuigan >>>> @kamggg >>>> kmcguigan at twitter.com From Alan.Bateman at oracle.com Fri Apr 25 16:44:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Apr 2014 17:44:10 +0100 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> Message-ID: <535A90DA.6060903@oracle.com> On 25/04/2014 17:36, Staffan Larsen wrote: > Here is an anti-delta for the broken push. I prepared it using ?hg > backout?. > > webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8041948 > > If I can get this reviewed quickly I can push the fix soon (and I will > spend the weekend in shame). > I just ran into the build issue a few minutes ago. From a quick scan of the patch then it looks to be anti-delta so I think it's good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 25 16:46:39 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 18:46:39 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <535A90A1.2050609@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> Message-ID: <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> Thanks Joe - fix has been pushed. (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). /Staffan On 25 apr 2014, at 18:43, Joe Darcy wrote: > Approved! > > -Joe > > On 04/25/2014 09:36 AM, Staffan Larsen wrote: >> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >> >> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >> >> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >> >> Thanks, >> /Staffan >> >> >> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >> >>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>> >>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>> >>> /Staffan >>> >>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>> >>>> Thanks Keith! >>>> >>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>> >>>> /Staffan >>>> >>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>> >>>>> Hi Staffan - >>>>> >>>>> It looks good to me. Why is the bug marked "closed" though? >>>>> >>>>> >>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>> Still looking for a Review of this change. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>> >>>>>> And the links: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>> >>>>>> Sorry about that, >>>>>> /Staffan >>>>>> >>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>> >>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>> >>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>> >>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>> >>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>> >>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>> >>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Keith McGuigan >>>>> @kamggg >>>>> kmcguigan at twitter.com > From alejandro.murillo at oracle.com Fri Apr 25 17:04:48 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 25 Apr 2014 11:04:48 -0600 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> Message-ID: <535A95B0.3020007@oracle.com> what's wrong with pushing them to jdk9/hs-rt? We did this a couple of weeks ago with Erik (Gahlin) changes, it might disrupt nightly, as we still do not have the JPRT changes in place, but that was the agreement we have for jdk9: tightly coupled changes should be pushed through the hotspot repos. had that been pushed this week there, it would be in jdk9/dev next Tuesday Alejandro On 4/25/2014 10:46 AM, Staffan Larsen wrote: > Thanks Joe - fix has been pushed. > > (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). > > /Staffan > > On 25 apr 2014, at 18:43, Joe Darcy wrote: > >> Approved! >> >> -Joe >> >> On 04/25/2014 09:36 AM, Staffan Larsen wrote: >>> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >>> >>> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >>> >>>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>>> >>>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>>> >>>> /Staffan >>>> >>>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>>> >>>>> Thanks Keith! >>>>> >>>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>>> >>>>> /Staffan >>>>> >>>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>>> >>>>>> Hi Staffan - >>>>>> >>>>>> It looks good to me. Why is the bug marked "closed" though? >>>>>> >>>>>> >>>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>>> Still looking for a Review of this change. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>>> >>>>>>> And the links: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>>> >>>>>>> Sorry about that, >>>>>>> /Staffan >>>>>>> >>>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>>> >>>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>>> >>>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>>> >>>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>>> >>>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>>> >>>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>>> >>>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Keith McGuigan >>>>>> @kamggg >>>>>> kmcguigan at twitter.com -- Alejandro From staffan.larsen at oracle.com Fri Apr 25 17:15:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Apr 2014 19:15:13 +0200 Subject: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms In-Reply-To: <535A95B0.3020007@oracle.com> References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com> <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com> <6D91D5E8-F2BC-4F7C-AE01-C1FFE21798DD@oracle.com> <006E6009-48A5-4CC7-BF2A-23B5F1604327@oracle.com> <736C2B89-E262-40E3-A106-D3804765836E@oracle.com> <02ADC4B7-1A4B-4B60-A75D-415E00FBFD08@oracle.com> <535A90A1.2050609@oracle.com> <084B0307-0050-4C9B-B3D4-6D9BAA5899AC@oracle.com> <535A95B0.3020007@oracle.com> Message-ID: <837FBCA9-1047-4689-952C-CA28B3AADAEF@oracle.com> In this case I think it would have worked ok since the dependency was from jdk -> hotspot. If the dependency was the other way (or both ways), then such a push would break nightly testing in hotspot since that testing picks up the latest promoted JDK (instead of the JDK that is in the same forest). This is broken, IMO, and there is work in progress on fixing it. /Staffan On 25 apr 2014, at 19:04, Alejandro E Murillo wrote: > > what's wrong with pushing them to jdk9/hs-rt? > We did this a couple of weeks ago with Erik (Gahlin) changes, > it might disrupt nightly, as we still do not have the JPRT changes in place, > but that was the agreement we have for jdk9: > tightly coupled changes should be pushed through the hotspot repos. > had that been pushed this week there, it would be in jdk9/dev next Tuesday > > > Alejandro > > On 4/25/2014 10:46 AM, Staffan Larsen wrote: >> Thanks Joe - fix has been pushed. >> >> (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). >> >> /Staffan >> >> On 25 apr 2014, at 18:43, Joe Darcy wrote: >> >>> Approved! >>> >>> -Joe >>> >>> On 04/25/2014 09:36 AM, Staffan Larsen wrote: >>>> Here is an anti-delta for the broken push. I prepared it using ?hg backout?. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041948 >>>> >>>> If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 25 apr 2014, at 18:24, Staffan Larsen wrote: >>>> >>>>> It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. >>>>> >>>>> Should I push an anti-delta of the patch? I can prepare a review of it in a moment. >>>>> >>>>> /Staffan >>>>> >>>>> On 25 apr 2014, at 17:16, Staffan Larsen wrote: >>>>> >>>>>> Thanks Keith! >>>>>> >>>>>> As far as I can tell there was no good reason for making the bug Confidential, but I can?t undo it. Sorry about that. >>>>>> >>>>>> /Staffan >>>>>> >>>>>> On 25 apr 2014, at 17:02, Keith McGuigan wrote: >>>>>> >>>>>>> Hi Staffan - >>>>>>> >>>>>>> It looks good to me. Why is the bug marked "closed" though? >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen wrote: >>>>>>> Still looking for a Review of this change. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 7 apr 2014, at 21:19, Staffan Larsen wrote: >>>>>>> >>>>>>>> And the links: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8033104 >>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ >>>>>>>> >>>>>>>> Sorry about that, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 7 apr 2014, at 20:08, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> The problem here is that the code for finding local VMs is not looking for the data in the correct place. >>>>>>>>> >>>>>>>>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. >>>>>>>>> >>>>>>>>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. >>>>>>>>> >>>>>>>>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. >>>>>>>>> >>>>>>>>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). >>>>>>>>> >>>>>>>>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Keith McGuigan >>>>>>> @kamggg >>>>>>> kmcguigan at twitter.com > > -- > Alejandro > From daniel.daugherty at oracle.com Fri Apr 25 18:08:37 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 12:08:37 -0600 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535908F7.4040000@oracle.com> References: <535908F7.4040000@oracle.com> Message-ID: <535AA4A5.9020502@oracle.com> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: > Please, review the following patch: > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 make/data/jdwp/jdwp.spec line 1256: "

Since JDWP version 1.8 Missing the ending double quote. line 1281: "suspended by an event or by command. " "by command" isn't clear. "by this command", "by a command" or something else more specific would be good. line 1322: (Error INVALID_METHODID "methodID is not the ID of a method.") The above description permits a 'methodID' value that is not for a method in the 'clazz' interface. Perhaps add "in the interface specified by clazz" at the end of the description? src/share/back/VirtualMachineImpl.c No comments. src/share/back/debugDispatch.c No comments. src/share/back/util.c No comments. src/share/classes/com/sun/jdi/ClassType.java No comments. src/share/classes/com/sun/jdi/InterfaceType.java line 88: * but not a static initializer. The 'jdwp.spec' wording does not mention this restriction. typo line 107: * enclosing class's class loader). typo line 184: * loaded through the enclosing class's class loader. -> enclosing class' class loader line 189: * @throws VMCannotBeModifiedException ... Please add the following after line 189: * * @since 1.8 line 193-196: These exception are not named in the throws clause: IllegalArgumentException, VMCannotBeModifiedException src/share/classes/com/sun/jdi/Method.java line 144: * false otherwise Please add the following after line 144: * * @since 1.8 src/share/classes/com/sun/jdi/ObjectReference.java No comments. src/share/classes/com/sun/tools/example/debug/expr/LValue.java No comments. src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java line 32: final public class ClassTypeImpl extends InvokableTypeImpl The switch to "final" caught my eye. I presume that SA-JDI does not extend this implementation class. Most of these changes appear to be due to refactoring with the new InvokableTypeImpl.java. Tried to do a visual diff between the common parts of this file and InvokableTypeImpl.java. Didn't see anything obviously wrong. src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java Most of these changes appear to be due to refactoring with the new InvokableTypeImpl.java. Tried to do a visual diff between the common parts of this file and InvokableTypeImpl.java. Didn't see anything obviously wrong. src/share/classes/com/sun/tools/jdi/MethodImpl.java No comments. src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java No comments. src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java No comments. src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c No comments. src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h No comments. src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java Most of this code came from refactoring ClassTypeImpl.java or InterfaceTypeImpl.java. line 98: throws clause does not mention: IllegalArgumentException or VMCannotBeModifiedException But I also have to wonder why this JavaDoc is here since this is an impl class... test/com/sun/jdi/EvalInterfaceStatic.sh line 35: # the above error occurs. jdb doesnt notice that this is Not sure what "the above error" is. I don't see an error example above this line. typo: "doesnt" -> "doesn't" test/com/sun/jdi/InterfaceMethodsTest.java Very nice test! Dan > > With JDK8 it became possible to have methods with implementation in > interfaces - static and default interface methods. However the JDI and > JDWP were not updated to reflect these capabilities so it is not > currently possible to invoke a static or default interface method > programatically from the debugger. > > This patch adds support for static and default interface methods to > JDI, JDWP and JDB. > > Thanks, > > -JB- From daniel.daugherty at oracle.com Fri Apr 25 18:13:11 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Apr 2014 12:13:11 -0600 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535AA4A5.9020502@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> Message-ID: <535AA5B7.7010204@oracle.com> Clicked send a little too soon... Very nice job on this API addition for supporting default and static interface methods. In particular, congratulations on getting this approved via CCC for the JDK8-Update train! It is very rare that we can make API changes in an update... Dan On 4/25/14 12:08 PM, Daniel D. Daugherty wrote: > On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >> Please, review the following patch: >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 > > make/data/jdwp/jdwp.spec > line 1256: "

Since JDWP version 1.8 > Missing the ending double quote. > > line 1281: "suspended by an event or by command. " > "by command" isn't clear. "by this command", "by a command" > or something else more specific would be good. > > line 1322: (Error INVALID_METHODID "methodID is not the ID of a > method.") > The above description permits a 'methodID' value that > is not for a method in the 'clazz' interface. Perhaps > add "in the interface specified by clazz" at the end > of the description? > > src/share/back/VirtualMachineImpl.c > No comments. > > src/share/back/debugDispatch.c > No comments. > > src/share/back/util.c > No comments. > > src/share/classes/com/sun/jdi/ClassType.java > No comments. > > src/share/classes/com/sun/jdi/InterfaceType.java > line 88: * but not a static initializer. > The 'jdwp.spec' wording does not mention this restriction. > > typo line 107: * enclosing class's class loader). > typo line 184: * loaded through the enclosing class's > class loader. > -> enclosing class' class loader > > line 189: * @throws VMCannotBeModifiedException ... > Please add the following after line 189: > > * > * @since 1.8 > > line 193-196: These exception are not named in the throws clause: > IllegalArgumentException, VMCannotBeModifiedException > > > src/share/classes/com/sun/jdi/Method.java > line 144: * false otherwise > Please add the following after line 144: > > * > * @since 1.8 > > src/share/classes/com/sun/jdi/ObjectReference.java > No comments. > > src/share/classes/com/sun/tools/example/debug/expr/LValue.java > No comments. > > src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java > line 32: final public class ClassTypeImpl extends InvokableTypeImpl > The switch to "final" caught my eye. I presume that > SA-JDI does not extend this implementation class. > > Most of these changes appear to be due to refactoring with > the new InvokableTypeImpl.java. Tried to do a visual diff > between the common parts of this file and InvokableTypeImpl.java. > Didn't see anything obviously wrong. > > src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java > Most of these changes appear to be due to refactoring with > the new InvokableTypeImpl.java. Tried to do a visual diff > between the common parts of this file and InvokableTypeImpl.java. > Didn't see anything obviously wrong. > > src/share/classes/com/sun/tools/jdi/MethodImpl.java > No comments. > > src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java > No comments. > > src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > No comments. > > src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c > No comments. > > src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h > No comments. > > src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java > Most of this code came from refactoring ClassTypeImpl.java or > InterfaceTypeImpl.java. > > line 98: throws clause does not mention: > IllegalArgumentException or VMCannotBeModifiedException > > But I also have to wonder why this JavaDoc is here since > this is an impl class... > > test/com/sun/jdi/EvalInterfaceStatic.sh > line 35: # the above error occurs. jdb doesnt notice that this is > Not sure what "the above error" is. I don't see an error > example above this line. > > typo: "doesnt" -> "doesn't" > > test/com/sun/jdi/InterfaceMethodsTest.java > Very nice test! > > Dan > > >> >> With JDK8 it became possible to have methods with implementation in >> interfaces - static and default interface methods. However the JDI >> and JDWP were not updated to reflect these capabilities so it is not >> currently possible to invoke a static or default interface method >> programatically from the debugger. >> >> This patch adds support for static and default interface methods to >> JDI, JDWP and JDB. >> >> Thanks, >> >> -JB- > From ysr1729 at gmail.com Sun Apr 27 20:07:06 2014 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sun, 27 Apr 2014 13:07:06 -0700 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> Message-ID: <792BCAE0-796B-4C77-A1C2-33C959A21D4C@gmail.com> Looks good. ysr1729 > On Apr 24, 2014, at 23:20, Staffan Larsen wrote: > > Can I get a Review for this, please? > > Thanks, > /Staffan > >> On 8 apr 2014, at 14:07, Staffan Larsen wrote: >> >> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. >> >> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. >> >> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8038947 >> >> Thanks, >> /Staffan > From jaroslav.bachorik at oracle.com Mon Apr 28 09:59:32 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 28 Apr 2014 11:59:32 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535AA4A5.9020502@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> Message-ID: <535E2684.8010902@oracle.com> Thanks Dan! On 25.4.2014 20:08, Daniel D. Daugherty wrote: > On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >> Please, review the following patch: >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 > > make/data/jdwp/jdwp.spec > line 1256: "

Since JDWP version 1.8 > Missing the ending double quote. Fixed. > > line 1281: "suspended by an event or by command. " > "by command" isn't clear. "by this command", "by a command" > or something else more specific would be good. > > line 1322: (Error INVALID_METHODID "methodID is not the ID of a > method.") > The above description permits a 'methodID' value that > is not for a method in the 'clazz' interface. Perhaps > add "in the interface specified by clazz" at the end > of the description? This text is copied over from the ClassType#InvokeMethod. Should I change it there too? > > src/share/back/VirtualMachineImpl.c > No comments. > > src/share/back/debugDispatch.c > No comments. > > src/share/back/util.c > No comments. > > src/share/classes/com/sun/jdi/ClassType.java > No comments. > > src/share/classes/com/sun/jdi/InterfaceType.java > line 88: * but not a static initializer. > The 'jdwp.spec' wording does not mention this restriction. Mentioned this restriction in jdwp.spec > > typo line 107: * enclosing class's class loader). > typo line 184: * loaded through the enclosing class's class > loader. > -> enclosing class' class loader Fixed. Also in ClassType (the comments were copied over from there with typos ...) > > line 189: * @throws VMCannotBeModifiedException ... > Please add the following after line 189: > > * > * @since 1.8 > Done. > line 193-196: These exception are not named in the throws clause: > IllegalArgumentException, VMCannotBeModifiedException They are runtime exceptions. Should I list them in the throws clause regardless of that? > > > src/share/classes/com/sun/jdi/Method.java > line 144: * false otherwise > Please add the following after line 144: > > * > * @since 1.8 Done. > > src/share/classes/com/sun/jdi/ObjectReference.java > No comments. > > src/share/classes/com/sun/tools/example/debug/expr/LValue.java > No comments. > > src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java > line 32: final public class ClassTypeImpl extends InvokableTypeImpl > The switch to "final" caught my eye. I presume that > SA-JDI does not extend this implementation class. To my best knowledge it does not. > > Most of these changes appear to be due to refactoring with > the new InvokableTypeImpl.java. Tried to do a visual diff > between the common parts of this file and InvokableTypeImpl.java. > Didn't see anything obviously wrong. > > src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java > Most of these changes appear to be due to refactoring with > the new InvokableTypeImpl.java. Tried to do a visual diff > between the common parts of this file and InvokableTypeImpl.java. > Didn't see anything obviously wrong. > > src/share/classes/com/sun/tools/jdi/MethodImpl.java > No comments. > > src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java > No comments. > > src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > No comments. > > src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c > No comments. > > src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h > No comments. > > src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java > Most of this code came from refactoring ClassTypeImpl.java or > InterfaceTypeImpl.java. > > line 98: throws clause does not mention: > IllegalArgumentException or VMCannotBeModifiedException This is a runtime exception. It hasn't been mentioned in the ClassType#invokeMethod() throws clause too. > > But I also have to wonder why this JavaDoc is here since > this is an impl class... Just to add expressiveness. This method is actually declared by the both interfaces, ClassType and InterfaceType and it kind of made sense to have the shared implementation documented. The cleaner solution would probably be to factor out a shared superinterface for ClassType and InterfaceType and declare invokeMethod() there. But that would be more disruptive than playing just with the implementations. > > test/com/sun/jdi/EvalInterfaceStatic.sh > line 35: # the above error occurs. jdb doesnt notice that this is > Not sure what "the above error" is. I don't see an error > example above this line. > > typo: "doesnt" -> "doesn't" This code comment is completely wrong - a remnant of copy-paste :/ I forgot to clean it up. Sorry. > > test/com/sun/jdi/InterfaceMethodsTest.java > Very nice test! > > Dan The updated webrev - http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ -JB- > > >> >> With JDK8 it became possible to have methods with implementation in >> interfaces - static and default interface methods. However the JDI and >> JDWP were not updated to reflect these capabilities so it is not >> currently possible to invoke a static or default interface method >> programatically from the debugger. >> >> This patch adds support for static and default interface methods to >> JDI, JDWP and JDB. >> >> Thanks, >> >> -JB- > From daniel.daugherty at oracle.com Mon Apr 28 17:45:54 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Apr 2014 11:45:54 -0600 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535E2684.8010902@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> Message-ID: <535E93D2.3020103@oracle.com> On 4/28/14 3:59 AM, Jaroslav Bachorik wrote: > Thanks Dan! > > > On 25.4.2014 20:08, Daniel D. Daugherty wrote: >> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>> Please, review the following patch: >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >> >> make/data/jdwp/jdwp.spec >> line 1256: "

Since JDWP version 1.8 >> Missing the ending double quote. > > Fixed. > >> >> line 1281: "suspended by an event or by command. " >> "by command" isn't clear. "by this command", "by a command" >> or something else more specific would be good. You didn't say anything about this one... >> >> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >> method.") >> The above description permits a 'methodID' value that >> is not for a method in the 'clazz' interface. Perhaps >> add "in the interface specified by clazz" at the end >> of the description? > > This text is copied over from the ClassType#InvokeMethod. Should I > change it there too? Probably. Check with Staffan L for another set of eyes... > >> >> src/share/back/VirtualMachineImpl.c >> No comments. >> >> src/share/back/debugDispatch.c >> No comments. >> >> src/share/back/util.c >> No comments. >> >> src/share/classes/com/sun/jdi/ClassType.java >> No comments. >> >> src/share/classes/com/sun/jdi/InterfaceType.java >> line 88: * but not a static initializer. >> The 'jdwp.spec' wording does not mention this restriction. > > Mentioned this restriction in jdwp.spec > >> >> typo line 107: * enclosing class's class loader). >> typo line 184: * loaded through the enclosing class's class >> loader. >> -> enclosing class' class loader > > Fixed. Also in ClassType (the comments were copied over from there > with typos ...) > >> >> line 189: * @throws VMCannotBeModifiedException ... >> Please add the following after line 189: >> >> * >> * @since 1.8 >> > > Done. > >> line 193-196: These exception are not named in the throws clause: >> IllegalArgumentException, VMCannotBeModifiedException > > They are runtime exceptions. Should I list them in the throws clause > regardless of that? I should have checked for that. I'm pretty sure we don't put runtime exceptions in the 'throws' clause... Of course, I'm not enough of a Java programmer to know why putting them there would be a bad idea or bad style or... > >> >> >> src/share/classes/com/sun/jdi/Method.java >> line 144: * false otherwise >> Please add the following after line 144: >> >> * >> * @since 1.8 > > Done. > >> >> src/share/classes/com/sun/jdi/ObjectReference.java >> No comments. >> >> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >> line 32: final public class ClassTypeImpl extends InvokableTypeImpl >> The switch to "final" caught my eye. I presume that >> SA-JDI does not extend this implementation class. > > To my best knowledge it does not. > >> >> Most of these changes appear to be due to refactoring with >> the new InvokableTypeImpl.java. Tried to do a visual diff >> between the common parts of this file and InvokableTypeImpl.java. >> Didn't see anything obviously wrong. >> >> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >> Most of these changes appear to be due to refactoring with >> the new InvokableTypeImpl.java. Tried to do a visual diff >> between the common parts of this file and InvokableTypeImpl.java. >> Didn't see anything obviously wrong. >> >> src/share/classes/com/sun/tools/jdi/MethodImpl.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >> No comments. >> >> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >> No comments. >> >> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >> No comments. >> >> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >> Most of this code came from refactoring ClassTypeImpl.java or >> InterfaceTypeImpl.java. >> >> line 98: throws clause does not mention: >> IllegalArgumentException or VMCannotBeModifiedException > > This is a runtime exception. It hasn't been mentioned in the > ClassType#invokeMethod() throws clause too. Same as above. > >> >> But I also have to wonder why this JavaDoc is here since >> this is an impl class... > > Just to add expressiveness. This method is actually declared by the > both interfaces, ClassType and InterfaceType and it kind of made sense > to have the shared implementation documented. The cleaner solution > would probably be to factor out a shared superinterface for ClassType > and InterfaceType and declare invokeMethod() there. But that would be > more disruptive than playing just with the implementations. > >> >> test/com/sun/jdi/EvalInterfaceStatic.sh >> line 35: # the above error occurs. jdb doesnt notice that this is >> Not sure what "the above error" is. I don't see an error >> example above this line. >> >> typo: "doesnt" -> "doesn't" > > This code comment is completely wrong - a remnant of copy-paste :/ I > forgot to clean it up. Sorry. No problem. > >> >> test/com/sun/jdi/InterfaceMethodsTest.java >> Very nice test! >> >> Dan > > The updated webrev - > http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ Sounds good. Don't know when I'll get a chance for a re-review so please don't wait for me. Dan > > -JB- > >> >> >>> >>> With JDK8 it became possible to have methods with implementation in >>> interfaces - static and default interface methods. However the JDI and >>> JDWP were not updated to reflect these capabilities so it is not >>> currently possible to invoke a static or default interface method >>> programatically from the debugger. >>> >>> This patch adds support for static and default interface methods to >>> JDI, JDWP and JDB. >>> >>> Thanks, >>> >>> -JB- >> > From serguei.spitsyn at oracle.com Mon Apr 28 21:27:10 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Apr 2014 14:27:10 -0700 Subject: RFR: 8038947 HotSpotDiagnosticMXBean/CheckOrigin.java 'NewSize' should have origin 'ERGONOMIC' but had 'DEFAULT' In-Reply-To: <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> References: <6B180B1F-9799-48B3-8B18-CCBE7F32FF6B@oracle.com> <67324BA3-62E9-45E7-8AB4-829C9B56942E@oracle.com> Message-ID: <535EC7AE.4010300@oracle.com> Looks good. Thanks, Serguei On 4/24/14 11:20 PM, Staffan Larsen wrote: > Can I get a Review for this, please? > > Thanks, > /Staffan > > On 8 apr 2014, at 14:07, Staffan Larsen wrote: > >> This test verifies the origins of a couple of flags. One origin type is ERGONOMIC. The test used NewSize as an example flag that was set ergonomically by the JVM. It turns out that flag is not always set ergonomically. >> >> This change switches to use UseParNewGC as the ergonomic flag. This flag is set whenever UseConcMarkSweepGC is used. >> >> webrev: http://cr.openjdk.java.net/~sla/8038947/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8038947 >> >> Thanks, >> /Staffan From serguei.spitsyn at oracle.com Mon Apr 28 23:02:31 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Apr 2014 16:02:31 -0700 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535E2684.8010902@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> Message-ID: <535EDE07.4020104@oracle.com> Hi Jaroslav, I looked at the new webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ The fixes look fine to me modulo comments below. This is a great job in general. On 4/28/14 2:59 AM, Jaroslav Bachorik wrote: > Thanks Dan! Indeed, Dan, thank you for the thorough review and nice catches! And Jaroslav, thank you for your patience! > > > On 25.4.2014 20:08, Daniel D. Daugherty wrote: >> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>> Please, review the following patch: >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >> >> make/data/jdwp/jdwp.spec >> line 1256: "

Since JDWP version 1.8 >> Missing the ending double quote. > > Fixed. > >> >> line 1281: "suspended by an event or by command. " >> "by command" isn't clear. "by this command", "by a command" >> or something else more specific would be good. This has not been fixed yet, changing to the following would work Ok: 1282 "suspended by an event or by*a* command. " >> >> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >> method.") >> The above description permits a 'methodID' value that >> is not for a method in the 'clazz' interface. Perhaps >> add "in the interface specified by clazz" at the end >> of the description? > > This text is copied over from the ClassType#InvokeMethod. Should I > change it there too? Probably, something like this is needed: . . . 1147 (ErrorSet 1148 (Error INVALID_CLASS "clazz is not the ID of a class.") 1149 (Error INVALID_OBJECT "clazz is not a known ID.") 1150 (Error INVALID_METHODID "methodID is not the ID of a*static* method* in" "this class type or one of its superclasses*.") . . . 1320 (ErrorSet 1321 (Error INVALID_CLASS "clazz is not the ID of an interface.") 1322 (Error INVALID_OBJECT "clazz is not a known ID.") 1323 (Error INVALID_METHODID "methodID is not the ID of a*static* method* in this"** ** ***"interface* type or is the ID of a static initializer*.") . . . 1661 (ErrorSet 1662 (Error INVALID_OBJECT) 1663 (Error INVALID_CLASS "clazz is not the ID of a reference " 1664 "type.") 1665 (Error INVALID_METHODID "methodID is not the ID of a*n instance* method* in this object's type** or"** ** "**one of its superclasses, superinterfaces, or implemented interfaces*.") > >> >> src/share/back/VirtualMachineImpl.c >> No comments. >> >> src/share/back/debugDispatch.c >> No comments. >> >> src/share/back/util.c >> No comments. >> >> src/share/classes/com/sun/jdi/ClassType.java >> No comments. >> >> src/share/classes/com/sun/jdi/InterfaceType.java >> line 88: * but not a static initializer. >> The 'jdwp.spec' wording does not mention this restriction. > > Mentioned this restriction in jdwp.spec > >> >> typo line 107: * enclosing class's class loader). >> typo line 184: * loaded through the enclosing class's class >> loader. >> -> enclosing class' class loader > > Fixed. Also in ClassType (the comments were copied over from there > with typos ...) This one is still unchanged: 184 * loaded through the enclosing*class's* class loader. Also need to be fixed in the src/share/classes/com/sun/jdi/ClassType.java: 106 * enclosing class's class loader). Primitive values must be 233 * loaded through the enclosing class's class loader. 270 * enclosing class's class loader). Primitive arguments must be 338 * loaded through the enclosing class's class loader. > >> >> line 189: * @throws VMCannotBeModifiedException ... >> Please add the following after line 189: >> >> * >> * @since 1.8 Important catch! >> > > Done. > >> line 193-196: These exception are not named in the throws clause: >> IllegalArgumentException, VMCannotBeModifiedException > > They are runtime exceptions. Should I list them in the throws clause > regardless of that? Probably, there is no need to list the above exceptions as they are "unchecked exceptions". At least, it is Ok to skip them in the "throws" list (IMHO). > >> >> >> src/share/classes/com/sun/jdi/Method.java >> line 144: * false otherwise >> Please add the following after line 144: >> >> * >> * @since 1.8 Important catch! > > Done. > >> >> src/share/classes/com/sun/jdi/ObjectReference.java >> No comments. >> >> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >> line 32: final public class ClassTypeImpl extends InvokableTypeImpl >> The switch to "final" caught my eye. I presume that >> SA-JDI does not extend this implementation class. > > To my best knowledge it does not. > >> >> Most of these changes appear to be due to refactoring with >> the new InvokableTypeImpl.java. Tried to do a visual diff >> between the common parts of this file and InvokableTypeImpl.java. >> Didn't see anything obviously wrong. I looked at the refactoring very thoroughly. The changes look fine. >> >> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >> Most of these changes appear to be due to refactoring with >> the new InvokableTypeImpl.java. Tried to do a visual diff >> between the common parts of this file and InvokableTypeImpl.java. >> Didn't see anything obviously wrong. I looked at the refactoring very thoroughly. The changes look fine. >> >> src/share/classes/com/sun/tools/jdi/MethodImpl.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >> No comments. >> >> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >> No comments. >> >> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >> No comments. >> >> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >> No comments. >> >> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >> Most of this code came from refactoring ClassTypeImpl.java or >> InterfaceTypeImpl.java. >> >> line 98: throws clause does not mention: >> IllegalArgumentException or VMCannotBeModifiedException > > This is a runtime exception. It hasn't been mentioned in the > ClassType#invokeMethod() throws clause too. > >> >> But I also have to wonder why this JavaDoc is here since >> this is an impl class... > > Just to add expressiveness. This method is actually declared by the > both interfaces, ClassType and InterfaceType and it kind of made sense > to have the shared implementation documented. The cleaner solution > would probably be to factor out a shared superinterface for ClassType > and InterfaceType and declare invokeMethod() there. But that would be > more disruptive than playing just with the implementations. > >> >> test/com/sun/jdi/EvalInterfaceStatic.sh >> line 35: # the above error occurs. jdb doesnt notice that this is >> Not sure what "the above error" is. I don't see an error >> example above this line. >> >> typo: "doesnt" -> "doesn't" > > This code comment is completely wrong - a remnant of copy-paste :/ I > forgot to clean it up. Sorry. > >> >> test/com/sun/jdi/InterfaceMethodsTest.java >> Very nice test! Indeed! Thanks, Serguei >> >> Dan > > The updated webrev - > http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ > > -JB- > >> >> >>> >>> With JDK8 it became possible to have methods with implementation in >>> interfaces - static and default interface methods. However the JDI and >>> JDWP were not updated to reflect these capabilities so it is not >>> currently possible to invoke a static or default interface method >>> programatically from the debugger. >>> >>> This patch adds support for static and default interface methods to >>> JDI, JDWP and JDB. >>> >>> Thanks, >>> >>> -JB- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Apr 29 07:32:20 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 09:32:20 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535E93D2.3020103@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> <535E93D2.3020103@oracle.com> Message-ID: <535F5584.4080501@oracle.com> On 28.4.2014 19:45, Daniel D. Daugherty wrote: > On 4/28/14 3:59 AM, Jaroslav Bachorik wrote: >> Thanks Dan! >> >> >> On 25.4.2014 20:08, Daniel D. Daugherty wrote: >>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>> Please, review the following patch: >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>> >>> make/data/jdwp/jdwp.spec >>> line 1256: "

Since JDWP version 1.8 >>> Missing the ending double quote. >> >> Fixed. >> >>> >>> line 1281: "suspended by an event or by command. " >>> "by command" isn't clear. "by this command", "by a command" >>> or something else more specific would be good. > > You didn't say anything about this one... The same as the one below. Copied over from the ClassType#InvokeMethod documentation. If it is to be changed it should be changed in both places. > > >>> >>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >>> method.") >>> The above description permits a 'methodID' value that >>> is not for a method in the 'clazz' interface. Perhaps >>> add "in the interface specified by clazz" at the end >>> of the description? >> >> This text is copied over from the ClassType#InvokeMethod. Should I >> change it there too? > > Probably. Check with Staffan L for another set of eyes... > > >> >>> >>> src/share/back/VirtualMachineImpl.c >>> No comments. >>> >>> src/share/back/debugDispatch.c >>> No comments. >>> >>> src/share/back/util.c >>> No comments. >>> >>> src/share/classes/com/sun/jdi/ClassType.java >>> No comments. >>> >>> src/share/classes/com/sun/jdi/InterfaceType.java >>> line 88: * but not a static initializer. >>> The 'jdwp.spec' wording does not mention this restriction. >> >> Mentioned this restriction in jdwp.spec >> >>> >>> typo line 107: * enclosing class's class loader). >>> typo line 184: * loaded through the enclosing class's class >>> loader. >>> -> enclosing class' class loader >> >> Fixed. Also in ClassType (the comments were copied over from there >> with typos ...) >> >>> >>> line 189: * @throws VMCannotBeModifiedException ... >>> Please add the following after line 189: >>> >>> * >>> * @since 1.8 >>> >> >> Done. >> >>> line 193-196: These exception are not named in the throws clause: >>> IllegalArgumentException, VMCannotBeModifiedException >> >> They are runtime exceptions. Should I list them in the throws clause >> regardless of that? > > I should have checked for that. I'm pretty sure we don't put > runtime exceptions in the 'throws' clause... Of course, I'm > not enough of a Java programmer to know why putting them there > would be a bad idea or bad style or... It would be basically a no-op. Since they are unchecked exceptions the API users can freely choose to ignore them. > > >> >>> >>> >>> src/share/classes/com/sun/jdi/Method.java >>> line 144: * false otherwise >>> Please add the following after line 144: >>> >>> * >>> * @since 1.8 >> >> Done. >> >>> >>> src/share/classes/com/sun/jdi/ObjectReference.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >>> line 32: final public class ClassTypeImpl extends InvokableTypeImpl >>> The switch to "final" caught my eye. I presume that >>> SA-JDI does not extend this implementation class. >> >> To my best knowledge it does not. >> >>> >>> Most of these changes appear to be due to refactoring with >>> the new InvokableTypeImpl.java. Tried to do a visual diff >>> between the common parts of this file and InvokableTypeImpl.java. >>> Didn't see anything obviously wrong. >>> >>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >>> Most of these changes appear to be due to refactoring with >>> the new InvokableTypeImpl.java. Tried to do a visual diff >>> between the common parts of this file and InvokableTypeImpl.java. >>> Didn't see anything obviously wrong. >>> >>> src/share/classes/com/sun/tools/jdi/MethodImpl.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>> No comments. >>> >>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >>> No comments. >>> >>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>> Most of this code came from refactoring ClassTypeImpl.java or >>> InterfaceTypeImpl.java. >>> >>> line 98: throws clause does not mention: >>> IllegalArgumentException or VMCannotBeModifiedException >> >> This is a runtime exception. It hasn't been mentioned in the >> ClassType#invokeMethod() throws clause too. > > Same as above. > > >> >>> >>> But I also have to wonder why this JavaDoc is here since >>> this is an impl class... >> >> Just to add expressiveness. This method is actually declared by the >> both interfaces, ClassType and InterfaceType and it kind of made sense >> to have the shared implementation documented. The cleaner solution >> would probably be to factor out a shared superinterface for ClassType >> and InterfaceType and declare invokeMethod() there. But that would be >> more disruptive than playing just with the implementations. >> >>> >>> test/com/sun/jdi/EvalInterfaceStatic.sh >>> line 35: # the above error occurs. jdb doesnt notice that this is >>> Not sure what "the above error" is. I don't see an error >>> example above this line. >>> >>> typo: "doesnt" -> "doesn't" >> >> This code comment is completely wrong - a remnant of copy-paste :/ I >> forgot to clean it up. Sorry. > > No problem. > > >> >>> >>> test/com/sun/jdi/InterfaceMethodsTest.java >>> Very nice test! >>> >>> Dan >> >> The updated webrev - >> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ > > Sounds good. Don't know when I'll get a chance for a re-review so > please don't wait for me. Ok. Thanks for taking time to review this! -JB- > > Dan > > >> >> -JB- >> >>> >>> >>>> >>>> With JDK8 it became possible to have methods with implementation in >>>> interfaces - static and default interface methods. However the JDI and >>>> JDWP were not updated to reflect these capabilities so it is not >>>> currently possible to invoke a static or default interface method >>>> programatically from the debugger. >>>> >>>> This patch adds support for static and default interface methods to >>>> JDI, JDWP and JDB. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Tue Apr 29 07:57:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 09:57:40 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535EDE07.4020104@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> <535EDE07.4020104@oracle.com> Message-ID: <535F5B74.7010103@oracle.com> Hi Serguei, On 29.4.2014 01:02, serguei.spitsyn at oracle.com wrote: > Hi Jaroslav, > > I looked at the new webrev: > http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ > > The fixes look fine to me modulo comments below. > This is a great job in general. Yeah, I had great support from you guys when undertaking this! I've corrected the wordings and fixed the typos. http://cr.openjdk.java.net/~jbachorik/8031195/webrev.06 I hope these will be the last changes necessary. -JB- > > > On 4/28/14 2:59 AM, Jaroslav Bachorik wrote: >> Thanks Dan! > > Indeed, Dan, thank you for the thorough review and nice catches! > And Jaroslav, thank you for your patience! > >> >> >> On 25.4.2014 20:08, Daniel D. Daugherty wrote: >>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>> Please, review the following patch: >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>> >>> make/data/jdwp/jdwp.spec >>> line 1256: "

Since JDWP version 1.8 >>> Missing the ending double quote. >> >> Fixed. >> >>> >>> line 1281: "suspended by an event or by command. " >>> "by command" isn't clear. "by this command", "by a command" >>> or something else more specific would be good. > > This has not been fixed yet, changing to the following would work Ok: > > 1282 "suspended by an event or by*a* command. " > > >>> >>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >>> method.") >>> The above description permits a 'methodID' value that >>> is not for a method in the 'clazz' interface. Perhaps >>> add "in the interface specified by clazz" at the end >>> of the description? >> >> This text is copied over from the ClassType#InvokeMethod. Should I >> change it there too? > > Probably, something like this is needed: > > . . . > 1147 (ErrorSet > 1148 (Error INVALID_CLASS "clazz is not the ID of a > class.") > 1149 (Error INVALID_OBJECT "clazz is not a known ID.") > 1150 (Error INVALID_METHODID "methodID is not the ID of > a*static* method* in" > "this class type or one of > its superclasses*.") > > . . . > 1320 (ErrorSet > 1321 (Error INVALID_CLASS "clazz is not the ID of an > interface.") > 1322 (Error INVALID_OBJECT "clazz is not a known ID.") > 1323 (Error INVALID_METHODID "methodID is not the ID of > a*static* method* in this"** > ** ***"interface* type or is > the ID of a static initializer*.") > > . . . > 1661 (ErrorSet > 1662 (Error INVALID_OBJECT) > 1663 (Error INVALID_CLASS "clazz is not the ID of a > reference " > 1664 "type.") > 1665 (Error INVALID_METHODID "methodID is not the ID of a*n > instance* method* in this object's type** or"** > ** "**one of its superclasses, > superinterfaces, or implemented interfaces*.") > >> >>> >>> src/share/back/VirtualMachineImpl.c >>> No comments. >>> >>> src/share/back/debugDispatch.c >>> No comments. >>> >>> src/share/back/util.c >>> No comments. >>> >>> src/share/classes/com/sun/jdi/ClassType.java >>> No comments. >>> >>> src/share/classes/com/sun/jdi/InterfaceType.java >>> line 88: * but not a static initializer. >>> The 'jdwp.spec' wording does not mention this restriction. >> >> Mentioned this restriction in jdwp.spec >> >>> >>> typo line 107: * enclosing class's class loader). >>> typo line 184: * loaded through the enclosing class's class >>> loader. >>> -> enclosing class' class loader >> >> Fixed. Also in ClassType (the comments were copied over from there >> with typos ...) > > This one is still unchanged: > > 184 * loaded through the enclosing*class's* class loader. > > Also need to be fixed in the src/share/classes/com/sun/jdi/ClassType.java: > > 106 * enclosing class's class loader). Primitive values must be > > 233 * loaded through the enclosing class's class loader. > > 270 * enclosing class's class loader). Primitive arguments must be > > 338 * loaded through the enclosing class's class loader. > > > >> >>> >>> line 189: * @throws VMCannotBeModifiedException ... >>> Please add the following after line 189: >>> >>> * >>> * @since 1.8 > > Important catch! > >>> >> >> Done. >> >>> line 193-196: These exception are not named in the throws clause: >>> IllegalArgumentException, VMCannotBeModifiedException >> >> They are runtime exceptions. Should I list them in the throws clause >> regardless of that? > > Probably, there is no need to list the above exceptions as they are > "unchecked exceptions". > At least, it is Ok to skip them in the "throws" list (IMHO). > >> >>> >>> >>> src/share/classes/com/sun/jdi/Method.java >>> line 144: * false otherwise >>> Please add the following after line 144: >>> >>> * >>> * @since 1.8 > > Important catch! > >> >> Done. >> >>> >>> src/share/classes/com/sun/jdi/ObjectReference.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >>> line 32: final public class ClassTypeImpl extends InvokableTypeImpl >>> The switch to "final" caught my eye. I presume that >>> SA-JDI does not extend this implementation class. >> >> To my best knowledge it does not. >> >>> >>> Most of these changes appear to be due to refactoring with >>> the new InvokableTypeImpl.java. Tried to do a visual diff >>> between the common parts of this file and InvokableTypeImpl.java. >>> Didn't see anything obviously wrong. > > I looked at the refactoring very thoroughly. > The changes look fine. > > >>> >>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >>> Most of these changes appear to be due to refactoring with >>> the new InvokableTypeImpl.java. Tried to do a visual diff >>> between the common parts of this file and InvokableTypeImpl.java. >>> Didn't see anything obviously wrong. > > I looked at the refactoring very thoroughly. > The changes look fine. > >>> >>> src/share/classes/com/sun/tools/jdi/MethodImpl.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>> No comments. >>> >>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >>> No comments. >>> >>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >>> No comments. >>> >>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>> Most of this code came from refactoring ClassTypeImpl.java or >>> InterfaceTypeImpl.java. >>> >>> line 98: throws clause does not mention: >>> IllegalArgumentException or VMCannotBeModifiedException >> >> This is a runtime exception. It hasn't been mentioned in the >> ClassType#invokeMethod() throws clause too. >> >>> >>> But I also have to wonder why this JavaDoc is here since >>> this is an impl class... >> >> Just to add expressiveness. This method is actually declared by the >> both interfaces, ClassType and InterfaceType and it kind of made sense >> to have the shared implementation documented. The cleaner solution >> would probably be to factor out a shared superinterface for ClassType >> and InterfaceType and declare invokeMethod() there. But that would be >> more disruptive than playing just with the implementations. >> >>> >>> test/com/sun/jdi/EvalInterfaceStatic.sh >>> line 35: # the above error occurs. jdb doesnt notice that this is >>> Not sure what "the above error" is. I don't see an error >>> example above this line. >>> >>> typo: "doesnt" -> "doesn't" >> >> This code comment is completely wrong - a remnant of copy-paste :/ I >> forgot to clean it up. Sorry. >> >>> >>> test/com/sun/jdi/InterfaceMethodsTest.java >>> Very nice test! > > Indeed! > > > Thanks, > Serguei > >>> >>> Dan >> >> The updated webrev - >> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >> >> -JB- >> >>> >>> >>>> >>>> With JDK8 it became possible to have methods with implementation in >>>> interfaces - static and default interface methods. However the JDI and >>>> JDWP were not updated to reflect these capabilities so it is not >>>> currently possible to invoke a static or default interface method >>>> programatically from the debugger. >>>> >>>> This patch adds support for static and default interface methods to >>>> JDI, JDWP and JDB. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > > From serguei.spitsyn at oracle.com Tue Apr 29 08:12:52 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 29 Apr 2014 01:12:52 -0700 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535F5B74.7010103@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> <535EDE07.4020104@oracle.com> <535F5B74.7010103@oracle.com> Message-ID: <535F5F04.5020209@oracle.com> Hi Jaroslav, make/data/jdwp/jdwp.spec Just a minor comment: an extra space or a TAB in the "staticmethod": 1150 (Error INVALID_METHODID "methodID is not the ID of a static method in " Reviewed. Thanks, Serguei On 4/29/14 12:57 AM, Jaroslav Bachorik wrote: > Hi Serguei, > > On 29.4.2014 01:02, serguei.spitsyn at oracle.com wrote: >> Hi Jaroslav, >> >> I looked at the new webrev: >> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >> >> The fixes look fine to me modulo comments below. >> This is a great job in general. > > Yeah, I had great support from you guys when undertaking this! > > I've corrected the wordings and fixed the typos. > > http://cr.openjdk.java.net/~jbachorik/8031195/webrev.06 > > I hope these will be the last changes necessary. > > -JB- > > >> >> >> On 4/28/14 2:59 AM, Jaroslav Bachorik wrote: >>> Thanks Dan! >> >> Indeed, Dan, thank you for the thorough review and nice catches! >> And Jaroslav, thank you for your patience! >> >>> >>> >>> On 25.4.2014 20:08, Daniel D. Daugherty wrote: >>>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>>> Please, review the following patch: >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>>> >>>> make/data/jdwp/jdwp.spec >>>> line 1256: "

Since JDWP version 1.8 >>>> Missing the ending double quote. >>> >>> Fixed. >>> >>>> >>>> line 1281: "suspended by an event or by command. " >>>> "by command" isn't clear. "by this command", "by a command" >>>> or something else more specific would be good. >> >> This has not been fixed yet, changing to the following would work Ok: >> >> 1282 "suspended by an event or by*a* command. " >> >> >>>> >>>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >>>> method.") >>>> The above description permits a 'methodID' value that >>>> is not for a method in the 'clazz' interface. Perhaps >>>> add "in the interface specified by clazz" at the end >>>> of the description? >>> >>> This text is copied over from the ClassType#InvokeMethod. Should I >>> change it there too? >> >> Probably, something like this is needed: >> >> . . . >> 1147 (ErrorSet >> 1148 (Error INVALID_CLASS "clazz is not the ID of a >> class.") >> 1149 (Error INVALID_OBJECT "clazz is not a known ID.") >> 1150 (Error INVALID_METHODID "methodID is not the ID of >> a*static* method* in" >> "this class type or one of >> its superclasses*.") >> >> . . . >> 1320 (ErrorSet >> 1321 (Error INVALID_CLASS "clazz is not the ID of an >> interface.") >> 1322 (Error INVALID_OBJECT "clazz is not a known ID.") >> 1323 (Error INVALID_METHODID "methodID is not the ID of >> a*static* method* in this"** >> ** ***"interface* type or is >> the ID of a static initializer*.") >> >> . . . >> 1661 (ErrorSet >> 1662 (Error INVALID_OBJECT) >> 1663 (Error INVALID_CLASS "clazz is not the ID of a >> reference " >> 1664 "type.") >> 1665 (Error INVALID_METHODID "methodID is not the ID of a*n >> instance* method* in this object's type** or"** >> ** "**one of its superclasses, >> superinterfaces, or implemented interfaces*.") >> >>> >>>> >>>> src/share/back/VirtualMachineImpl.c >>>> No comments. >>>> >>>> src/share/back/debugDispatch.c >>>> No comments. >>>> >>>> src/share/back/util.c >>>> No comments. >>>> >>>> src/share/classes/com/sun/jdi/ClassType.java >>>> No comments. >>>> >>>> src/share/classes/com/sun/jdi/InterfaceType.java >>>> line 88: * but not a static initializer. >>>> The 'jdwp.spec' wording does not mention this restriction. >>> >>> Mentioned this restriction in jdwp.spec >>> >>>> >>>> typo line 107: * enclosing class's class loader). >>>> typo line 184: * loaded through the enclosing class's >>>> class >>>> loader. >>>> -> enclosing class' class loader >>> >>> Fixed. Also in ClassType (the comments were copied over from there >>> with typos ...) >> >> This one is still unchanged: >> >> 184 * loaded through the enclosing*class's* class loader. >> >> Also need to be fixed in the >> src/share/classes/com/sun/jdi/ClassType.java: >> >> 106 * enclosing class's class loader). Primitive values must be >> >> 233 * loaded through the enclosing class's class loader. >> >> 270 * enclosing class's class loader). Primitive arguments >> must be >> >> 338 * loaded through the enclosing class's class loader. >> >> >> >>> >>>> >>>> line 189: * @throws VMCannotBeModifiedException ... >>>> Please add the following after line 189: >>>> >>>> * >>>> * @since 1.8 >> >> Important catch! >> >>>> >>> >>> Done. >>> >>>> line 193-196: These exception are not named in the throws clause: >>>> IllegalArgumentException, VMCannotBeModifiedException >>> >>> They are runtime exceptions. Should I list them in the throws clause >>> regardless of that? >> >> Probably, there is no need to list the above exceptions as they are >> "unchecked exceptions". >> At least, it is Ok to skip them in the "throws" list (IMHO). >> >>> >>>> >>>> >>>> src/share/classes/com/sun/jdi/Method.java >>>> line 144: * false otherwise >>>> Please add the following after line 144: >>>> >>>> * >>>> * @since 1.8 >> >> Important catch! >> >>> >>> Done. >>> >>>> >>>> src/share/classes/com/sun/jdi/ObjectReference.java >>>> No comments. >>>> >>>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >>>> No comments. >>>> >>>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >>>> line 32: final public class ClassTypeImpl extends >>>> InvokableTypeImpl >>>> The switch to "final" caught my eye. I presume that >>>> SA-JDI does not extend this implementation class. >>> >>> To my best knowledge it does not. >>> >>>> >>>> Most of these changes appear to be due to refactoring with >>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>> between the common parts of this file and InvokableTypeImpl.java. >>>> Didn't see anything obviously wrong. >> >> I looked at the refactoring very thoroughly. >> The changes look fine. >> >> >>>> >>>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >>>> Most of these changes appear to be due to refactoring with >>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>> between the common parts of this file and InvokableTypeImpl.java. >>>> Didn't see anything obviously wrong. >> >> I looked at the refactoring very thoroughly. >> The changes look fine. >> >>>> >>>> src/share/classes/com/sun/tools/jdi/MethodImpl.java >>>> No comments. >>>> >>>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >>>> No comments. >>>> >>>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>>> No comments. >>>> >>>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >>>> No comments. >>>> >>>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >>>> No comments. >>>> >>>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>> Most of this code came from refactoring ClassTypeImpl.java or >>>> InterfaceTypeImpl.java. >>>> >>>> line 98: throws clause does not mention: >>>> IllegalArgumentException or VMCannotBeModifiedException >>> >>> This is a runtime exception. It hasn't been mentioned in the >>> ClassType#invokeMethod() throws clause too. >>> >>>> >>>> But I also have to wonder why this JavaDoc is here since >>>> this is an impl class... >>> >>> Just to add expressiveness. This method is actually declared by the >>> both interfaces, ClassType and InterfaceType and it kind of made sense >>> to have the shared implementation documented. The cleaner solution >>> would probably be to factor out a shared superinterface for ClassType >>> and InterfaceType and declare invokeMethod() there. But that would be >>> more disruptive than playing just with the implementations. >>> >>>> >>>> test/com/sun/jdi/EvalInterfaceStatic.sh >>>> line 35: # the above error occurs. jdb doesnt notice that >>>> this is >>>> Not sure what "the above error" is. I don't see an error >>>> example above this line. >>>> >>>> typo: "doesnt" -> "doesn't" >>> >>> This code comment is completely wrong - a remnant of copy-paste :/ I >>> forgot to clean it up. Sorry. >>> >>>> >>>> test/com/sun/jdi/InterfaceMethodsTest.java >>>> Very nice test! >> >> Indeed! >> >> >> Thanks, >> Serguei >> >>>> >>>> Dan >>> >>> The updated webrev - >>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >>> >>> -JB- >>> >>>> >>>> >>>>> >>>>> With JDK8 it became possible to have methods with implementation in >>>>> interfaces - static and default interface methods. However the JDI >>>>> and >>>>> JDWP were not updated to reflect these capabilities so it is not >>>>> currently possible to invoke a static or default interface method >>>>> programatically from the debugger. >>>>> >>>>> This patch adds support for static and default interface methods to >>>>> JDI, JDWP and JDB. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> >> > From ivan.gerasimov at oracle.com Tue Apr 29 08:48:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 29 Apr 2014 12:48:08 +0400 Subject: RFR: [8040790] TEST_BUG: tools/javac/innerClassFile/Driver.sh fails to cleanup files after it Message-ID: <535F6748.6060809@oracle.com> Hello! This is a 7u-only test-stabilization one-line fix. The test was reported to not clean after itself, which sometimes causes problems. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040790 WEBREV: http://cr.openjdk.java.net/~igerasim/8040790/0/webrev/ Sincerely yours, Ivan From jaroslav.bachorik at oracle.com Tue Apr 29 08:57:16 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 10:57:16 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535F5F04.5020209@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> <535EDE07.4020104@oracle.com> <535F5B74.7010103@oracle.com> <535F5F04.5020209@oracle.com> Message-ID: <535F696C.8020607@oracle.com> On 29.4.2014 10:12, serguei.spitsyn at oracle.com wrote: > Hi Jaroslav, > > make/data/jdwp/jdwp.spec > Just a minor comment: an extra space or a TAB in the "staticmethod": > > 1150 (Error INVALID_METHODID "methodID is not the ID of a > static method in " Gone ... http://cr.openjdk.java.net/~jbachorik/8031195/webrev.07 Could I have a "seal-of-approval" from a Reviewer, please? -JB- > > > Reviewed. > > Thanks, > Serguei > > > On 4/29/14 12:57 AM, Jaroslav Bachorik wrote: >> Hi Serguei, >> >> On 29.4.2014 01:02, serguei.spitsyn at oracle.com wrote: >>> Hi Jaroslav, >>> >>> I looked at the new webrev: >>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >>> >>> The fixes look fine to me modulo comments below. >>> This is a great job in general. >> >> Yeah, I had great support from you guys when undertaking this! >> >> I've corrected the wordings and fixed the typos. >> >> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.06 >> >> I hope these will be the last changes necessary. >> >> -JB- >> >> >>> >>> >>> On 4/28/14 2:59 AM, Jaroslav Bachorik wrote: >>>> Thanks Dan! >>> >>> Indeed, Dan, thank you for the thorough review and nice catches! >>> And Jaroslav, thank you for your patience! >>> >>>> >>>> >>>> On 25.4.2014 20:08, Daniel D. Daugherty wrote: >>>>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the following patch: >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>>>> >>>>> make/data/jdwp/jdwp.spec >>>>> line 1256: "

Since JDWP version 1.8 >>>>> Missing the ending double quote. >>>> >>>> Fixed. >>>> >>>>> >>>>> line 1281: "suspended by an event or by command. " >>>>> "by command" isn't clear. "by this command", "by a command" >>>>> or something else more specific would be good. >>> >>> This has not been fixed yet, changing to the following would work Ok: >>> >>> 1282 "suspended by an event or by*a* command. " >>> >>> >>>>> >>>>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >>>>> method.") >>>>> The above description permits a 'methodID' value that >>>>> is not for a method in the 'clazz' interface. Perhaps >>>>> add "in the interface specified by clazz" at the end >>>>> of the description? >>>> >>>> This text is copied over from the ClassType#InvokeMethod. Should I >>>> change it there too? >>> >>> Probably, something like this is needed: >>> >>> . . . >>> 1147 (ErrorSet >>> 1148 (Error INVALID_CLASS "clazz is not the ID of a >>> class.") >>> 1149 (Error INVALID_OBJECT "clazz is not a known ID.") >>> 1150 (Error INVALID_METHODID "methodID is not the ID of >>> a*static* method* in" >>> "this class type or one of >>> its superclasses*.") >>> >>> . . . >>> 1320 (ErrorSet >>> 1321 (Error INVALID_CLASS "clazz is not the ID of an >>> interface.") >>> 1322 (Error INVALID_OBJECT "clazz is not a known ID.") >>> 1323 (Error INVALID_METHODID "methodID is not the ID of >>> a*static* method* in this"** >>> ** ***"interface* type or is >>> the ID of a static initializer*.") >>> >>> . . . >>> 1661 (ErrorSet >>> 1662 (Error INVALID_OBJECT) >>> 1663 (Error INVALID_CLASS "clazz is not the ID of a >>> reference " >>> 1664 "type.") >>> 1665 (Error INVALID_METHODID "methodID is not the ID of a*n >>> instance* method* in this object's type** or"** >>> ** "**one of its superclasses, >>> superinterfaces, or implemented interfaces*.") >>> >>>> >>>>> >>>>> src/share/back/VirtualMachineImpl.c >>>>> No comments. >>>>> >>>>> src/share/back/debugDispatch.c >>>>> No comments. >>>>> >>>>> src/share/back/util.c >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/jdi/ClassType.java >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/jdi/InterfaceType.java >>>>> line 88: * but not a static initializer. >>>>> The 'jdwp.spec' wording does not mention this restriction. >>>> >>>> Mentioned this restriction in jdwp.spec >>>> >>>>> >>>>> typo line 107: * enclosing class's class loader). >>>>> typo line 184: * loaded through the enclosing class's >>>>> class >>>>> loader. >>>>> -> enclosing class' class loader >>>> >>>> Fixed. Also in ClassType (the comments were copied over from there >>>> with typos ...) >>> >>> This one is still unchanged: >>> >>> 184 * loaded through the enclosing*class's* class loader. >>> >>> Also need to be fixed in the >>> src/share/classes/com/sun/jdi/ClassType.java: >>> >>> 106 * enclosing class's class loader). Primitive values must be >>> >>> 233 * loaded through the enclosing class's class loader. >>> >>> 270 * enclosing class's class loader). Primitive arguments >>> must be >>> >>> 338 * loaded through the enclosing class's class loader. >>> >>> >>> >>>> >>>>> >>>>> line 189: * @throws VMCannotBeModifiedException ... >>>>> Please add the following after line 189: >>>>> >>>>> * >>>>> * @since 1.8 >>> >>> Important catch! >>> >>>>> >>>> >>>> Done. >>>> >>>>> line 193-196: These exception are not named in the throws clause: >>>>> IllegalArgumentException, VMCannotBeModifiedException >>>> >>>> They are runtime exceptions. Should I list them in the throws clause >>>> regardless of that? >>> >>> Probably, there is no need to list the above exceptions as they are >>> "unchecked exceptions". >>> At least, it is Ok to skip them in the "throws" list (IMHO). >>> >>>> >>>>> >>>>> >>>>> src/share/classes/com/sun/jdi/Method.java >>>>> line 144: * false otherwise >>>>> Please add the following after line 144: >>>>> >>>>> * >>>>> * @since 1.8 >>> >>> Important catch! >>> >>>> >>>> Done. >>>> >>>>> >>>>> src/share/classes/com/sun/jdi/ObjectReference.java >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >>>>> line 32: final public class ClassTypeImpl extends >>>>> InvokableTypeImpl >>>>> The switch to "final" caught my eye. I presume that >>>>> SA-JDI does not extend this implementation class. >>>> >>>> To my best knowledge it does not. >>>> >>>>> >>>>> Most of these changes appear to be due to refactoring with >>>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>>> between the common parts of this file and InvokableTypeImpl.java. >>>>> Didn't see anything obviously wrong. >>> >>> I looked at the refactoring very thoroughly. >>> The changes look fine. >>> >>> >>>>> >>>>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >>>>> Most of these changes appear to be due to refactoring with >>>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>>> between the common parts of this file and InvokableTypeImpl.java. >>>>> Didn't see anything obviously wrong. >>> >>> I looked at the refactoring very thoroughly. >>> The changes look fine. >>> >>>>> >>>>> src/share/classes/com/sun/tools/jdi/MethodImpl.java >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>>>> No comments. >>>>> >>>>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >>>>> No comments. >>>>> >>>>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >>>>> No comments. >>>>> >>>>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>>> Most of this code came from refactoring ClassTypeImpl.java or >>>>> InterfaceTypeImpl.java. >>>>> >>>>> line 98: throws clause does not mention: >>>>> IllegalArgumentException or VMCannotBeModifiedException >>>> >>>> This is a runtime exception. It hasn't been mentioned in the >>>> ClassType#invokeMethod() throws clause too. >>>> >>>>> >>>>> But I also have to wonder why this JavaDoc is here since >>>>> this is an impl class... >>>> >>>> Just to add expressiveness. This method is actually declared by the >>>> both interfaces, ClassType and InterfaceType and it kind of made sense >>>> to have the shared implementation documented. The cleaner solution >>>> would probably be to factor out a shared superinterface for ClassType >>>> and InterfaceType and declare invokeMethod() there. But that would be >>>> more disruptive than playing just with the implementations. >>>> >>>>> >>>>> test/com/sun/jdi/EvalInterfaceStatic.sh >>>>> line 35: # the above error occurs. jdb doesnt notice that >>>>> this is >>>>> Not sure what "the above error" is. I don't see an error >>>>> example above this line. >>>>> >>>>> typo: "doesnt" -> "doesn't" >>>> >>>> This code comment is completely wrong - a remnant of copy-paste :/ I >>>> forgot to clean it up. Sorry. >>>> >>>>> >>>>> test/com/sun/jdi/InterfaceMethodsTest.java >>>>> Very nice test! >>> >>> Indeed! >>> >>> >>> Thanks, >>> Serguei >>> >>>>> >>>>> Dan >>>> >>>> The updated webrev - >>>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >>>> >>>> -JB- >>>> >>>>> >>>>> >>>>>> >>>>>> With JDK8 it became possible to have methods with implementation in >>>>>> interfaces - static and default interface methods. However the JDI >>>>>> and >>>>>> JDWP were not updated to reflect these capabilities so it is not >>>>>> currently possible to invoke a static or default interface method >>>>>> programatically from the debugger. >>>>>> >>>>>> This patch adds support for static and default interface methods to >>>>>> JDI, JDWP and JDB. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >>> >> > From staffan.larsen at oracle.com Tue Apr 29 09:10:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Apr 2014 11:10:01 +0200 Subject: RFR 8031195: Support default and static interface methods in JDI, JDWP and JDB In-Reply-To: <535F696C.8020607@oracle.com> References: <535908F7.4040000@oracle.com> <535AA4A5.9020502@oracle.com> <535E2684.8010902@oracle.com> <535EDE07.4020104@oracle.com> <535F5B74.7010103@oracle.com> <535F5F04.5020209@oracle.com> <535F696C.8020607@oracle.com> Message-ID: <617EA0DD-96A0-4530-B57B-43C68E3302D8@oracle.com> Very nice! Good to go. /Staffan On 29 apr 2014, at 10:57, Jaroslav Bachorik wrote: > On 29.4.2014 10:12, serguei.spitsyn at oracle.com wrote: >> Hi Jaroslav, >> >> make/data/jdwp/jdwp.spec >> Just a minor comment: an extra space or a TAB in the "staticmethod": >> >> 1150 (Error INVALID_METHODID "methodID is not the ID of a >> static method in " > > Gone ... > http://cr.openjdk.java.net/~jbachorik/8031195/webrev.07 > > Could I have a "seal-of-approval" from a Reviewer, please? > > -JB- > >> >> >> Reviewed. >> >> Thanks, >> Serguei >> >> >> On 4/29/14 12:57 AM, Jaroslav Bachorik wrote: >>> Hi Serguei, >>> >>> On 29.4.2014 01:02, serguei.spitsyn at oracle.com wrote: >>>> Hi Jaroslav, >>>> >>>> I looked at the new webrev: >>>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >>>> >>>> The fixes look fine to me modulo comments below. >>>> This is a great job in general. >>> >>> Yeah, I had great support from you guys when undertaking this! >>> >>> I've corrected the wordings and fixed the typos. >>> >>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.06 >>> >>> I hope these will be the last changes necessary. >>> >>> -JB- >>> >>> >>>> >>>> >>>> On 4/28/14 2:59 AM, Jaroslav Bachorik wrote: >>>>> Thanks Dan! >>>> >>>> Indeed, Dan, thank you for the thorough review and nice catches! >>>> And Jaroslav, thank you for your patience! >>>> >>>>> >>>>> >>>>> On 25.4.2014 20:08, Daniel D. Daugherty wrote: >>>>>> On 4/24/14 6:52 AM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following patch: >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031195 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031195/webrev.04 >>>>>> >>>>>> make/data/jdwp/jdwp.spec >>>>>> line 1256: "

Since JDWP version 1.8 >>>>>> Missing the ending double quote. >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> line 1281: "suspended by an event or by command. " >>>>>> "by command" isn't clear. "by this command", "by a command" >>>>>> or something else more specific would be good. >>>> >>>> This has not been fixed yet, changing to the following would work Ok: >>>> >>>> 1282 "suspended by an event or by*a* command. " >>>> >>>> >>>>>> >>>>>> line 1322: (Error INVALID_METHODID "methodID is not the ID of a >>>>>> method.") >>>>>> The above description permits a 'methodID' value that >>>>>> is not for a method in the 'clazz' interface. Perhaps >>>>>> add "in the interface specified by clazz" at the end >>>>>> of the description? >>>>> >>>>> This text is copied over from the ClassType#InvokeMethod. Should I >>>>> change it there too? >>>> >>>> Probably, something like this is needed: >>>> >>>> . . . >>>> 1147 (ErrorSet >>>> 1148 (Error INVALID_CLASS "clazz is not the ID of a >>>> class.") >>>> 1149 (Error INVALID_OBJECT "clazz is not a known ID.") >>>> 1150 (Error INVALID_METHODID "methodID is not the ID of >>>> a*static* method* in" >>>> "this class type or one of >>>> its superclasses*.") >>>> >>>> . . . >>>> 1320 (ErrorSet >>>> 1321 (Error INVALID_CLASS "clazz is not the ID of an >>>> interface.") >>>> 1322 (Error INVALID_OBJECT "clazz is not a known ID.") >>>> 1323 (Error INVALID_METHODID "methodID is not the ID of >>>> a*static* method* in this"** >>>> ** ***"interface* type or is >>>> the ID of a static initializer*.") >>>> >>>> . . . >>>> 1661 (ErrorSet >>>> 1662 (Error INVALID_OBJECT) >>>> 1663 (Error INVALID_CLASS "clazz is not the ID of a >>>> reference " >>>> 1664 "type.") >>>> 1665 (Error INVALID_METHODID "methodID is not the ID of a*n >>>> instance* method* in this object's type** or"** >>>> ** "**one of its superclasses, >>>> superinterfaces, or implemented interfaces*.") >>>> >>>>> >>>>>> >>>>>> src/share/back/VirtualMachineImpl.c >>>>>> No comments. >>>>>> >>>>>> src/share/back/debugDispatch.c >>>>>> No comments. >>>>>> >>>>>> src/share/back/util.c >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/jdi/ClassType.java >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/jdi/InterfaceType.java >>>>>> line 88: * but not a static initializer. >>>>>> The 'jdwp.spec' wording does not mention this restriction. >>>>> >>>>> Mentioned this restriction in jdwp.spec >>>>> >>>>>> >>>>>> typo line 107: * enclosing class's class loader). >>>>>> typo line 184: * loaded through the enclosing class's >>>>>> class >>>>>> loader. >>>>>> -> enclosing class' class loader >>>>> >>>>> Fixed. Also in ClassType (the comments were copied over from there >>>>> with typos ...) >>>> >>>> This one is still unchanged: >>>> >>>> 184 * loaded through the enclosing*class's* class loader. >>>> >>>> Also need to be fixed in the >>>> src/share/classes/com/sun/jdi/ClassType.java: >>>> >>>> 106 * enclosing class's class loader). Primitive values must be >>>> >>>> 233 * loaded through the enclosing class's class loader. >>>> >>>> 270 * enclosing class's class loader). Primitive arguments >>>> must be >>>> >>>> 338 * loaded through the enclosing class's class loader. >>>> >>>> >>>> >>>>> >>>>>> >>>>>> line 189: * @throws VMCannotBeModifiedException ... >>>>>> Please add the following after line 189: >>>>>> >>>>>> * >>>>>> * @since 1.8 >>>> >>>> Important catch! >>>> >>>>>> >>>>> >>>>> Done. >>>>> >>>>>> line 193-196: These exception are not named in the throws clause: >>>>>> IllegalArgumentException, VMCannotBeModifiedException >>>>> >>>>> They are runtime exceptions. Should I list them in the throws clause >>>>> regardless of that? >>>> >>>> Probably, there is no need to list the above exceptions as they are >>>> "unchecked exceptions". >>>> At least, it is Ok to skip them in the "throws" list (IMHO). >>>> >>>>> >>>>>> >>>>>> >>>>>> src/share/classes/com/sun/jdi/Method.java >>>>>> line 144: * false otherwise >>>>>> Please add the following after line 144: >>>>>> >>>>>> * >>>>>> * @since 1.8 >>>> >>>> Important catch! >>>> >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> src/share/classes/com/sun/jdi/ObjectReference.java >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/tools/example/debug/expr/LValue.java >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java >>>>>> line 32: final public class ClassTypeImpl extends >>>>>> InvokableTypeImpl >>>>>> The switch to "final" caught my eye. I presume that >>>>>> SA-JDI does not extend this implementation class. >>>>> >>>>> To my best knowledge it does not. >>>>> >>>>>> >>>>>> Most of these changes appear to be due to refactoring with >>>>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>>>> between the common parts of this file and InvokableTypeImpl.java. >>>>>> Didn't see anything obviously wrong. >>>> >>>> I looked at the refactoring very thoroughly. >>>> The changes look fine. >>>> >>>> >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java >>>>>> Most of these changes appear to be due to refactoring with >>>>>> the new InvokableTypeImpl.java. Tried to do a visual diff >>>>>> between the common parts of this file and InvokableTypeImpl.java. >>>>>> Didn't see anything obviously wrong. >>>> >>>> I looked at the refactoring very thoroughly. >>>> The changes look fine. >>>> >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/MethodImpl.java >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>>>>> No comments. >>>>>> >>>>>> src/share/back/InterfaceTypeImpl.c src/share/back/ClassTypeImpl.c >>>>>> No comments. >>>>>> >>>>>> src/share/back/InterfaceTypeImpl.h src/share/back/ClassTypeImpl.h >>>>>> No comments. >>>>>> >>>>>> src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>>>> Most of this code came from refactoring ClassTypeImpl.java or >>>>>> InterfaceTypeImpl.java. >>>>>> >>>>>> line 98: throws clause does not mention: >>>>>> IllegalArgumentException or VMCannotBeModifiedException >>>>> >>>>> This is a runtime exception. It hasn't been mentioned in the >>>>> ClassType#invokeMethod() throws clause too. >>>>> >>>>>> >>>>>> But I also have to wonder why this JavaDoc is here since >>>>>> this is an impl class... >>>>> >>>>> Just to add expressiveness. This method is actually declared by the >>>>> both interfaces, ClassType and InterfaceType and it kind of made sense >>>>> to have the shared implementation documented. The cleaner solution >>>>> would probably be to factor out a shared superinterface for ClassType >>>>> and InterfaceType and declare invokeMethod() there. But that would be >>>>> more disruptive than playing just with the implementations. >>>>> >>>>>> >>>>>> test/com/sun/jdi/EvalInterfaceStatic.sh >>>>>> line 35: # the above error occurs. jdb doesnt notice that >>>>>> this is >>>>>> Not sure what "the above error" is. I don't see an error >>>>>> example above this line. >>>>>> >>>>>> typo: "doesnt" -> "doesn't" >>>>> >>>>> This code comment is completely wrong - a remnant of copy-paste :/ I >>>>> forgot to clean it up. Sorry. >>>>> >>>>>> >>>>>> test/com/sun/jdi/InterfaceMethodsTest.java >>>>>> Very nice test! >>>> >>>> Indeed! >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>>> >>>>>> Dan >>>>> >>>>> The updated webrev - >>>>> http://cr.openjdk.java.net/~jbachorik/8031195/webrev.05/ >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> With JDK8 it became possible to have methods with implementation in >>>>>>> interfaces - static and default interface methods. However the JDI >>>>>>> and >>>>>>> JDWP were not updated to reflect these capabilities so it is not >>>>>>> currently possible to invoke a static or default interface method >>>>>>> programatically from the debugger. >>>>>>> >>>>>>> This patch adds support for static and default interface methods to >>>>>>> JDI, JDWP and JDB. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>>> >>> >> > From lance.andersen at oracle.com Tue Apr 29 10:49:32 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 29 Apr 2014 06:49:32 -0400 Subject: RFR: [8040790] TEST_BUG: tools/javac/innerClassFile/Driver.sh fails to cleanup files after it In-Reply-To: <535F6748.6060809@oracle.com> References: <535F6748.6060809@oracle.com> Message-ID: This looks ok Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On Apr 29, 2014, at 4:48 AM, Ivan Gerasimov wrote: > Hello! > > This is a 7u-only test-stabilization one-line fix. > > The test was reported to not clean after itself, which sometimes causes problems. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040790 > WEBREV: http://cr.openjdk.java.net/~igerasim/8040790/0/webrev/ > > Sincerely yours, > Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Apr 29 11:28:14 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 29 Apr 2014 15:28:14 +0400 Subject: RFR: [8040790] TEST_BUG: tools/javac/innerClassFile/Driver.sh fails to cleanup files after it In-Reply-To: References: <535F6748.6060809@oracle.com> Message-ID: <535F8CCE.2030502@oracle.com> Thanks! On 29.04.2014 14:49, Lance @ Oracle wrote: > This looks ok > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > Sent from my iPad > > On Apr 29, 2014, at 4:48 AM, Ivan Gerasimov > wrote: > >> Hello! >> >> This is a 7u-only test-stabilization one-line fix. >> >> The test was reported to not clean after itself, which sometimes >> causes problems. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040790 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8040790/0/webrev/ >> >> >> Sincerely yours, >> Ivan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Apr 29 11:42:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 13:42:50 +0200 Subject: RFR 8042096: Backout JDK-8042091 Message-ID: <535F903A.3070602@oracle.com> Please, review this emergency backout. The changes introduced in fix for JDK-8042091 didn't contain SA-JDI implementation in hotspot causing JDK build breakage. The JDK part needs to be backed out till the hotspot side is ready to accept the changed APIs. The change is generated by 'hg backout -r 4e7f3aac979b' on jdk9/jdk repo. Issue : https://bugs.openjdk.java.net/browse/JDK-8042096 Webrev: http://cr.openjdk.java.net/~jbachorik/8042096/webrev.00 Thanks, -JB- From staffan.larsen at oracle.com Tue Apr 29 12:33:25 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Apr 2014 14:33:25 +0200 Subject: RFR 8042096: Backout JDK-8042091 In-Reply-To: <535F903A.3070602@oracle.com> References: <535F903A.3070602@oracle.com> Message-ID: <26E14E65-7916-49C3-B87D-89FA164C17D8@oracle.com> Looks good. Very sorry I didn?t catch this during review. /Staffan On 29 apr 2014, at 13:42, Jaroslav Bachorik wrote: > Please, review this emergency backout. > > The changes introduced in fix for JDK-8042091 didn't contain SA-JDI implementation in hotspot causing JDK build breakage. The JDK part needs to be backed out till the hotspot side is ready to accept the changed APIs. > > The change is generated by 'hg backout -r 4e7f3aac979b' on jdk9/jdk repo. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8042096 > Webrev: http://cr.openjdk.java.net/~jbachorik/8042096/webrev.00 > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Apr 29 12:38:56 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 14:38:56 +0200 Subject: RFR 8042096: Backout JDK-8042091 In-Reply-To: <26E14E65-7916-49C3-B87D-89FA164C17D8@oracle.com> References: <535F903A.3070602@oracle.com> <26E14E65-7916-49C3-B87D-89FA164C17D8@oracle.com> Message-ID: <535F9D60.3090901@oracle.com> Backed out - #276c2688450d Thanks for the patience! -JB- On 29.4.2014 14:33, Staffan Larsen wrote: > Looks good. > > Very sorry I didn?t catch this during review. > > /Staffan > > On 29 apr 2014, at 13:42, Jaroslav Bachorik wrote: > >> Please, review this emergency backout. >> >> The changes introduced in fix for JDK-8042091 didn't contain SA-JDI implementation in hotspot causing JDK build breakage. The JDK part needs to be backed out till the hotspot side is ready to accept the changed APIs. >> >> The change is generated by 'hg backout -r 4e7f3aac979b' on jdk9/jdk repo. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8042096 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8042096/webrev.00 >> >> Thanks, >> >> -JB- > From Alan.Bateman at oracle.com Tue Apr 29 13:22:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Apr 2014 14:22:04 +0100 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> Message-ID: <535FA77C.6050303@oracle.com> On 16/04/2014 10:21, Staffan Larsen wrote: > On 14 apr 2014, at 17:17, Alan Bateman wrote: > >> : >> For someone looking at the Virtualmachine API then I don't think the javadoc is clear enough to understand when one might get the specific AttachOperationFailedException vs. the more general IOException. I think it means that there was communication with the target VM but that the operation failed for some reason but I don't think this will be obvious to the reader. > I have tried to clarify the wording in the javadoc. Suggestions for improvements are welcome. Sorry for the delay, I was on away for a few days and just catching up with this again. The updated descriptions looks much better. For IOException then it might be better to have a bit of wriggle room to allow for other I/O errors that might not be communication related. So maybe something like "If an I/O error occurs, a communication error for example, that cannot be identified as an error to indicate that the operation failed in the target VM". > : >> For the new exception then it would be good to add @since and also a copyright header. > Fixed. > Thanks, a formatting nit at L42, I assume that the "{" will fit at the end of line 41. I don't have cycles at the moment to go through the implementation changes but I think you have other reviewers for that. -Alan. From staffan.larsen at oracle.com Tue Apr 29 14:08:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Apr 2014 16:08:50 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <535FA77C.6050303@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> <535FA77C.6050303@oracle.com> Message-ID: <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> Thanks for the comments. I have updated the review with both. webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.05/ I do not actually have any Reviewers for this change. Anyone willing to take it on is much appreciated. Thanks, /Staffan On 29 apr 2014, at 15:22, Alan Bateman wrote: > On 16/04/2014 10:21, Staffan Larsen wrote: >> On 14 apr 2014, at 17:17, Alan Bateman wrote: >> >>> : >>> For someone looking at the Virtualmachine API then I don't think the javadoc is clear enough to understand when one might get the specific AttachOperationFailedException vs. the more general IOException. I think it means that there was communication with the target VM but that the operation failed for some reason but I don't think this will be obvious to the reader. >> I have tried to clarify the wording in the javadoc. Suggestions for improvements are welcome. > Sorry for the delay, I was on away for a few days and just catching up with this again. > > The updated descriptions looks much better. For IOException then it might be better to have a bit of wriggle room to allow for other I/O errors that might not be communication related. So maybe something like "If an I/O error occurs, a communication error for example, that cannot be identified as an error to indicate that the operation failed in the target VM". > >> : >>> For the new exception then it would be good to add @since and also a copyright header. >> Fixed. >> > Thanks, a formatting nit at L42, I assume that the "{" will fit at the end of line 41. > > I don't have cycles at the moment to go through the implementation changes but I think you have other reviewers for that. > > -Alan. > > From jaroslav.bachorik at oracle.com Tue Apr 29 14:44:15 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Apr 2014 16:44:15 +0200 Subject: RFR 8042123: Support default and static interface methods in JDI, JDWP and JDB (was 8031195) Message-ID: <535FBABF.7040301@oracle.com> This is a take two on addressing this issue. The previous attempt caused build breakage when building SA-JDI because of non-implemented abstract methods. Because of "tainted" issue number I had to make a new clone. Issue : https://bugs.openjdk.java.net/browse/JDK-8042123 Webrev: http://cr.openjdk.java.net/~jbachorik/8042123/webrev.00 This is the same patch as was used for JDK-8031195 with the added "default" keyword to the newly introduced interface methods. The default implementations just throw UnsupportedOperationException. The build did break when doing "make bootcycle-images" - I've rerun the build locally and using JPRT and after adding "default" keyword the breakages does not appear any more. Sorry for the mess ... Thanks, -JB- From staffan.larsen at oracle.com Tue Apr 29 14:57:48 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Apr 2014 16:57:48 +0200 Subject: RFR 8042123: Support default and static interface methods in JDI, JDWP and JDB (was 8031195) In-Reply-To: <535FBABF.7040301@oracle.com> References: <535FBABF.7040301@oracle.com> Message-ID: Let?s try it again. Reviewed. /Staffan On 29 apr 2014, at 16:44, Jaroslav Bachorik wrote: > This is a take two on addressing this issue. > The previous attempt caused build breakage when building SA-JDI because of non-implemented abstract methods. > Because of "tainted" issue number I had to make a new clone. > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8042123 > Webrev: http://cr.openjdk.java.net/~jbachorik/8042123/webrev.00 > > This is the same patch as was used for JDK-8031195 with the added "default" keyword to the newly introduced interface methods. The default implementations just throw UnsupportedOperationException. > > The build did break when doing "make bootcycle-images" - I've rerun the build locally and using JPRT and after adding "default" keyword the breakages does not appear any more. > > Sorry for the mess ... > > > Thanks, > > -JB- From serguei.spitsyn at oracle.com Wed Apr 30 00:07:35 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 29 Apr 2014 17:07:35 -0700 Subject: RFR 8042096: Backout JDK-8042091 In-Reply-To: <26E14E65-7916-49C3-B87D-89FA164C17D8@oracle.com> References: <535F903A.3070602@oracle.com> <26E14E65-7916-49C3-B87D-89FA164C17D8@oracle.com> Message-ID: <53603EC7.1070906@oracle.com> Sorry, I did not catch this too. It is hard to catch, testing must be our friend here. Thanks, Serguei On 4/29/14 5:33 AM, Staffan Larsen wrote: > Looks good. > > Very sorry I didn?t catch this during review. > > /Staffan > > On 29 apr 2014, at 13:42, Jaroslav Bachorik wrote: > >> Please, review this emergency backout. >> >> The changes introduced in fix for JDK-8042091 didn't contain SA-JDI implementation in hotspot causing JDK build breakage. The JDK part needs to be backed out till the hotspot side is ready to accept the changed APIs. >> >> The change is generated by 'hg backout -r 4e7f3aac979b' on jdk9/jdk repo. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8042096 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8042096/webrev.00 >> >> Thanks, >> >> -JB- From serguei.spitsyn at oracle.com Wed Apr 30 00:09:13 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 29 Apr 2014 17:09:13 -0700 Subject: RFR 8042123: Support default and static interface methods in JDI, JDWP and JDB (was 8031195) In-Reply-To: <535FBABF.7040301@oracle.com> References: <535FBABF.7040301@oracle.com> Message-ID: <53603F29.2030903@oracle.com> It looks good again. Thanks, Serguei On 4/29/14 7:44 AM, Jaroslav Bachorik wrote: > This is a take two on addressing this issue. > The previous attempt caused build breakage when building SA-JDI > because of non-implemented abstract methods. > Because of "tainted" issue number I had to make a new clone. > > > Issue : https://bugs.openjdk.java.net/browse/JDK-8042123 > Webrev: http://cr.openjdk.java.net/~jbachorik/8042123/webrev.00 > > This is the same patch as was used for JDK-8031195 with the added > "default" keyword to the newly introduced interface methods. The > default implementations just throw UnsupportedOperationException. > > The build did break when doing "make bootcycle-images" - I've rerun > the build locally and using JPRT and after adding "default" keyword > the breakages does not appear any more. > > Sorry for the mess ... > > > Thanks, > > -JB-