From volker.simonis at gmail.com Wed Mar 1 13:23:01 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Mar 2017 14:23:01 +0100 Subject: Why doesn't jdk.hotspot.agent export anything? Message-ID: Hi, I understand that the SA API is an unofficial, unsupported API which is constantly evolving and changing. But at least its JavaDoc has been made available recently [1] (and I really welcome and appreciate that). Unfortunately, with Java 9 and the new module system it becomes very inconvenient to use the SA API for own tools because the jdk.hotspot.agent has no unqualified exports at all. So from my understanding, even for a relatively small SA application, I need a command line like: javac --add-modules jdk.hotspot.agent --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED MySAApp.java Running it isn't any simpler: java --add-modules jdk.hotspot.agent --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED MySAApp java core Is this intended or do you plan to simplify this by opening jdk.hotspot.agent by exporting its packages? Or maybe there's a simpler way of using the SA API in jdk9 which I've completely missed? Thank you and best regards, Volker [1] http://docs.oracle.com/javase/8/docs/serviceabilityagent/ From serguei.spitsyn at oracle.com Thu Mar 2 03:49:32 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 Mar 2017 19:49:32 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface Message-ID: Please, review the JDK 10 fix for: https://bugs.openjdk.java.net/browse/JDK-8134103 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ Summary: This is an intermittent issue in the debugger back-end (JDWP agent) that impacts the nightly testing stability. The fix adds check guards of gdata->vmDead condition to the: - debugLoop (JDWP Event Helper thread) and - commandLoop (JDWP Transport Listener thread) The commands are ignored in the DEAD phase. The check guard in the debugLoop already existed but only for VirtualMachine command set, so it has been extended to commands from all JDWP command sets. I suspect, this bug could also cause some of the timeout and socket related issues. Testing: The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. The test results are very clean. Thanks, Serguei From david.holmes at oracle.com Thu Mar 2 05:12:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Mar 2017 15:12:47 +1000 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: Message-ID: Hi Serguei, This looks very reasonable. Thanks, David On 2/03/2017 1:49 PM, serguei.spitsyn at oracle.com wrote: > Please, review the JDK 10 fix for: > https://bugs.openjdk.java.net/browse/JDK-8134103 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ > > > > Summary: > This is an intermittent issue in the debugger back-end (JDWP agent) > that impacts the nightly testing stability. > The fix adds check guards of gdata->vmDead condition to the: > - debugLoop (JDWP Event Helper thread) and > - commandLoop (JDWP Transport Listener thread) > The commands are ignored in the DEAD phase. > > The check guard in the debugLoop already existed but only for > VirtualMachine > command set, so it has been extended to commands from all JDWP command > sets. > > I suspect, this bug could also cause some of the timeout and socket > related issues. > > > Testing: > The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs > of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. > The test results are very clean. > > > Thanks, > Serguei From dmitry.samersoff at oracle.com Thu Mar 2 07:07:40 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 2 Mar 2017 10:07:40 +0300 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: Message-ID: <20337887-d99f-1d66-03b2-4390baf832ad@oracle.com> Serguei, Looks good to me! -Dmitry On 2017-03-02 06:49, serguei.spitsyn at oracle.com wrote: > Please, review the JDK 10 fix for: > https://bugs.openjdk.java.net/browse/JDK-8134103 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ > > > > Summary: > This is an intermittent issue in the debugger back-end (JDWP agent) > that impacts the nightly testing stability. > The fix adds check guards of gdata->vmDead condition to the: > - debugLoop (JDWP Event Helper thread) and > - commandLoop (JDWP Transport Listener thread) > The commands are ignored in the DEAD phase. > > The check guard in the debugLoop already existed but only for > VirtualMachine > command set, so it has been extended to commands from all JDWP command > sets. > > I suspect, this bug could also cause some of the timeout and socket > related issues. > > > Testing: > The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs > of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. > The test results are very clean. > > > Thanks, > Serguei -- 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 Thu Mar 2 07:18:19 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 Mar 2017 23:18:19 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: Message-ID: <70e37fb4-d075-5c74-9c04-adf85f647814@oracle.com> Thank you a lot, David! Serguei On 3/1/17 21:12, David Holmes wrote: > Hi Serguei, > > This looks very reasonable. > > Thanks, > David > > On 2/03/2017 1:49 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the JDK 10 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8134103 >> >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >> >> >> >> >> Summary: >> This is an intermittent issue in the debugger back-end (JDWP agent) >> that impacts the nightly testing stability. >> The fix adds check guards of gdata->vmDead condition to the: >> - debugLoop (JDWP Event Helper thread) and >> - commandLoop (JDWP Transport Listener thread) >> The commands are ignored in the DEAD phase. >> >> The check guard in the debugLoop already existed but only for >> VirtualMachine >> command set, so it has been extended to commands from all JDWP command >> sets. >> >> I suspect, this bug could also cause some of the timeout and socket >> related issues. >> >> >> Testing: >> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >> of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >> The test results are very clean. >> >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Thu Mar 2 07:18:51 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 Mar 2017 23:18:51 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <20337887-d99f-1d66-03b2-4390baf832ad@oracle.com> References: <20337887-d99f-1d66-03b2-4390baf832ad@oracle.com> Message-ID: <042dfa0a-5040-873c-895d-917183bc4473@oracle.com> Thank you a lot, Dmitry! Serguei On 3/1/17 23:07, Dmitry Samersoff wrote: > Serguei, > > Looks good to me! > > -Dmitry > > On 2017-03-02 06:49, serguei.spitsyn at oracle.com wrote: >> Please, review the JDK 10 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8134103 >> >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >> >> >> >> Summary: >> This is an intermittent issue in the debugger back-end (JDWP agent) >> that impacts the nightly testing stability. >> The fix adds check guards of gdata->vmDead condition to the: >> - debugLoop (JDWP Event Helper thread) and >> - commandLoop (JDWP Transport Listener thread) >> The commands are ignored in the DEAD phase. >> >> The check guard in the debugLoop already existed but only for >> VirtualMachine >> command set, so it has been extended to commands from all JDWP command >> sets. >> >> I suspect, this bug could also cause some of the timeout and socket >> related issues. >> >> >> Testing: >> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >> of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >> The test results are very clean. >> >> >> Thanks, >> Serguei > From Alan.Bateman at oracle.com Thu Mar 2 09:00:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Mar 2017 09:00:17 +0000 Subject: Why doesn't jdk.hotspot.agent export anything? In-Reply-To: References: Message-ID: On 01/03/2017 13:23, Volker Simonis wrote: > Hi, > > I understand that the SA API is an unofficial, unsupported API which > is constantly evolving and changing. But at least its JavaDoc has been > made available recently [1] (and I really welcome and appreciate > that). > > Unfortunately, with Java 9 and the new module system it becomes very > inconvenient to use the SA API for own tools because the > jdk.hotspot.agent has no unqualified exports at all. So from my > understanding, even for a relatively small SA application, I need a > command line like: > > javac --add-modules jdk.hotspot.agent > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED > MySAApp.java > > Running it isn't any simpler: > > java --add-modules jdk.hotspot.agent > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED > --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED > MySAApp java core > > Is this intended As you noted, SA isn't a supported API so this is why jdk.hotspot.agent doesn't export any packages unconditionally. I don't know what the javadoc was published via the link you posted, this seems to be a mistake. -Alan From volker.simonis at gmail.com Thu Mar 2 13:31:17 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Mar 2017 14:31:17 +0100 Subject: Why doesn't jdk.hotspot.agent export anything? In-Reply-To: References: Message-ID: On Thu, Mar 2, 2017 at 10:00 AM, Alan Bateman wrote: > On 01/03/2017 13:23, Volker Simonis wrote: > >> Hi, >> >> I understand that the SA API is an unofficial, unsupported API which >> is constantly evolving and changing. But at least its JavaDoc has been >> made available recently [1] (and I really welcome and appreciate >> that). >> >> Unfortunately, with Java 9 and the new module system it becomes very >> inconvenient to use the SA API for own tools because the >> jdk.hotspot.agent has no unqualified exports at all. So from my >> understanding, even for a relatively small SA application, I need a >> command line like: >> >> javac --add-modules jdk.hotspot.agent >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED >> MySAApp.java >> >> Running it isn't any simpler: >> >> java --add-modules jdk.hotspot.agent >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.classfile=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.oops=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.runtime=ALL-UNNAMED >> --add-exports jdk.hotspot.agent/sun.jvm.hotspot.tools=ALL-UNNAMED >> MySAApp java core >> >> Is this intended > > As you noted, SA isn't a supported API so this is why jdk.hotspot.agent > doesn't export any packages unconditionally. I don't know what the javadoc > was published via the link you posted, this seems to be a mistake. > I didn't had the impression that this was a mistake. At least it was advertised on " The Java Tuturials Blog" https://blogs.oracle.com/thejavatutorials/entry/hotspot_serviceability_agent_api_javadoc which seems to be a more or less 'offical' Oracle blog. I just think that not everything that's not supported necessarily has to be closed. The SA APIs are definitely quite useful, even if they are not supported in any way. Regards, Volker > -Alan From daniel.daugherty at oracle.com Thu Mar 2 14:59:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Mar 2017 07:59:16 -0700 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: Message-ID: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: > Please, review the JDK 10 fix for: > https://bugs.openjdk.java.net/browse/JDK-8134103 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ > src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c old L152: } else if (gdata->vmDead && old L153: ((cmd->cmdSet) != JDWP_COMMAND_SET(VirtualMachine))) { The old code used to set the error condition when the VM is dead and the command was not in the VirtualMachine command set. With the new code: L150: } else if (gdata->vmDead) { The error condition is now set for all command sets including the VirtualMachine command set. Minimally that means that this comment needs work: L152: * VirtualMachine cmdSet quietly ignores some cmds L153: * after VM death, so, it sends it's own errors. since you are no longer letting the VirtualMachine cmdSet send its own errors. It's not clear to me why you are now setting the error condition for VirtualMachine cmds instead of letting those cmds send their own errors. See more comments below for your summary. src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c L243: * Immediately close out any commands enqueued from a L244: * previously attached debugger. Perhaps L244 can be change to: * dead VM or a previously attached debugger. to match the changed line of code: L246 if (gdata->vmDead || command->sessionID != currentSessionID) { > > > Summary: > This is an intermittent issue in the debugger back-end (JDWP agent) > that impacts the nightly testing stability. Congrats on tracking down this elusive bug! > The fix adds check guards of gdata->vmDead condition to the: > - debugLoop (JDWP Event Helper thread) and > - commandLoop (JDWP Transport Listener thread) > The commands are ignored in the DEAD phase. In the debugLoop, you aren't ignoring the commands, you are setting an error condition. > The check guard in the debugLoop already existed but only for > VirtualMachine > command set, so it has been extended to commands from all JDWP > command sets. I'm reading the existing code exactly opposite of what you say here. The gdata->vmDead check applied to all command sets except for the VirtualMachine command set. I agree that you've extended it to all command sets, but we're not ignoring the commands. We are now setting the error condition for all command sets. Maybe I'm missing something here. Perhaps I've been away from this code for too long... :-) Dan > > I suspect, this bug could also cause some of the timeout and socket > related issues. > > > Testing: > The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs > of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. > The test results are very clean. > > > Thanks, > Serguei From Alan.Bateman at oracle.com Thu Mar 2 19:01:24 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Mar 2017 19:01:24 +0000 Subject: Why doesn't jdk.hotspot.agent export anything? In-Reply-To: References: Message-ID: <81a94169-21b9-858b-b911-f14013a2eb23@oracle.com> On 02/03/2017 13:31, Volker Simonis wrote: > : > I didn't had the impression that this was a mistake. At least it was > advertised on " The Java Tuturials Blog" > > https://blogs.oracle.com/thejavatutorials/entry/hotspot_serviceability_agent_api_javadoc > > which seems to be a more or less 'offical' Oracle blog. I have contacted the author to get this corrected. -Alan From serguei.spitsyn at oracle.com Thu Mar 2 19:21:04 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Mar 2017 11:21:04 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> Message-ID: <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> Dan, Thank you for reviewing! I was waiting for your comments. On 3/2/17 06:59, Daniel D. Daugherty wrote: > On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the JDK 10 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8134103 >> >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >> > > src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c > old L152: } else if (gdata->vmDead && > old L153: ((cmd->cmdSet) != > JDWP_COMMAND_SET(VirtualMachine))) { > > The old code used to set the error condition when the VM > is dead and the command was not in the VirtualMachine > command set. With the new code: > > L150: } else if (gdata->vmDead) { > > The error condition is now set for all command sets > including the VirtualMachine command set. Minimally > that means that this comment needs work: > > L152: * VirtualMachine cmdSet quietly > ignores some cmds > L153: * after VM death, so, it sends it's > own errors. > > since you are no longer letting the VirtualMachine cmdSet send > its own errors. Agreed, good catch, thanks! > > It's not clear to me why you are now setting the error > condition for VirtualMachine cmds instead of letting those > cmds send their own errors. > > See more comments below for your summary. Most likely, you are right here. I specifically looked at the VM commands but overlooked the ones that are silently ignored. For instance: Resume (9) or exit (10). So, I will need to restore the L152+L153. Please, let me re-test this update and then I'll send another webrev. Interesting that no test has caught this as there is a very tiny gap for such an intermittent issue to appear. > > src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c > L243: * Immediately close out any commands enqueued from a > L244: * previously attached debugger. > > Perhaps L244 can be change to: > > * dead VM or a previously attached debugger. > > to match the changed line of code: > > L246 if (gdata->vmDead || command->sessionID != > currentSessionID) { > >> >> >> Summary: >> This is an intermittent issue in the debugger back-end (JDWP agent) >> that impacts the nightly testing stability. > > Congrats on tracking down this elusive bug! Thanks! > > >> The fix adds check guards of gdata->vmDead condition to the: >> - debugLoop (JDWP Event Helper thread) and >> - commandLoop (JDWP Transport Listener thread) >> The commands are ignored in the DEAD phase. > > In the debugLoop, you aren't ignoring the commands, you > are setting an error condition. Right, I meant: ignored == not executed. :) > > >> The check guard in the debugLoop already existed but only for >> VirtualMachine >> command set, so it has been extended to commands from all JDWP >> command sets. > > I'm reading the existing code exactly opposite of what you > say here. The gdata->vmDead check applied to all command > sets except for the VirtualMachine command set. I agree > that you've extended it to all command sets, but we're > not ignoring the commands. We are now setting the error > condition for all command sets. Agreed. > > Maybe I'm missing something here. Perhaps I've been away > from this code for too long... :-) No, it is that I'm still learning this code with your help. :-) Thanks a lot! Serguei > > Dan > > >> >> I suspect, this bug could also cause some of the timeout and socket >> related issues. >> >> >> Testing: >> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >> of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >> The test results are very clean. >> >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Thu Mar 2 21:24:32 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Mar 2017 13:24:32 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> Message-ID: <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ The change at L152-L153 has been reverted. Just one sanity check is needed. Thanks, Serguei On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: > Dan, > > Thank you for reviewing! > I was waiting for your comments. > > > On 3/2/17 06:59, Daniel D. Daugherty wrote: >> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the JDK 10 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>> >> >> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >> old L152: } else if (gdata->vmDead && >> old L153: ((cmd->cmdSet) != >> JDWP_COMMAND_SET(VirtualMachine))) { >> >> The old code used to set the error condition when the VM >> is dead and the command was not in the VirtualMachine >> command set. With the new code: >> >> L150: } else if (gdata->vmDead) { >> >> The error condition is now set for all command sets >> including the VirtualMachine command set. Minimally >> that means that this comment needs work: >> >> L152: * VirtualMachine cmdSet quietly >> ignores some cmds >> L153: * after VM death, so, it sends >> it's own errors. >> >> since you are no longer letting the VirtualMachine cmdSet send >> its own errors. > > Agreed, good catch, thanks! > > >> >> It's not clear to me why you are now setting the error >> condition for VirtualMachine cmds instead of letting those >> cmds send their own errors. >> >> See more comments below for your summary. > > Most likely, you are right here. > I specifically looked at the VM commands but overlooked the ones that > are silently ignored. > For instance: Resume (9) or exit (10). > > So, I will need to restore the L152+L153. > Please, let me re-test this update and then I'll send another webrev. > Interesting that no test has caught this as there is a very tiny gap > for such an intermittent issue to appear. > > >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >> L243: * Immediately close out any commands enqueued from a >> L244: * previously attached debugger. >> >> Perhaps L244 can be change to: >> >> * dead VM or a previously attached debugger. >> >> to match the changed line of code: >> >> L246 if (gdata->vmDead || command->sessionID != >> currentSessionID) { >> >>> >>> >>> Summary: >>> This is an intermittent issue in the debugger back-end (JDWP agent) >>> that impacts the nightly testing stability. >> >> Congrats on tracking down this elusive bug! > > Thanks! > >> >> >>> The fix adds check guards of gdata->vmDead condition to the: >>> - debugLoop (JDWP Event Helper thread) and >>> - commandLoop (JDWP Transport Listener thread) >>> The commands are ignored in the DEAD phase. >> >> In the debugLoop, you aren't ignoring the commands, you >> are setting an error condition. > > Right, I meant: ignored == not executed. :) > > >> >> >>> The check guard in the debugLoop already existed but only for >>> VirtualMachine >>> command set, so it has been extended to commands from all JDWP >>> command sets. >> >> I'm reading the existing code exactly opposite of what you >> say here. The gdata->vmDead check applied to all command >> sets except for the VirtualMachine command set. I agree >> that you've extended it to all command sets, but we're >> not ignoring the commands. We are now setting the error >> condition for all command sets. > > Agreed. > > >> >> Maybe I'm missing something here. Perhaps I've been away >> from this code for too long... :-) > > No, it is that I'm still learning this code with your help. :-) > > > Thanks a lot! > Serguei > >> >> Dan >> >> >>> >>> I suspect, this bug could also cause some of the timeout and >>> socket related issues. >>> >>> >>> Testing: >>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >>> of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>> The test results are very clean. >>> >>> >>> Thanks, >>> Serguei >> > From daniel.daugherty at oracle.com Thu Mar 2 22:06:49 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Mar 2017 15:06:49 -0700 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> Message-ID: <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ > > > The change at L152-L153 has been reverted. > Just one sanity check is needed. This comment from earlier review is still unresolved: src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c L243: * Immediately close out any commands enqueued from a L244: * previously attached debugger. Perhaps L244 can be change to: * dead VM or a previously attached debugger. to match the changed line of code: L246 if (gdata->vmDead || command->sessionID != currentSessionID) { Sorry I didn't notice that you didn't reply to it earlier... I presume you are retesting... How often does hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java reproduce the problem? Dan > > Thanks, > Serguei > > > On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you for reviewing! >> I was waiting for your comments. >> >> >> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the JDK 10 fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>> >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>> old L152: } else if (gdata->vmDead && >>> old L153: ((cmd->cmdSet) != >>> JDWP_COMMAND_SET(VirtualMachine))) { >>> >>> The old code used to set the error condition when the VM >>> is dead and the command was not in the VirtualMachine >>> command set. With the new code: >>> >>> L150: } else if (gdata->vmDead) { >>> >>> The error condition is now set for all command sets >>> including the VirtualMachine command set. Minimally >>> that means that this comment needs work: >>> >>> L152: * VirtualMachine cmdSet quietly >>> ignores some cmds >>> L153: * after VM death, so, it sends >>> it's own errors. >>> >>> since you are no longer letting the VirtualMachine cmdSet send >>> its own errors. >> >> Agreed, good catch, thanks! >> >> >>> >>> It's not clear to me why you are now setting the error >>> condition for VirtualMachine cmds instead of letting those >>> cmds send their own errors. >>> >>> See more comments below for your summary. >> >> Most likely, you are right here. >> I specifically looked at the VM commands but overlooked the ones that >> are silently ignored. >> For instance: Resume (9) or exit (10). >> >> So, I will need to restore the L152+L153. >> Please, let me re-test this update and then I'll send another webrev. >> Interesting that no test has caught this as there is a very tiny gap >> for such an intermittent issue to appear. >> >> >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>> L243: * Immediately close out any commands enqueued from a >>> L244: * previously attached debugger. >>> >>> Perhaps L244 can be change to: >>> >>> * dead VM or a previously attached debugger. >>> >>> to match the changed line of code: >>> >>> L246 if (gdata->vmDead || command->sessionID != >>> currentSessionID) { >>> >>>> >>>> >>>> Summary: >>>> This is an intermittent issue in the debugger back-end (JDWP agent) >>>> that impacts the nightly testing stability. >>> >>> Congrats on tracking down this elusive bug! >> >> Thanks! >> >>> >>> >>>> The fix adds check guards of gdata->vmDead condition to the: >>>> - debugLoop (JDWP Event Helper thread) and >>>> - commandLoop (JDWP Transport Listener thread) >>>> The commands are ignored in the DEAD phase. >>> >>> In the debugLoop, you aren't ignoring the commands, you >>> are setting an error condition. >> >> Right, I meant: ignored == not executed. :) >> >> >>> >>> >>>> The check guard in the debugLoop already existed but only for >>>> VirtualMachine >>>> command set, so it has been extended to commands from all JDWP >>>> command sets. >>> >>> I'm reading the existing code exactly opposite of what you >>> say here. The gdata->vmDead check applied to all command >>> sets except for the VirtualMachine command set. I agree >>> that you've extended it to all command sets, but we're >>> not ignoring the commands. We are now setting the error >>> condition for all command sets. >> >> Agreed. >> >> >>> >>> Maybe I'm missing something here. Perhaps I've been away >>> from this code for too long... :-) >> >> No, it is that I'm still learning this code with your help. :-) >> >> >> Thanks a lot! >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> I suspect, this bug could also cause some of the timeout and >>>> socket related issues. >>>> >>>> >>>> Testing: >>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >>>> of the hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>> The test results are very clean. >>>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From serguei.spitsyn at oracle.com Thu Mar 2 22:19:50 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Mar 2017 14:19:50 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> Message-ID: On 3/2/17 14:06, Daniel D. Daugherty wrote: > On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ >> >> >> The change at L152-L153 has been reverted. >> Just one sanity check is needed. > > This comment from earlier review is still unresolved: > > src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c > L243: * Immediately close out any commands enqueued from a > L244: * previously attached debugger. > > Perhaps L244 can be change to: > > * dead VM or a previously attached debugger. > > to match the changed line of code: > > L246 if (gdata->vmDead || command->sessionID != > currentSessionID) { > > Sorry I didn't notice that you didn't reply to it earlier... Sorry, I missed it - fixed now. I guess, it can be pushed now. > > I presume you are retesting... How often does > hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java reproduce > the problem? The repro-rate is pretty high it is about 1/3 - 1/2. It is non-reproducible with the fix. The test is pretty slow. At this point I've got about 200 clean runs. All the jdi/jdwp tests are clean too. Thanks! Serguei > > Dan > >> >> Thanks, >> Serguei >> >> >> On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> Thank you for reviewing! >>> I was waiting for your comments. >>> >>> >>> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the JDK 10 fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>>> >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>>> old L152: } else if (gdata->vmDead && >>>> old L153: ((cmd->cmdSet) != >>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>> >>>> The old code used to set the error condition when the VM >>>> is dead and the command was not in the VirtualMachine >>>> command set. With the new code: >>>> >>>> L150: } else if (gdata->vmDead) { >>>> >>>> The error condition is now set for all command sets >>>> including the VirtualMachine command set. Minimally >>>> that means that this comment needs work: >>>> >>>> L152: * VirtualMachine cmdSet quietly >>>> ignores some cmds >>>> L153: * after VM death, so, it sends >>>> it's own errors. >>>> >>>> since you are no longer letting the VirtualMachine cmdSet send >>>> its own errors. >>> >>> Agreed, good catch, thanks! >>> >>> >>>> >>>> It's not clear to me why you are now setting the error >>>> condition for VirtualMachine cmds instead of letting those >>>> cmds send their own errors. >>>> >>>> See more comments below for your summary. >>> >>> Most likely, you are right here. >>> I specifically looked at the VM commands but overlooked the ones >>> that are silently ignored. >>> For instance: Resume (9) or exit (10). >>> >>> So, I will need to restore the L152+L153. >>> Please, let me re-test this update and then I'll send another webrev. >>> Interesting that no test has caught this as there is a very tiny gap >>> for such an intermittent issue to appear. >>> >>> >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>> L243: * Immediately close out any commands enqueued >>>> from a >>>> L244: * previously attached debugger. >>>> >>>> Perhaps L244 can be change to: >>>> >>>> * dead VM or a previously attached debugger. >>>> >>>> to match the changed line of code: >>>> >>>> L246 if (gdata->vmDead || command->sessionID != >>>> currentSessionID) { >>>> >>>>> >>>>> >>>>> Summary: >>>>> This is an intermittent issue in the debugger back-end (JDWP agent) >>>>> that impacts the nightly testing stability. >>>> >>>> Congrats on tracking down this elusive bug! >>> >>> Thanks! >>> >>>> >>>> >>>>> The fix adds check guards of gdata->vmDead condition to the: >>>>> - debugLoop (JDWP Event Helper thread) and >>>>> - commandLoop (JDWP Transport Listener thread) >>>>> The commands are ignored in the DEAD phase. >>>> >>>> In the debugLoop, you aren't ignoring the commands, you >>>> are setting an error condition. >>> >>> Right, I meant: ignored == not executed. :) >>> >>> >>>> >>>> >>>>> The check guard in the debugLoop already existed but only for >>>>> VirtualMachine >>>>> command set, so it has been extended to commands from all JDWP >>>>> command sets. >>>> >>>> I'm reading the existing code exactly opposite of what you >>>> say here. The gdata->vmDead check applied to all command >>>> sets except for the VirtualMachine command set. I agree >>>> that you've extended it to all command sets, but we're >>>> not ignoring the commands. We are now setting the error >>>> condition for all command sets. >>> >>> Agreed. >>> >>> >>>> >>>> Maybe I'm missing something here. Perhaps I've been away >>>> from this code for too long... :-) >>> >>> No, it is that I'm still learning this code with your help. :-) >>> >>> >>> Thanks a lot! >>> Serguei >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> I suspect, this bug could also cause some of the timeout and >>>>> socket related issues. >>>>> >>>>> >>>>> Testing: >>>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 runs >>>>> of the >>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>>> The test results are very clean. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From daniel.daugherty at oracle.com Thu Mar 2 22:55:29 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Mar 2017 15:55:29 -0700 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> Message-ID: On 3/2/17 3:19 PM, serguei.spitsyn at oracle.com wrote: > On 3/2/17 14:06, Daniel D. Daugherty wrote: >> On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ >>> >>> >>> The change at L152-L153 has been reverted. >>> Just one sanity check is needed. >> >> This comment from earlier review is still unresolved: >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >> L243: * Immediately close out any commands enqueued from a >> L244: * previously attached debugger. >> >> Perhaps L244 can be change to: >> >> * dead VM or a previously attached debugger. >> >> to match the changed line of code: >> >> L246 if (gdata->vmDead || command->sessionID != >> currentSessionID) { >> >> Sorry I didn't notice that you didn't reply to it earlier... > > Sorry, I missed it - fixed now. > I guess, it can be pushed now. > > >> >> I presume you are retesting... How often does >> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java reproduce >> the problem? > > The repro-rate is pretty high it is about 1/3 - 1/2. > It is non-reproducible with the fix. So just to be clear, with just these code changes in place: - grab the vmDeathLock for all JDWP command sets instead of just the VirtualMachine command set in the debugLoop thread - ignore/close out cmds when gdata->vmDead is true in addition to the existing old session check in the CommandLoop thread the HeapwalkingTest goes from failing 1/3 -> 1/2 the time to not failing in 200 runs so far... I'd say you nailed this one nicely! Dan > The test is pretty slow. > At this point I've got about 200 clean runs. > All the jdi/jdwp tests are clean too. > > Thanks! > Serguei > >> >> Dan >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >>>> Dan, >>>> >>>> Thank you for reviewing! >>>> I was waiting for your comments. >>>> >>>> >>>> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>>>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the JDK 10 fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>>>> >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>>>> old L152: } else if (gdata->vmDead && >>>>> old L153: ((cmd->cmdSet) != >>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>> >>>>> The old code used to set the error condition when the VM >>>>> is dead and the command was not in the VirtualMachine >>>>> command set. With the new code: >>>>> >>>>> L150: } else if (gdata->vmDead) { >>>>> >>>>> The error condition is now set for all command sets >>>>> including the VirtualMachine command set. Minimally >>>>> that means that this comment needs work: >>>>> >>>>> L152: * VirtualMachine cmdSet quietly >>>>> ignores some cmds >>>>> L153: * after VM death, so, it sends >>>>> it's own errors. >>>>> >>>>> since you are no longer letting the VirtualMachine cmdSet >>>>> send >>>>> its own errors. >>>> >>>> Agreed, good catch, thanks! >>>> >>>> >>>>> >>>>> It's not clear to me why you are now setting the error >>>>> condition for VirtualMachine cmds instead of letting those >>>>> cmds send their own errors. >>>>> >>>>> See more comments below for your summary. >>>> >>>> Most likely, you are right here. >>>> I specifically looked at the VM commands but overlooked the ones >>>> that are silently ignored. >>>> For instance: Resume (9) or exit (10). >>>> >>>> So, I will need to restore the L152+L153. >>>> Please, let me re-test this update and then I'll send another webrev. >>>> Interesting that no test has caught this as there is a very tiny >>>> gap for such an intermittent issue to appear. >>>> >>>> >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>> L243: * Immediately close out any commands enqueued >>>>> from a >>>>> L244: * previously attached debugger. >>>>> >>>>> Perhaps L244 can be change to: >>>>> >>>>> * dead VM or a previously attached debugger. >>>>> >>>>> to match the changed line of code: >>>>> >>>>> L246 if (gdata->vmDead || command->sessionID >>>>> != currentSessionID) { >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> This is an intermittent issue in the debugger back-end (JDWP >>>>>> agent) >>>>>> that impacts the nightly testing stability. >>>>> >>>>> Congrats on tracking down this elusive bug! >>>> >>>> Thanks! >>>> >>>>> >>>>> >>>>>> The fix adds check guards of gdata->vmDead condition to the: >>>>>> - debugLoop (JDWP Event Helper thread) and >>>>>> - commandLoop (JDWP Transport Listener thread) >>>>>> The commands are ignored in the DEAD phase. >>>>> >>>>> In the debugLoop, you aren't ignoring the commands, you >>>>> are setting an error condition. >>>> >>>> Right, I meant: ignored == not executed. :) >>>> >>>> >>>>> >>>>> >>>>>> The check guard in the debugLoop already existed but only for >>>>>> VirtualMachine >>>>>> command set, so it has been extended to commands from all JDWP >>>>>> command sets. >>>>> >>>>> I'm reading the existing code exactly opposite of what you >>>>> say here. The gdata->vmDead check applied to all command >>>>> sets except for the VirtualMachine command set. I agree >>>>> that you've extended it to all command sets, but we're >>>>> not ignoring the commands. We are now setting the error >>>>> condition for all command sets. >>>> >>>> Agreed. >>>> >>>> >>>>> >>>>> Maybe I'm missing something here. Perhaps I've been away >>>>> from this code for too long... :-) >>>> >>>> No, it is that I'm still learning this code with your help. :-) >>>> >>>> >>>> Thanks a lot! >>>> Serguei >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> I suspect, this bug could also cause some of the timeout and >>>>>> socket related issues. >>>>>> >>>>>> >>>>>> Testing: >>>>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 >>>>>> runs >>>>>> of the >>>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>>>> The test results are very clean. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Mar 2 23:07:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Mar 2017 15:07:56 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> Message-ID: On 3/2/17 14:55, Daniel D. Daugherty wrote: > On 3/2/17 3:19 PM, serguei.spitsyn at oracle.com wrote: >> On 3/2/17 14:06, Daniel D. Daugherty wrote: >>> On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ >>>> >>>> >>>> The change at L152-L153 has been reverted. >>>> Just one sanity check is needed. >>> >>> This comment from earlier review is still unresolved: >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>> L243: * Immediately close out any commands enqueued from a >>> L244: * previously attached debugger. >>> >>> Perhaps L244 can be change to: >>> >>> * dead VM or a previously attached debugger. >>> >>> to match the changed line of code: >>> >>> L246 if (gdata->vmDead || command->sessionID != >>> currentSessionID) { >>> >>> Sorry I didn't notice that you didn't reply to it earlier... >> >> Sorry, I missed it - fixed now. >> I guess, it can be pushed now. >> >> >>> >>> I presume you are retesting... How often does >>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java reproduce >>> the problem? >> >> The repro-rate is pretty high it is about 1/3 - 1/2. >> It is non-reproducible with the fix. > > So just to be clear, with just these code changes in place: > > - grab the vmDeathLock for all JDWP command sets instead of just > the VirtualMachine command set in the debugLoop thread > - ignore/close out cmds when gdata->vmDead is true in addition > to the existing old session check in the CommandLoop thread Exactly. > > the HeapwalkingTest goes from failing 1/3 -> 1/2 the time to > not failing in 200 runs so far... > > I'd say you nailed this one nicely! Thanks. The fix should cover all the symptoms described in the bug dups. At least, I tried to analyze and cover all theoretically possible cases. :) My initial fix had more guards. But then I proved to myself some of the guards are not necessary. Thanks, Serguei > > Dan > > >> The test is pretty slow. >> At this point I've got about 200 clean runs. >> All the jdi/jdwp tests are clean too. >> >> Thanks! >> Serguei >> >>> >>> Dan >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >>>>> Dan, >>>>> >>>>> Thank you for reviewing! >>>>> I was waiting for your comments. >>>>> >>>>> >>>>> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>>>>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the JDK 10 fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>>>>> >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>>>>> >>>>>> >>>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>>>>> old L152: } else if (gdata->vmDead && >>>>>> old L153: ((cmd->cmdSet) != >>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>> >>>>>> The old code used to set the error condition when the VM >>>>>> is dead and the command was not in the VirtualMachine >>>>>> command set. With the new code: >>>>>> >>>>>> L150: } else if (gdata->vmDead) { >>>>>> >>>>>> The error condition is now set for all command sets >>>>>> including the VirtualMachine command set. Minimally >>>>>> that means that this comment needs work: >>>>>> >>>>>> L152: * VirtualMachine cmdSet >>>>>> quietly ignores some cmds >>>>>> L153: * after VM death, so, it sends >>>>>> it's own errors. >>>>>> >>>>>> since you are no longer letting the VirtualMachine cmdSet >>>>>> send >>>>>> its own errors. >>>>> >>>>> Agreed, good catch, thanks! >>>>> >>>>> >>>>>> >>>>>> It's not clear to me why you are now setting the error >>>>>> condition for VirtualMachine cmds instead of letting those >>>>>> cmds send their own errors. >>>>>> >>>>>> See more comments below for your summary. >>>>> >>>>> Most likely, you are right here. >>>>> I specifically looked at the VM commands but overlooked the ones >>>>> that are silently ignored. >>>>> For instance: Resume (9) or exit (10). >>>>> >>>>> So, I will need to restore the L152+L153. >>>>> Please, let me re-test this update and then I'll send another webrev. >>>>> Interesting that no test has caught this as there is a very tiny >>>>> gap for such an intermittent issue to appear. >>>>> >>>>> >>>>>> >>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>> L243: * Immediately close out any commands enqueued >>>>>> from a >>>>>> L244: * previously attached debugger. >>>>>> >>>>>> Perhaps L244 can be change to: >>>>>> >>>>>> * dead VM or a previously attached debugger. >>>>>> >>>>>> to match the changed line of code: >>>>>> >>>>>> L246 if (gdata->vmDead || command->sessionID >>>>>> != currentSessionID) { >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> This is an intermittent issue in the debugger back-end (JDWP >>>>>>> agent) >>>>>>> that impacts the nightly testing stability. >>>>>> >>>>>> Congrats on tracking down this elusive bug! >>>>> >>>>> Thanks! >>>>> >>>>>> >>>>>> >>>>>>> The fix adds check guards of gdata->vmDead condition to the: >>>>>>> - debugLoop (JDWP Event Helper thread) and >>>>>>> - commandLoop (JDWP Transport Listener thread) >>>>>>> The commands are ignored in the DEAD phase. >>>>>> >>>>>> In the debugLoop, you aren't ignoring the commands, you >>>>>> are setting an error condition. >>>>> >>>>> Right, I meant: ignored == not executed. :) >>>>> >>>>> >>>>>> >>>>>> >>>>>>> The check guard in the debugLoop already existed but only for >>>>>>> VirtualMachine >>>>>>> command set, so it has been extended to commands from all JDWP >>>>>>> command sets. >>>>>> >>>>>> I'm reading the existing code exactly opposite of what you >>>>>> say here. The gdata->vmDead check applied to all command >>>>>> sets except for the VirtualMachine command set. I agree >>>>>> that you've extended it to all command sets, but we're >>>>>> not ignoring the commands. We are now setting the error >>>>>> condition for all command sets. >>>>> >>>>> Agreed. >>>>> >>>>> >>>>>> >>>>>> Maybe I'm missing something here. Perhaps I've been away >>>>>> from this code for too long... :-) >>>>> >>>>> No, it is that I'm still learning this code with your help. :-) >>>>> >>>>> >>>>> Thanks a lot! >>>>> Serguei >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> I suspect, this bug could also cause some of the timeout and >>>>>>> socket related issues. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 >>>>>>> runs >>>>>>> of the >>>>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>>>>> The test results are very clean. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Mar 2 23:46:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Mar 2017 09:46:26 +1000 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> Message-ID: +1 from me. David On 3/03/2017 9:07 AM, serguei.spitsyn at oracle.com wrote: > On 3/2/17 14:55, Daniel D. Daugherty wrote: >> On 3/2/17 3:19 PM, serguei.spitsyn at oracle.com wrote: >>> On 3/2/17 14:06, Daniel D. Daugherty wrote: >>>> On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ >>>>> >>>>> >>>>> The change at L152-L153 has been reverted. >>>>> Just one sanity check is needed. >>>> >>>> This comment from earlier review is still unresolved: >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>> L243: * Immediately close out any commands enqueued from a >>>> L244: * previously attached debugger. >>>> >>>> Perhaps L244 can be change to: >>>> >>>> * dead VM or a previously attached debugger. >>>> >>>> to match the changed line of code: >>>> >>>> L246 if (gdata->vmDead || command->sessionID != >>>> currentSessionID) { >>>> >>>> Sorry I didn't notice that you didn't reply to it earlier... >>> >>> Sorry, I missed it - fixed now. >>> I guess, it can be pushed now. >>> >>> >>>> >>>> I presume you are retesting... How often does >>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java reproduce >>>> the problem? >>> >>> The repro-rate is pretty high it is about 1/3 - 1/2. >>> It is non-reproducible with the fix. >> >> So just to be clear, with just these code changes in place: >> >> - grab the vmDeathLock for all JDWP command sets instead of just >> the VirtualMachine command set in the debugLoop thread >> - ignore/close out cmds when gdata->vmDead is true in addition >> to the existing old session check in the CommandLoop thread > > Exactly. > > >> >> the HeapwalkingTest goes from failing 1/3 -> 1/2 the time to >> not failing in 200 runs so far... >> >> I'd say you nailed this one nicely! > > Thanks. > The fix should cover all the symptoms described in the bug dups. > At least, I tried to analyze and cover all theoretically possible cases. :) > My initial fix had more guards. > But then I proved to myself some of the guards are not necessary. > > > Thanks, > Serguei > > >> >> Dan >> >> >>> The test is pretty slow. >>> At this point I've got about 200 clean runs. >>> All the jdi/jdwp tests are clean too. >>> >>> Thanks! >>> Serguei >>> >>>> >>>> Dan >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >>>>>> Dan, >>>>>> >>>>>> Thank you for reviewing! >>>>>> I was waiting for your comments. >>>>>> >>>>>> >>>>>> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>>>>>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the JDK 10 fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>>>>>> >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>>>>>> >>>>>>> >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>>>>>> old L152: } else if (gdata->vmDead && >>>>>>> old L153: ((cmd->cmdSet) != >>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>> >>>>>>> The old code used to set the error condition when the VM >>>>>>> is dead and the command was not in the VirtualMachine >>>>>>> command set. With the new code: >>>>>>> >>>>>>> L150: } else if (gdata->vmDead) { >>>>>>> >>>>>>> The error condition is now set for all command sets >>>>>>> including the VirtualMachine command set. Minimally >>>>>>> that means that this comment needs work: >>>>>>> >>>>>>> L152: * VirtualMachine cmdSet >>>>>>> quietly ignores some cmds >>>>>>> L153: * after VM death, so, it sends >>>>>>> it's own errors. >>>>>>> >>>>>>> since you are no longer letting the VirtualMachine cmdSet >>>>>>> send >>>>>>> its own errors. >>>>>> >>>>>> Agreed, good catch, thanks! >>>>>> >>>>>> >>>>>>> >>>>>>> It's not clear to me why you are now setting the error >>>>>>> condition for VirtualMachine cmds instead of letting those >>>>>>> cmds send their own errors. >>>>>>> >>>>>>> See more comments below for your summary. >>>>>> >>>>>> Most likely, you are right here. >>>>>> I specifically looked at the VM commands but overlooked the ones >>>>>> that are silently ignored. >>>>>> For instance: Resume (9) or exit (10). >>>>>> >>>>>> So, I will need to restore the L152+L153. >>>>>> Please, let me re-test this update and then I'll send another webrev. >>>>>> Interesting that no test has caught this as there is a very tiny >>>>>> gap for such an intermittent issue to appear. >>>>>> >>>>>> >>>>>>> >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>>> L243: * Immediately close out any commands enqueued >>>>>>> from a >>>>>>> L244: * previously attached debugger. >>>>>>> >>>>>>> Perhaps L244 can be change to: >>>>>>> >>>>>>> * dead VM or a previously attached debugger. >>>>>>> >>>>>>> to match the changed line of code: >>>>>>> >>>>>>> L246 if (gdata->vmDead || command->sessionID >>>>>>> != currentSessionID) { >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> This is an intermittent issue in the debugger back-end (JDWP >>>>>>>> agent) >>>>>>>> that impacts the nightly testing stability. >>>>>>> >>>>>>> Congrats on tracking down this elusive bug! >>>>>> >>>>>> Thanks! >>>>>> >>>>>>> >>>>>>> >>>>>>>> The fix adds check guards of gdata->vmDead condition to the: >>>>>>>> - debugLoop (JDWP Event Helper thread) and >>>>>>>> - commandLoop (JDWP Transport Listener thread) >>>>>>>> The commands are ignored in the DEAD phase. >>>>>>> >>>>>>> In the debugLoop, you aren't ignoring the commands, you >>>>>>> are setting an error condition. >>>>>> >>>>>> Right, I meant: ignored == not executed. :) >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> The check guard in the debugLoop already existed but only for >>>>>>>> VirtualMachine >>>>>>>> command set, so it has been extended to commands from all JDWP >>>>>>>> command sets. >>>>>>> >>>>>>> I'm reading the existing code exactly opposite of what you >>>>>>> say here. The gdata->vmDead check applied to all command >>>>>>> sets except for the VirtualMachine command set. I agree >>>>>>> that you've extended it to all command sets, but we're >>>>>>> not ignoring the commands. We are now setting the error >>>>>>> condition for all command sets. >>>>>> >>>>>> Agreed. >>>>>> >>>>>> >>>>>>> >>>>>>> Maybe I'm missing something here. Perhaps I've been away >>>>>>> from this code for too long... :-) >>>>>> >>>>>> No, it is that I'm still learning this code with your help. :-) >>>>>> >>>>>> >>>>>> Thanks a lot! >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I suspect, this bug could also cause some of the timeout and >>>>>>>> socket related issues. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 >>>>>>>> runs >>>>>>>> of the >>>>>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>>>>>> The test results are very clean. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Mar 2 23:49:53 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Mar 2017 15:49:53 -0800 Subject: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <7e1661b6-3f0e-95bf-6c53-22b5fab968e9@oracle.com> <71e326e2-64ad-dcf2-3435-4a0684b9c375@oracle.com> <363e1ea0-b3f8-2ffa-f141-6b1e1148cd29@oracle.com> <888853cc-47ec-ae67-da67-301bbbf315d6@oracle.com> Message-ID: <498361c8-c0f5-47e3-396c-499ccc3d354c@oracle.com> Thanks, David! Serguei On 3/2/17 15:46, David Holmes wrote: > +1 from me. > > David > > On 3/03/2017 9:07 AM, serguei.spitsyn at oracle.com wrote: >> On 3/2/17 14:55, Daniel D. Daugherty wrote: >>> On 3/2/17 3:19 PM, serguei.spitsyn at oracle.com wrote: >>>> On 3/2/17 14:06, Daniel D. Daugherty wrote: >>>>> On 3/2/17 2:24 PM, serguei.spitsyn at oracle.com wrote: >>>>>> The updated webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ >>>>>> >>>>>> >>>>>> >>>>>> The change at L152-L153 has been reverted. >>>>>> Just one sanity check is needed. >>>>> >>>>> This comment from earlier review is still unresolved: >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>> L243: * Immediately close out any commands enqueued >>>>> from a >>>>> L244: * previously attached debugger. >>>>> >>>>> Perhaps L244 can be change to: >>>>> >>>>> * dead VM or a previously attached debugger. >>>>> >>>>> to match the changed line of code: >>>>> >>>>> L246 if (gdata->vmDead || command->sessionID != >>>>> currentSessionID) { >>>>> >>>>> Sorry I didn't notice that you didn't reply to it earlier... >>>> >>>> Sorry, I missed it - fixed now. >>>> I guess, it can be pushed now. >>>> >>>> >>>>> >>>>> I presume you are retesting... How often does >>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java >>>>> reproduce >>>>> the problem? >>>> >>>> The repro-rate is pretty high it is about 1/3 - 1/2. >>>> It is non-reproducible with the fix. >>> >>> So just to be clear, with just these code changes in place: >>> >>> - grab the vmDeathLock for all JDWP command sets instead of just >>> the VirtualMachine command set in the debugLoop thread >>> - ignore/close out cmds when gdata->vmDead is true in addition >>> to the existing old session check in the CommandLoop thread >> >> Exactly. >> >> >>> >>> the HeapwalkingTest goes from failing 1/3 -> 1/2 the time to >>> not failing in 200 runs so far... >>> >>> I'd say you nailed this one nicely! >> >> Thanks. >> The fix should cover all the symptoms described in the bug dups. >> At least, I tried to analyze and cover all theoretically possible >> cases. :) >> My initial fix had more guards. >> But then I proved to myself some of the guards are not necessary. >> >> >> Thanks, >> Serguei >> >> >>> >>> Dan >>> >>> >>>> The test is pretty slow. >>>> At this point I've got about 200 clean runs. >>>> All the jdi/jdwp tests are clean too. >>>> >>>> Thanks! >>>> Serguei >>>> >>>>> >>>>> Dan >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 3/2/17 11:21, serguei.spitsyn at oracle.com wrote: >>>>>>> Dan, >>>>>>> >>>>>>> Thank you for reviewing! >>>>>>> I was waiting for your comments. >>>>>>> >>>>>>> >>>>>>> On 3/2/17 06:59, Daniel D. Daugherty wrote: >>>>>>>> On 3/1/17 8:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the JDK 10 fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103 >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c >>>>>>>> old L152: } else if (gdata->vmDead && >>>>>>>> old L153: ((cmd->cmdSet) != >>>>>>>> JDWP_COMMAND_SET(VirtualMachine))) { >>>>>>>> >>>>>>>> The old code used to set the error condition when the VM >>>>>>>> is dead and the command was not in the VirtualMachine >>>>>>>> command set. With the new code: >>>>>>>> >>>>>>>> L150: } else if (gdata->vmDead) { >>>>>>>> >>>>>>>> The error condition is now set for all command sets >>>>>>>> including the VirtualMachine command set. Minimally >>>>>>>> that means that this comment needs work: >>>>>>>> >>>>>>>> L152: * VirtualMachine cmdSet >>>>>>>> quietly ignores some cmds >>>>>>>> L153: * after VM death, so, it sends >>>>>>>> it's own errors. >>>>>>>> >>>>>>>> since you are no longer letting the VirtualMachine cmdSet >>>>>>>> send >>>>>>>> its own errors. >>>>>>> >>>>>>> Agreed, good catch, thanks! >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> It's not clear to me why you are now setting the error >>>>>>>> condition for VirtualMachine cmds instead of letting those >>>>>>>> cmds send their own errors. >>>>>>>> >>>>>>>> See more comments below for your summary. >>>>>>> >>>>>>> Most likely, you are right here. >>>>>>> I specifically looked at the VM commands but overlooked the ones >>>>>>> that are silently ignored. >>>>>>> For instance: Resume (9) or exit (10). >>>>>>> >>>>>>> So, I will need to restore the L152+L153. >>>>>>> Please, let me re-test this update and then I'll send another >>>>>>> webrev. >>>>>>> Interesting that no test has caught this as there is a very tiny >>>>>>> gap for such an intermittent issue to appear. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>>>> L243: * Immediately close out any commands enqueued >>>>>>>> from a >>>>>>>> L244: * previously attached debugger. >>>>>>>> >>>>>>>> Perhaps L244 can be change to: >>>>>>>> >>>>>>>> * dead VM or a previously attached debugger. >>>>>>>> >>>>>>>> to match the changed line of code: >>>>>>>> >>>>>>>> L246 if (gdata->vmDead || command->sessionID >>>>>>>> != currentSessionID) { >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> This is an intermittent issue in the debugger back-end (JDWP >>>>>>>>> agent) >>>>>>>>> that impacts the nightly testing stability. >>>>>>>> >>>>>>>> Congrats on tracking down this elusive bug! >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The fix adds check guards of gdata->vmDead condition to the: >>>>>>>>> - debugLoop (JDWP Event Helper thread) and >>>>>>>>> - commandLoop (JDWP Transport Listener thread) >>>>>>>>> The commands are ignored in the DEAD phase. >>>>>>>> >>>>>>>> In the debugLoop, you aren't ignoring the commands, you >>>>>>>> are setting an error condition. >>>>>>> >>>>>>> Right, I meant: ignored == not executed. :) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The check guard in the debugLoop already existed but only for >>>>>>>>> VirtualMachine >>>>>>>>> command set, so it has been extended to commands from all JDWP >>>>>>>>> command sets. >>>>>>>> >>>>>>>> I'm reading the existing code exactly opposite of what you >>>>>>>> say here. The gdata->vmDead check applied to all command >>>>>>>> sets except for the VirtualMachine command set. I agree >>>>>>>> that you've extended it to all command sets, but we're >>>>>>>> not ignoring the commands. We are now setting the error >>>>>>>> condition for all command sets. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Maybe I'm missing something here. Perhaps I've been away >>>>>>>> from this code for too long... :-) >>>>>>> >>>>>>> No, it is that I'm still learning this code with your help. :-) >>>>>>> >>>>>>> >>>>>>> Thanks a lot! >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I suspect, this bug could also cause some of the timeout and >>>>>>>>> socket related issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> The fix was tested with the nsk.jdi, jtreg com/sun/jdi and 100 >>>>>>>>> runs >>>>>>>>> of the >>>>>>>>> hotspot/test/closed/compiler/c1/6507107/HeapwalkingTest.java. >>>>>>>>> The test results are very clean. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Thu Mar 2 23:57:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Mar 2017 09:57:35 +1000 Subject: Why doesn't jdk.hotspot.agent export anything? In-Reply-To: <81a94169-21b9-858b-b911-f14013a2eb23@oracle.com> References: <81a94169-21b9-858b-b911-f14013a2eb23@oracle.com> Message-ID: <93d2f451-7d83-a92f-5d7b-86d423bbfaa8@oracle.com> On 3/03/2017 5:01 AM, Alan Bateman wrote: > On 02/03/2017 13:31, Volker Simonis wrote: > >> : >> I didn't had the impression that this was a mistake. At least it was >> advertised on " The Java Tuturials Blog" >> >> https://blogs.oracle.com/thejavatutorials/entry/hotspot_serviceability_agent_api_javadoc >> >> >> which seems to be a more or less 'offical' Oracle blog. > I have contacted the author to get this corrected. The SA is unsupported but documented in various ways and places: http://openjdk.java.net/groups/hotspot/docs/Serviceability.html https://blogs.oracle.com/sundararajan/entry/hotspot_source_serviceability_agent http://cr.openjdk.java.net/~minqi/6830717/raw_files/new/agent/doc/index.html (also same content linked from kenai.com) David > -Alan From chris.plummer at oracle.com Tue Mar 7 00:57:08 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Mar 2017 16:57:08 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible Message-ID: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> Hi, Please review the following simple fix. Explanation of the cause and the fix are in the CR. Testing so far has only been done with serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. I think the addition of JPRT push testing will be sufficient. http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ https://bugs.openjdk.java.net/browse/JDK-8175341 thanks, Chris From serguei.spitsyn at oracle.com Tue Mar 7 01:51:47 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Mar 2017 17:51:47 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> Message-ID: <28f5997b-c39a-df5a-0c29-5d6beae0d838@oracle.com> Hi Chris, Looks good. Thanks, Serguei On 3/6/17 16:57, Chris Plummer wrote: > Hi, > > Please review the following simple fix. Explanation of the cause and > the fix are in the CR. Testing so far has only been done with > serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. > I think the addition of JPRT push testing will be sufficient. > > http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ > https://bugs.openjdk.java.net/browse/JDK-8175341 > > thanks, > > Chris > From david.holmes at oracle.com Tue Mar 7 01:51:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Mar 2017 11:51:44 +1000 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> Message-ID: <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> Hi Chris, On 7/03/2017 10:57 AM, Chris Plummer wrote: > Hi, > > Please review the following simple fix. Explanation of the cause and the > fix are in the CR. Testing so far has only been done with > serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. I > think the addition of JPRT push testing will be sufficient. > > http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ > https://bugs.openjdk.java.net/browse/JDK-8175341 Looking at the other potentially-exception-throwing actions in that DCmd and others, I think a simple delete of the assert and change: 425 vmSymbols::finalizer_histogram_klass(), THREAD); to 425 vmSymbols::finalizer_histogram_klass(), CHECK); would suffice. Something upstream has to handle potential errors and the pending exception in any case. Thanks, David > thanks, > > Chris > From david.holmes at oracle.com Tue Mar 7 01:58:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Mar 2017 11:58:21 +1000 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> Message-ID: <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> On 7/03/2017 11:51 AM, David Holmes wrote: > Hi Chris, > > On 7/03/2017 10:57 AM, Chris Plummer wrote: >> Hi, >> >> Please review the following simple fix. Explanation of the cause and the >> fix are in the CR. Testing so far has only been done with >> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. I >> think the addition of JPRT push testing will be sufficient. >> >> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >> https://bugs.openjdk.java.net/browse/JDK-8175341 > > Looking at the other potentially-exception-throwing actions in that DCmd > and others, I think a simple delete of the assert and change: > > 425 vmSymbols::finalizer_histogram_klass(), THREAD); > > to > > 425 vmSymbols::finalizer_histogram_klass(), CHECK); > > would suffice. Something upstream has to handle potential errors and the > pending exception in any case. Oops! This explains why no exception: 424 Klass* k = SystemDictionary::resolve_or_null( 425 vmSymbols::finalizer_histogram_klass(), THREAD); it uses resolve_or_null, not resolve_or_fail! I think it should use the latter and simply throw like the other Dcmds. David > Thanks, > David > >> thanks, >> >> Chris >> From chris.plummer at oracle.com Tue Mar 7 02:14:33 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Mar 2017 18:14:33 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> Message-ID: <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> On 3/6/17 5:58 PM, David Holmes wrote: > On 7/03/2017 11:51 AM, David Holmes wrote: >> Hi Chris, >> >> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>> Hi, >>> >>> Please review the following simple fix. Explanation of the cause and >>> the >>> fix are in the CR. Testing so far has only been done with >>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. I >>> think the addition of JPRT push testing will be sufficient. >>> >>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>> https://bugs.openjdk.java.net/browse/JDK-8175341 >> >> Looking at the other potentially-exception-throwing actions in that DCmd >> and others, I think a simple delete of the assert and change: >> >> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >> >> to >> >> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >> >> would suffice. Something upstream has to handle potential errors and the >> pending exception in any case. > > Oops! This explains why no exception: > > 424 Klass* k = SystemDictionary::resolve_or_null( > 425 vmSymbols::finalizer_histogram_klass(), THREAD); > > it uses resolve_or_null, not resolve_or_fail! I think it should use > the latter and simply throw like the other Dcmds. > Ok. That seems to work. Bit of a hurry here before I step out, so trimmed diff is inline: - Klass* k = SystemDictionary::resolve_or_null( - vmSymbols::finalizer_histogram_klass(), THREAD); - assert(k != NULL, "FinalizerHistogram class is not accessible"); + Klass* k = SystemDictionary::resolve_or_fail( + vmSymbols::finalizer_histogram_klass(), true, CHECK); + if (k == NULL) { + return; + } I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not sure which is correct here. When I forced an exception by dropping the last character of the class name, here's what I see in the test output: stderr: [java.lang.NoClassDefFoundError: java/lang/ref/FinalizerHistogra ] cheers, Chris > David > >> Thanks, >> David >> >>> thanks, >>> >>> Chris >>> From david.holmes at oracle.com Tue Mar 7 02:25:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Mar 2017 12:25:31 +1000 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> Message-ID: On 7/03/2017 12:14 PM, Chris Plummer wrote: > On 3/6/17 5:58 PM, David Holmes wrote: >> On 7/03/2017 11:51 AM, David Holmes wrote: >>> Hi Chris, >>> >>> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>>> Hi, >>>> >>>> Please review the following simple fix. Explanation of the cause and >>>> the >>>> fix are in the CR. Testing so far has only been done with >>>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the CR. I >>>> think the addition of JPRT push testing will be sufficient. >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>>> https://bugs.openjdk.java.net/browse/JDK-8175341 >>> >>> Looking at the other potentially-exception-throwing actions in that DCmd >>> and others, I think a simple delete of the assert and change: >>> >>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>> >>> to >>> >>> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >>> >>> would suffice. Something upstream has to handle potential errors and the >>> pending exception in any case. >> >> Oops! This explains why no exception: >> >> 424 Klass* k = SystemDictionary::resolve_or_null( >> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >> >> it uses resolve_or_null, not resolve_or_fail! I think it should use >> the latter and simply throw like the other Dcmds. >> > Ok. That seems to work. Bit of a hurry here before I step out, so > trimmed diff is inline: > > - Klass* k = SystemDictionary::resolve_or_null( > - vmSymbols::finalizer_histogram_klass(), THREAD); > - assert(k != NULL, "FinalizerHistogram class is not accessible"); > + Klass* k = SystemDictionary::resolve_or_fail( > + vmSymbols::finalizer_histogram_klass(), true, CHECK); > + if (k == NULL) { > + return; > + } > > I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not > sure which is correct here. THREAD is just a reference to the current thread (as passed down the call chain). CHECK automatically expands into a pending exception check plus a return. So your "if (k==null) ..." is unreachable with CHECK - as k will only be NULL if an exception is pending. Thanks, David > When I forced an exception by dropping the last character of the class > name, here's what I see in the test output: > > stderr: [java.lang.NoClassDefFoundError: java/lang/ref/FinalizerHistogra > ] > > cheers, > > Chris >> David >> >>> Thanks, >>> David >>> >>>> thanks, >>>> >>>> Chris >>>> > From chris.plummer at oracle.com Tue Mar 7 05:30:41 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Mar 2017 21:30:41 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> Message-ID: On 3/6/17 6:25 PM, David Holmes wrote: > On 7/03/2017 12:14 PM, Chris Plummer wrote: >> On 3/6/17 5:58 PM, David Holmes wrote: >>> On 7/03/2017 11:51 AM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>>>> Hi, >>>>> >>>>> Please review the following simple fix. Explanation of the cause and >>>>> the >>>>> fix are in the CR. Testing so far has only been done with >>>>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the >>>>> CR. I >>>>> think the addition of JPRT push testing will be sufficient. >>>>> >>>>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8175341 >>>> >>>> Looking at the other potentially-exception-throwing actions in that >>>> DCmd >>>> and others, I think a simple delete of the assert and change: >>>> >>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>> >>>> to >>>> >>>> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >>>> >>>> would suffice. Something upstream has to handle potential errors >>>> and the >>>> pending exception in any case. >>> >>> Oops! This explains why no exception: >>> >>> 424 Klass* k = SystemDictionary::resolve_or_null( >>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>> >>> it uses resolve_or_null, not resolve_or_fail! I think it should use >>> the latter and simply throw like the other Dcmds. >>> >> Ok. That seems to work. Bit of a hurry here before I step out, so >> trimmed diff is inline: >> >> - Klass* k = SystemDictionary::resolve_or_null( >> - vmSymbols::finalizer_histogram_klass(), THREAD); >> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >> + Klass* k = SystemDictionary::resolve_or_fail( >> + vmSymbols::finalizer_histogram_klass(), true, CHECK); >> + if (k == NULL) { >> + return; >> + } >> >> I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not >> sure which is correct here. > > THREAD is just a reference to the current thread (as passed down the > call chain). CHECK automatically expands into a pending exception > check plus a return. So your "if (k==null) ..." is unreachable with > CHECK - as k will only be NULL if an exception is pending. Ok. This seems to work as well: - Klass* k = SystemDictionary::resolve_or_null( - vmSymbols::finalizer_histogram_klass(), THREAD); - assert(k != NULL, "FinalizerHistogram class is not accessible"); + Klass* k = SystemDictionary::resolve_or_fail( + vmSymbols::finalizer_histogram_klass(), true, CHECK); thanks, Chris > > Thanks, > David > >> When I forced an exception by dropping the last character of the class >> name, here's what I see in the test output: >> >> stderr: [java.lang.NoClassDefFoundError: >> java/lang/ref/FinalizerHistogra >> ] >> >> cheers, >> >> Chris >>> David >>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >> From david.holmes at oracle.com Tue Mar 7 07:15:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Mar 2017 17:15:30 +1000 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> Message-ID: <2c3507b8-32c5-78b8-edda-dca6308cd7d7@oracle.com> Sorry for the delay TB decided not to pull any email down from my openjdk folder for 3 hours :( On 7/03/2017 3:30 PM, Chris Plummer wrote: > On 3/6/17 6:25 PM, David Holmes wrote: >> On 7/03/2017 12:14 PM, Chris Plummer wrote: >>> On 3/6/17 5:58 PM, David Holmes wrote: >>>> On 7/03/2017 11:51 AM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following simple fix. Explanation of the cause and >>>>>> the >>>>>> fix are in the CR. Testing so far has only been done with >>>>>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the >>>>>> CR. I >>>>>> think the addition of JPRT push testing will be sufficient. >>>>>> >>>>>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8175341 >>>>> >>>>> Looking at the other potentially-exception-throwing actions in that >>>>> DCmd >>>>> and others, I think a simple delete of the assert and change: >>>>> >>>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>>> >>>>> to >>>>> >>>>> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >>>>> >>>>> would suffice. Something upstream has to handle potential errors >>>>> and the >>>>> pending exception in any case. >>>> >>>> Oops! This explains why no exception: >>>> >>>> 424 Klass* k = SystemDictionary::resolve_or_null( >>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>> >>>> it uses resolve_or_null, not resolve_or_fail! I think it should use >>>> the latter and simply throw like the other Dcmds. >>>> >>> Ok. That seems to work. Bit of a hurry here before I step out, so >>> trimmed diff is inline: >>> >>> - Klass* k = SystemDictionary::resolve_or_null( >>> - vmSymbols::finalizer_histogram_klass(), THREAD); >>> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >>> + Klass* k = SystemDictionary::resolve_or_fail( >>> + vmSymbols::finalizer_histogram_klass(), true, CHECK); >>> + if (k == NULL) { >>> + return; >>> + } >>> >>> I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not >>> sure which is correct here. >> >> THREAD is just a reference to the current thread (as passed down the >> call chain). CHECK automatically expands into a pending exception >> check plus a return. So your "if (k==null) ..." is unreachable with >> CHECK - as k will only be NULL if an exception is pending. > Ok. This seems to work as well: > > - Klass* k = SystemDictionary::resolve_or_null( > - vmSymbols::finalizer_histogram_klass(), THREAD); > - assert(k != NULL, "FinalizerHistogram class is not accessible"); > + Klass* k = SystemDictionary::resolve_or_fail( > + vmSymbols::finalizer_histogram_klass(), true, CHECK); Yep looks good to me. Thanks, David ----- > thanks, > > Chris >> >> Thanks, >> David >> >>> When I forced an exception by dropping the last character of the class >>> name, here's what I see in the test output: >>> >>> stderr: [java.lang.NoClassDefFoundError: >>> java/lang/ref/FinalizerHistogra >>> ] >>> >>> cheers, >>> >>> Chris >>>> David >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>> > From serguei.spitsyn at oracle.com Tue Mar 7 09:38:34 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Mar 2017 01:38:34 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <2c3507b8-32c5-78b8-edda-dca6308cd7d7@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> <2c3507b8-32c5-78b8-edda-dca6308cd7d7@oracle.com> Message-ID: <086a809d-5cf6-b226-7165-2cc9efb335c9@oracle.com> On 3/6/17 23:15, David Holmes wrote: > Sorry for the delay TB decided not to pull any email down from my > openjdk folder for 3 hours :( > > On 7/03/2017 3:30 PM, Chris Plummer wrote: >> On 3/6/17 6:25 PM, David Holmes wrote: >>> On 7/03/2017 12:14 PM, Chris Plummer wrote: >>>> On 3/6/17 5:58 PM, David Holmes wrote: >>>>> On 7/03/2017 11:51 AM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following simple fix. Explanation of the cause >>>>>>> and >>>>>>> the >>>>>>> fix are in the CR. Testing so far has only been done with >>>>>>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the >>>>>>> CR. I >>>>>>> think the addition of JPRT push testing will be sufficient. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>>>>>> >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8175341 >>>>>> >>>>>> Looking at the other potentially-exception-throwing actions in that >>>>>> DCmd >>>>>> and others, I think a simple delete of the assert and change: >>>>>> >>>>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>>>> >>>>>> to >>>>>> >>>>>> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >>>>>> >>>>>> would suffice. Something upstream has to handle potential errors >>>>>> and the >>>>>> pending exception in any case. >>>>> >>>>> Oops! This explains why no exception: >>>>> >>>>> 424 Klass* k = SystemDictionary::resolve_or_null( >>>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>>> >>>>> it uses resolve_or_null, not resolve_or_fail! I think it should use >>>>> the latter and simply throw like the other Dcmds. >>>>> >>>> Ok. That seems to work. Bit of a hurry here before I step out, so >>>> trimmed diff is inline: >>>> >>>> - Klass* k = SystemDictionary::resolve_or_null( >>>> - vmSymbols::finalizer_histogram_klass(), THREAD); >>>> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >>>> + Klass* k = SystemDictionary::resolve_or_fail( >>>> + vmSymbols::finalizer_histogram_klass(), true, CHECK); >>>> + if (k == NULL) { >>>> + return; >>>> + } >>>> >>>> I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not >>>> sure which is correct here. >>> >>> THREAD is just a reference to the current thread (as passed down the >>> call chain). CHECK automatically expands into a pending exception >>> check plus a return. So your "if (k==null) ..." is unreachable with >>> CHECK - as k will only be NULL if an exception is pending. >> Ok. This seems to work as well: >> >> - Klass* k = SystemDictionary::resolve_or_null( >> - vmSymbols::finalizer_histogram_klass(), THREAD); >> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >> + Klass* k = SystemDictionary::resolve_or_fail( >> + vmSymbols::finalizer_histogram_klass(), true, CHECK); > > Yep looks good to me. +1 Thanks, Serguei > > Thanks, > David > ----- > >> thanks, >> >> Chris >>> >>> Thanks, >>> David >>> >>>> When I forced an exception by dropping the last character of the class >>>> name, here's what I see in the test output: >>>> >>>> stderr: [java.lang.NoClassDefFoundError: >>>> java/lang/ref/FinalizerHistogra >>>> ] >>>> >>>> cheers, >>>> >>>> Chris >>>>> David >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>> >> From daniel.fuchs at oracle.com Tue Mar 7 15:10:53 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 Mar 2017 15:10:53 +0000 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: References: Message-ID: Hi Harsha, Not a review either (at least not a complete one). PlatformMBeanProviderImpl: 281 @Override 282 public Set> mbeanInterfaces() { 283 return Collections.emptySet(); 284 } For future maintainers, I think it would be good to copy the comment at line 250 and insert it before line 283 too: 250 // DynamicMBean cannot be used to find an MBean by ManagementFactory HotSpotPerfCounterMBean: Exception handling: I have the feeling that this part might be a bit over-engineered. If you look at javax.management.StandardMBean (which is a canonical implementation of DynamicMBean) and then transitively at MBeanSupport and PerInterface where this class eventually delegates to, you will see that: 1. You can throw NPE in setAttribute when attribute == null (no need for all the wrapping) 2. You should throw AttributeNotFoundException when attempting to read a write-only attribute or write a read-only attribute 3. You can throw NPE if AttributeList is null 179 String typeName = "java.lang.String"; That looks like a hack. What if at some point the value of that attribute becomes non null, and its class is *not* java.lang.String? Then MBeanAttributeInfo would be lying. If that ever happens - then it would be more consistent to coerce the value to its declared type (String) before sending it as a a result for getAttribute. Or better, find a way to figure out what should be the class name of the value even if the value is null (isn't there some metadata available for these perf counters somewhere?). PerfCounterMBeanTest: testGetAttribute should verify that class of the returned value corresponds to what was declared in the MBeanAttributeInfo for the corresponding attribute. cheers, -- daniel On 26/02/17 16:50, Harsha Wardhana B wrote: > Hi All, > > Please review the below RFE, > > JDK-8007141 : Introduce Dynamic MBean exposing the > perf counters. > > with webrev at, > > http://cr.openjdk.java.net/~hb/8007141/webrev.00/ > > Appreciate if I can get inputs for below. > > 1. Location of HotSpotPerfCounterMBean. It is located at > src/jdk.management/share/classes/com/sun/management/internal. It can be > moved to src/jdk.management/share/classes/com/sun/management if required. > > 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is adequate. > > 3. Description for each attribute of MBean. I am using getUnits(), > getVariability(), and getFlags() for description. I am not sure if that > is the right description. Appreciate inputs from someone who knows perf > counters well. > > Thanks > > Harsha > > From chris.plummer at oracle.com Tue Mar 7 20:51:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Mar 2017 12:51:43 -0800 Subject: RFR(10)(XXS): 8175341: "java/util/Arrays/ParallelPrefix.java" Crash Internal Error ...diagnosticCommand.cpp...assert(k != __null) failed: FinalizerHistogram class is not accessible In-Reply-To: <086a809d-5cf6-b226-7165-2cc9efb335c9@oracle.com> References: <9cc051d1-b8f6-3cb5-2f67-d43ec4dba192@oracle.com> <77c02bf3-343d-546c-1d62-e7d3f7fea90b@oracle.com> <2b329347-2082-a06c-c208-17fbac9c0b47@oracle.com> <3aa341c5-7855-501b-29e6-f36e57e6a9dd@oracle.com> <2c3507b8-32c5-78b8-edda-dca6308cd7d7@oracle.com> <086a809d-5cf6-b226-7165-2cc9efb335c9@oracle.com> Message-ID: <4d385831-d1ca-40cb-2049-4fc00d1fdf05@oracle.com> On 3/7/17 1:38 AM, serguei.spitsyn at oracle.com wrote: > On 3/6/17 23:15, David Holmes wrote: >> Sorry for the delay TB decided not to pull any email down from my >> openjdk folder for 3 hours :( >> >> On 7/03/2017 3:30 PM, Chris Plummer wrote: >>> On 3/6/17 6:25 PM, David Holmes wrote: >>>> On 7/03/2017 12:14 PM, Chris Plummer wrote: >>>>> On 3/6/17 5:58 PM, David Holmes wrote: >>>>>> On 7/03/2017 11:51 AM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 7/03/2017 10:57 AM, Chris Plummer wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the following simple fix. Explanation of the >>>>>>>> cause and >>>>>>>> the >>>>>>>> fix are in the CR. Testing so far has only been done with >>>>>>>> serviceability/dcmd/gc/FinalizerInfoTest.java as described in the >>>>>>>> CR. I >>>>>>>> think the addition of JPRT push testing will be sufficient. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8175341/webrev.00/webrev.hotspot/ >>>>>>>> >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8175341 >>>>>>> >>>>>>> Looking at the other potentially-exception-throwing actions in that >>>>>>> DCmd >>>>>>> and others, I think a simple delete of the assert and change: >>>>>>> >>>>>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>>>>> >>>>>>> to >>>>>>> >>>>>>> 425 vmSymbols::finalizer_histogram_klass(), CHECK); >>>>>>> >>>>>>> would suffice. Something upstream has to handle potential errors >>>>>>> and the >>>>>>> pending exception in any case. >>>>>> >>>>>> Oops! This explains why no exception: >>>>>> >>>>>> 424 Klass* k = SystemDictionary::resolve_or_null( >>>>>> 425 vmSymbols::finalizer_histogram_klass(), THREAD); >>>>>> >>>>>> it uses resolve_or_null, not resolve_or_fail! I think it should use >>>>>> the latter and simply throw like the other Dcmds. >>>>>> >>>>> Ok. That seems to work. Bit of a hurry here before I step out, so >>>>> trimmed diff is inline: >>>>> >>>>> - Klass* k = SystemDictionary::resolve_or_null( >>>>> - vmSymbols::finalizer_histogram_klass(), THREAD); >>>>> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >>>>> + Klass* k = SystemDictionary::resolve_or_fail( >>>>> + vmSymbols::finalizer_histogram_klass(), true, CHECK); >>>>> + if (k == NULL) { >>>>> + return; >>>>> + } >>>>> >>>>> I'm a bit unclear about THREAD vs CHECK. They both seem to work. Not >>>>> sure which is correct here. >>>> >>>> THREAD is just a reference to the current thread (as passed down the >>>> call chain). CHECK automatically expands into a pending exception >>>> check plus a return. So your "if (k==null) ..." is unreachable with >>>> CHECK - as k will only be NULL if an exception is pending. >>> Ok. This seems to work as well: >>> >>> - Klass* k = SystemDictionary::resolve_or_null( >>> - vmSymbols::finalizer_histogram_klass(), THREAD); >>> - assert(k != NULL, "FinalizerHistogram class is not accessible"); >>> + Klass* k = SystemDictionary::resolve_or_fail( >>> + vmSymbols::finalizer_histogram_klass(), true, CHECK); >> >> Yep looks good to me. > > +1 > > Thanks, > Serguei David and Serguie, thanks for the reviews! Chris > > >> >> Thanks, >> David >> ----- >> >>> thanks, >>> >>> Chris >>>> >>>> Thanks, >>>> David >>>> >>>>> When I forced an exception by dropping the last character of the >>>>> class >>>>> name, here's what I see in the test output: >>>>> >>>>> stderr: [java.lang.NoClassDefFoundError: >>>>> java/lang/ref/FinalizerHistogra >>>>> ] >>>>> >>>>> cheers, >>>>> >>>>> Chris >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>> >>> > From igor.ignatyev at oracle.com Tue Mar 7 21:07:55 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Mar 2017 13:07:55 -0800 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests Message-ID: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html > 2586 lines changed: 669 ins; 484 del; 1433 mod; Hi all, Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? there are a couple issues w/ modules in jdk_svc tests: - some tests do not specify modules which they depend on - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive - @modules directive isn't placed according to current convention (before the 1st run directive) Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. There are two one-liners which, I hope, can simplify review: [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): test/com/sun/jdi/ArgumentValuesTest.java test/com/sun/jdi/BreakpointTest.java test/com/sun/jdi/FetchLocals.java test/com/sun/jdi/GetLocalVariables.java test/com/sun/jdi/GetSetLocalTest.java test/com/sun/jdi/LambdaBreakpointTest.java test/com/sun/jdi/LineNumberOnBraceTest.java test/com/sun/jdi/PopAndStepTest.java [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html bug: https://bugs.openjdk.java.net/browse/JDK-8176176 Testing: - jdk_svc on linux, windows, mac - checked that all tests which could be executed with full jdk before still can be executed with full jdk Thanks, ? Igor [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" From harsha.wardhana.b at oracle.com Wed Mar 8 04:12:12 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 8 Mar 2017 09:42:12 +0530 Subject: RFR - [RFE] JDK-8007141 : Introduce Dynamic MBean exposing the perf counters In-Reply-To: References: Message-ID: Hi Daniel, On Tuesday 07 March 2017 08:40 PM, Daniel Fuchs wrote: > Hi Harsha, > > Not a review either (at least not a complete one). > > PlatformMBeanProviderImpl: > > 281 @Override > 282 public Set> > mbeanInterfaces() { > 283 return Collections.emptySet(); > 284 } > > For future maintainers, I think it would be good to copy > the comment at line 250 and insert it before line 283 too: > 250 // DynamicMBean cannot be used to find an > MBean by ManagementFactory > Will do. > HotSpotPerfCounterMBean: > > Exception handling: I have the feeling that this part might > be a bit over-engineered. If you look at javax.management.StandardMBean > (which is a canonical implementation of DynamicMBean) and > then transitively at MBeanSupport and PerInterface where this class > eventually delegates to, you will see that: > > 1. You can throw NPE in setAttribute when attribute == null (no need for > all the wrapping) If attribute == null, isn't it better to throw IllegalArgumentException instead of NPE? I'll remove the wrapping. > 2. You should throw AttributeNotFoundException when attempting to read > a write-only attribute or write a read-only attribute Isn't UnSupportedOperationEx better than AttributeNotFoundException? Have we committed to above in the specs? > 3. You can throw NPE if AttributeList is null If attribute == null, isn't it better to throw IllegalArgumentException instead of NPE? I'll remove the wrapping. > > 179 String typeName = "java.lang.String"; > > That looks like a hack. If attribute is null, defaulting to String would be convenient as getAttribute can return empty string instead of null. Do you think otherwise? > > What if at some point the value of that attribute becomes non null, > and its class is *not* java.lang.String? > Then MBeanAttributeInfo would be lying. > If that ever happens - then it would be more consistent to coerce > the value to its declared type (String) before sending it as a > a result for getAttribute. Since perf-counters are key-value pairs written into shared memory, it is reasonable to expect new counters to be added or type of existing counters to be updated while VM is running. I have to refresh the counters periodically (maybe once every 5 mins) since I will not be notified of any change. If any attributes are added or if existing attribute types are changed, then AttributeChangeNotification will be sent. Clients will have to refresh MBeanInfo upon receiving this notification. So yeah, there is a brief window where MBeanInfo will be lying. I don't see easy way to fix it unlesss perfcounters can notify MBean of any mutations. Maybe the limitation can be documented. I will make these changes in next webrev. > Or better, find a way to figure out what should be the class name > of the value even if the value is null (isn't there some metadata > available for these perf counters somewhere?). > > PerfCounterMBeanTest: > > testGetAttribute should verify that class of the returned value > corresponds to what was declared in the MBeanAttributeInfo for the > corresponding attribute. Sure. Will do. > > cheers, > > -- daniel -Harsha > > On 26/02/17 16:50, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the below RFE, >> >> JDK-8007141 : Introduce Dynamic MBean exposing the >> perf counters. >> >> with webrev at, >> >> http://cr.openjdk.java.net/~hb/8007141/webrev.00/ >> >> Appreciate if I can get inputs for below. >> >> 1. Location of HotSpotPerfCounterMBean. It is located at >> src/jdk.management/share/classes/com/sun/management/internal. It can be >> moved to src/jdk.management/share/classes/com/sun/management if >> required. >> >> 2. Javadoc comments for HotSpotPerfCounterMBean. Not sure if it is >> adequate. >> >> 3. Description for each attribute of MBean. I am using getUnits(), >> getVariability(), and getFlags() for description. I am not sure if that >> is the right description. Appreciate inputs from someone who knows perf >> counters well. >> >> Thanks >> >> Harsha >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergei.kovalev at oracle.com Thu Mar 9 11:05:31 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 9 Mar 2017 14:05:31 +0300 Subject: RFR(s): 8176304: Number of javax/management test fails due to undeclared dependencies In-Reply-To: <792857f4-61fb-f1ed-4f1c-f8d4ac750661@oracle.com> References: <792857f4-61fb-f1ed-4f1c-f8d4ac750661@oracle.com> Message-ID: <4639e7ee-4aff-3768-c2c7-aa18a190d270@oracle.com> Hi Daniel, Thank you for the review. I'v revised dependencies based on you comments and made some changes. Please take a look at the result. http://cr.openjdk.java.net/~skovalev/8176304/webrev.01 -- With best regards, Sergei 07.03.17 18:55, Daniel Fuchs wrote: > Hi Sergei, > > I have several observations: > > - AFAIK you don't need to list modules that > are required by a module already listed. > > so for instance, if you list jdk.management.agent then > you don't need to list java.management or java.management.rmi > (unless you need qualified exports from those) > > - AFAICS some (most?) of these tests depend on > java.management.rmi and not on jdk.management.agent > > Did you try to simply add java.management.rmi first? > > best regards, > > -- daniel > > > On 07/03/17 15:31, Sergei Kovalev wrote: >> Hi Team, >> >> Please take a look at the fix for javax.management tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8176304 >> Webrev: http://cr.openjdk.java.net/~skovalev/8176304/webrev.00/ >> >> Issue: number of tests failing with "--limit-module" command line option >> due to missed dependencies. In general missed dependencies are: >> jdk.management.agent and jdk.naming.rmi modules. From daniel.fuchs at oracle.com Thu Mar 9 11:21:34 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 9 Mar 2017 11:21:34 +0000 Subject: RFR(s): 8176304: Number of javax/management test fails due to undeclared dependencies In-Reply-To: <4639e7ee-4aff-3768-c2c7-aa18a190d270@oracle.com> References: <792857f4-61fb-f1ed-4f1c-f8d4ac750661@oracle.com> <4639e7ee-4aff-3768-c2c7-aa18a190d270@oracle.com> Message-ID: <11bb4e07-f850-479e-f736-f9cb29183025@oracle.com> Hi Sergei, Looks good to me now. best regards, -- daniel On 09/03/2017 11:05, Sergei Kovalev wrote: > Hi Daniel, > > Thank you for the review. I'v revised dependencies based on you comments > and made some changes. Please take a look at the result. > > http://cr.openjdk.java.net/~skovalev/8176304/webrev.01 > From alexandre.iline at oracle.com Fri Mar 10 01:02:00 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 9 Mar 2017 17:02:00 -0800 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> Message-ID: Igor, I have reviewed some number tests which change the @modules - they are fine. You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? Shura [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html > On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >> 2586 lines changed: 669 ins; 484 del; 1433 mod; > > Hi all, > > Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? > there are a couple issues w/ modules in jdk_svc tests: > - some tests do not specify modules which they depend on > - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive > - @modules directive isn't placed according to current convention (before the 1st run directive) > > Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. > > Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. > > There are two one-liners which, I hope, can simplify review: > [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): > test/com/sun/jdi/ArgumentValuesTest.java > test/com/sun/jdi/BreakpointTest.java > test/com/sun/jdi/FetchLocals.java > test/com/sun/jdi/GetLocalVariables.java > test/com/sun/jdi/GetSetLocalTest.java > test/com/sun/jdi/LambdaBreakpointTest.java > test/com/sun/jdi/LineNumberOnBraceTest.java > test/com/sun/jdi/PopAndStepTest.java > > [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. > > webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html > bug: https://bugs.openjdk.java.net/browse/JDK-8176176 > Testing: > - jdk_svc on linux, windows, mac > - checked that all tests which could be executed with full jdk before still can be executed with full jdk > > Thanks, > ? Igor > > [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" > [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" From robbin.ehn at oracle.com Fri Mar 10 12:56:58 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 10 Mar 2017 13:56:58 +0100 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Message-ID: Hi Dmitry, I took a look at this, I have two practical issues: 1: [rehn at rehn-ws dev]$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 -cp runs ForEver Listening for transport dt_socket at address: 9999 ERROR: transport error 202: peer not allowed to connect: Success JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error [transport.c:358] So connecting with an unallowed client terminates the VM. 2: [rehn at rehn-ws dev]$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 -cp runs ForEver Listening for transport dt_socket at address: 9999 ERROR: transport error 202: unable to parse list of allowed peers: Success JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error [transport.c:358] Starting with an bad allow filter terminates the VM when connecting a client. Connecting with an unallowed ip/port should not terminate the VM and we should verify allow filter directly at startup. Thanks /Robbin On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ > > These changes introduce new parameter[1] of the socket transport - > allow. Users can explicitly specify a list of hosts that allowed to > connect to jdwp server and it's the second part of JDWP hardening[2]. > > No restrictions are applied by default now but I'll file a separate CR > to restrict list of allowed peers to localhost by default. > > Also these changes implement versioning for jdwp transport and therefor > simplify feature development of jdwp. > > > 1. Example command line: > > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, > address=*,allow="127.0.0.0/8;192.168.0.0/24" > > Possible values for allow parameter: > * - accept connections from everywhere. > N.N.N.N - accept connections from this IP address only > N.N.N.N/nn - accept connections from particular ip subnet > > > > 2. JDK-8052136 JDWP hardening > > -Dmitry > From dmitry.samersoff at oracle.com Fri Mar 10 14:21:28 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 10 Mar 2017 17:21:28 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Message-ID: Robbin, Agree, I'll fix it. -Dmitry On 2017-03-10 15:56, Robbin Ehn wrote: > Hi Dmitry, > > I took a look at this, I have two practical issues: > > 1: > [rehn at rehn-ws dev]$ java > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 > -cp runs ForEver > Listening for transport dt_socket at address: 9999 > ERROR: transport error 202: peer not allowed to connect: Success > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal > error [transport.c:358] > > So connecting with an unallowed client terminates the VM. > > 2: > [rehn at rehn-ws dev]$ java > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 > -cp runs ForEver > Listening for transport dt_socket at address: 9999 > ERROR: transport error 202: unable to parse list of allowed peers: Success > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal > error [transport.c:358] > > Starting with an bad allow filter terminates the VM when connecting a > client. > > > Connecting with an unallowed ip/port should not terminate the VM and we > should verify allow filter directly at startup. > > Thanks > > /Robbin > > On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >> >> These changes introduce new parameter[1] of the socket transport - >> allow. Users can explicitly specify a list of hosts that allowed to >> connect to jdwp server and it's the second part of JDWP hardening[2]. >> >> No restrictions are applied by default now but I'll file a separate CR >> to restrict list of allowed peers to localhost by default. >> >> Also these changes implement versioning for jdwp transport and therefor >> simplify feature development of jdwp. >> >> >> 1. Example command line: >> >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >> address=*,allow="127.0.0.0/8;192.168.0.0/24" >> >> Possible values for allow parameter: >> * - accept connections from everywhere. >> N.N.N.N - accept connections from this IP address only >> N.N.N.N/nn - accept connections from particular ip subnet >> >> >> >> 2. JDK-8052136 JDWP hardening >> >> -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 Mar 13 19:07:50 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 13 Mar 2017 22:07:50 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Message-ID: Robbin, Please, see: http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.11 > 1: > So connecting with an unallowed client terminates the VM. Fixed. > 2: > Starting with an bad allow filter terminates the VM when connecting a > client. Moved allowed parameter (and parser call) to StartListening. -Dmitry On 2017-03-10 15:56, Robbin Ehn wrote: > Hi Dmitry, > > I took a look at this, I have two practical issues: > > 1: > [rehn at rehn-ws dev]$ java > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 > -cp runs ForEver > Listening for transport dt_socket at address: 9999 > ERROR: transport error 202: peer not allowed to connect: Success > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal > error [transport.c:358] > > So connecting with an unallowed client terminates the VM. > > 2: > [rehn at rehn-ws dev]$ java > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 > -cp runs ForEver > Listening for transport dt_socket at address: 9999 > ERROR: transport error 202: unable to parse list of allowed peers: Success > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal > error [transport.c:358] > > Starting with an bad allow filter terminates the VM when connecting a > client. > > > Connecting with an unallowed ip/port should not terminate the VM and we > should verify allow filter directly at startup. > > Thanks > > /Robbin > > On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >> >> These changes introduce new parameter[1] of the socket transport - >> allow. Users can explicitly specify a list of hosts that allowed to >> connect to jdwp server and it's the second part of JDWP hardening[2]. >> >> No restrictions are applied by default now but I'll file a separate CR >> to restrict list of allowed peers to localhost by default. >> >> Also these changes implement versioning for jdwp transport and therefor >> simplify feature development of jdwp. >> >> >> 1. Example command line: >> >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >> address=*,allow="127.0.0.0/8;192.168.0.0/24" >> >> Possible values for allow parameter: >> * - accept connections from everywhere. >> N.N.N.N - accept connections from this IP address only >> N.N.N.N/nn - accept connections from particular ip subnet >> >> >> >> 2. JDK-8052136 JDWP hardening >> >> -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 igor.ignatyev at oracle.com Tue Mar 14 04:03:16 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 13 Mar 2017 21:03:16 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> Message-ID: <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> Shura, Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html Thanks, ? Igor > On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: > > Igor, > > I have reviewed some number tests which change the @modules - they are fine. > > You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? > > Shura > > [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html > [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html > >> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >> >> Hi all, >> >> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >> there are a couple issues w/ modules in jdk_svc tests: >> - some tests do not specify modules which they depend on >> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >> - @modules directive isn't placed according to current convention (before the 1st run directive) >> >> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >> >> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >> >> There are two one-liners which, I hope, can simplify review: >> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >> test/com/sun/jdi/ArgumentValuesTest.java >> test/com/sun/jdi/BreakpointTest.java >> test/com/sun/jdi/FetchLocals.java >> test/com/sun/jdi/GetLocalVariables.java >> test/com/sun/jdi/GetSetLocalTest.java >> test/com/sun/jdi/LambdaBreakpointTest.java >> test/com/sun/jdi/LineNumberOnBraceTest.java >> test/com/sun/jdi/PopAndStepTest.java >> >> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >> Testing: >> - jdk_svc on linux, windows, mac >> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >> >> Thanks, >> ? Igor >> >> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Mar 14 17:34:50 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Mar 2017 10:34:50 -0700 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: Message-ID: I've added the seviceability-dev mailing list as the SetNativeMethodPrefix() is in the JVM TI interface. Thanks, Serguei On 3/14/17 06:24, Michael Rasmussen wrote: > Hi > > If you set a native prefix using SetNativeMethodPrefix, in order to wrap > native methods. If those methods are annotated with @HotSpotIntrinsicCandidate > you get a warning when running. > > For instance for Thread::isInterrupted: > Compiler intrinsic is defined for method > [java.lang.Thread.isInterrupted(Z)Z], but the method is not annotated with > @HotSpotIntrinsicCandidate. Method will not be inlined. > Method [java.lang.Thread.$prefix$isInterrupted(Z)Z] is annotated with > @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the > method. > > Shouldn't the native prefix be taken into account for this? > > Kind regards > > Michael Rasmussen > JRebel, ZeroTurnaround From vladimir.x.ivanov at oracle.com Tue Mar 14 18:30:57 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Mar 2017 21:30:57 +0300 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: Message-ID: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> Nice catch, Michael! @HotSpotIntrinsicCandidate starts to pay off :-) So, if a native method w/ an intrinsic is instrumented, it won't be intrinsified anymore. Looking into the code, it looks like it worked that way from the very beginning. Filed an RFE: https://bugs.openjdk.java.net/browse/JDK-8176771 Do you have any problems when the JVM issues such warnings? Best regards, Vladimir Ivanov > On 3/14/17 06:24, Michael Rasmussen wrote: >> Hi >> >> If you set a native prefix using SetNativeMethodPrefix, in order to wrap >> native methods. If those methods are annotated with >> @HotSpotIntrinsicCandidate >> you get a warning when running. >> >> For instance for Thread::isInterrupted: >> Compiler intrinsic is defined for method >> [java.lang.Thread.isInterrupted(Z)Z], but the method is not annotated >> with >> @HotSpotIntrinsicCandidate. Method will not be inlined. >> Method [java.lang.Thread.$prefix$isInterrupted(Z)Z] is annotated with >> @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the >> method. >> >> Shouldn't the native prefix be taken into account for this? >> >> Kind regards >> >> Michael Rasmussen >> JRebel, ZeroTurnaround > From vladimir.x.ivanov at oracle.com Tue Mar 14 18:48:59 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Mar 2017 21:48:59 +0300 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> Message-ID: Just in case it will cause problems for you, there's a workaround: you can prune @HotSpotIntrinsicCandidate during instrumentation. Best regards, Vladimir Ivanov On 3/14/17 9:45 PM, Michael Rasmussen wrote: > On 14 March 2017 at 20:30, Vladimir Ivanov wrote: >> Do you have any problems when the JVM issues such warnings? > > We only just recently resumed our integration with JDK9 (was waiting > for the API (especially jigsaw) to stabilize), so I don't yet know the > full extend of these warnings, or if they will cause some actual > problems as well. > > The warnings seems more of a nuisance than a problem, as we do add a > native-prefix to a lot of native methods, there are bounds to be some > hotspot intrinsic among them. > But for now, I'll just add it to the list of warnings that can be > ignored, most noticeably the "JavaLaunchHelper is implemented in both > ... " warning on macOS, when launching with an agent. > > /Michael > From vladimir.x.ivanov at oracle.com Tue Mar 14 19:03:42 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Mar 2017 22:03:42 +0300 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> Message-ID: <1fef2eae-529f-4c01-2faf-30481a04e1d9@oracle.com> >> Just in case it will cause problems for you, there's a workaround: you can >> prune @HotSpotIntrinsicCandidate during instrumentation. > > Wouldn't that just cause the 2nd warning to disappear, but the first > one would remain? Yes, you are right. Then the only option is: -XX:+UnlockDiagnosticVMOptions -XX:-CheckIntrinsics Best regards, Vladimir Ivanov From michael.rasmussen at zeroturnaround.com Tue Mar 14 18:45:30 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Tue, 14 Mar 2017 20:45:30 +0200 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> Message-ID: On 14 March 2017 at 20:30, Vladimir Ivanov wrote: > Do you have any problems when the JVM issues such warnings? We only just recently resumed our integration with JDK9 (was waiting for the API (especially jigsaw) to stabilize), so I don't yet know the full extend of these warnings, or if they will cause some actual problems as well. The warnings seems more of a nuisance than a problem, as we do add a native-prefix to a lot of native methods, there are bounds to be some hotspot intrinsic among them. But for now, I'll just add it to the list of warnings that can be ignored, most noticeably the "JavaLaunchHelper is implemented in both ... " warning on macOS, when launching with an agent. /Michael From michael.rasmussen at zeroturnaround.com Tue Mar 14 18:50:26 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Tue, 14 Mar 2017 20:50:26 +0200 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> Message-ID: On 14 March 2017 at 20:48, Vladimir Ivanov wrote: > Just in case it will cause problems for you, there's a workaround: you can > prune @HotSpotIntrinsicCandidate during instrumentation. Wouldn't that just cause the 2nd warning to disappear, but the first one would remain? /Michael From serguei.spitsyn at oracle.com Tue Mar 14 21:40:58 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Mar 2017 14:40:58 -0700 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Message-ID: <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> Hi Dmitry, We already had a big review thread back in 2014 on this. I think, it is again going in the wrong order. First, I think, it is better to start from a CCC (or its equivalent, CSR). This will allow to focus on and sort out the changes in interface/behavior first before going into the implementation details. Second, I'd suggest to separate a couple of other things. I still see the C .vs. C++ related change in the jdwpTransport.h. It is better to leave it along for now as it was suggested in early review rounds. If you still want to fix it then it is better to file a separate bug that should include the JNI as well (as it was discussed with Alan before). Also, I'm thinking if it is a good idea to separate the transport versioning to an RFE. It would allow to focus on this aspect as necessary. In this case, the 8061228 will depend on the versioning. However, it is much more simple and can be resolved faster. Thanks, Serguei On 2/28/17 01:41, Dmitry Samersoff wrote: > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ > > These changes introduce new parameter[1] of the socket transport - > allow. Users can explicitly specify a list of hosts that allowed to > connect to jdwp server and it's the second part of JDWP hardening[2]. > > No restrictions are applied by default now but I'll file a separate CR > to restrict list of allowed peers to localhost by default. > > Also these changes implement versioning for jdwp transport and therefor > simplify feature development of jdwp. > > > 1. Example command line: > > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, > address=*,allow="127.0.0.0/8;192.168.0.0/24" > > Possible values for allow parameter: > * - accept connections from everywhere. > N.N.N.N - accept connections from this IP address only > N.N.N.N/nn - accept connections from particular ip subnet > > > > 2. JDK-8052136 JDWP hardening > > -Dmitry > From dmitry.samersoff at oracle.com Wed Mar 15 07:56:40 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Mar 2017 10:56:40 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> Message-ID: <09941e94-e755-0318-04fa-19117eb14195@oracle.com> Serguei, > I still see the C .vs. C++ related change in the jdwpTransport.h. done. http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/ see also inline. On 2017-03-15 00:40, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > We already had a big review thread back in 2014 on this. > I think, it is again going in the wrong order. > > First, I think, it is better to start from a CCC (or its equivalent, CSR). > This will allow to focus on and sort out the changes in interface/behavior > first before going into the implementation details. CCC was filed and approved. The only reason I withdraw it - the fix didn't go to jdk9 but CCC tool doesn't have jdk10. CSR process is also not yet implemented. > Second, I'd suggest to separate a couple of other things. > I still see the C .vs. C++ related change in the jdwpTransport.h. > It is better to leave it along for now as it was suggested in early > review rounds. > If you still want to fix it then it is better to file a separate bug that > should include the JNI as well (as it was discussed with Alan before). Do you mean? 39 #ifdef __cplusplus 40 extern "C" { 41 #endif I'll add it back to avoid any confusion. > Also, I'm thinking if it is a good idea to separate the transport > versioning to an RFE. > It would allow to focus on this aspect as necessary. > In this case, the 8061228 will depend on the versioning. > However, it is much more simple and can be resolved faster. It's hard to test versioning code without implementation of new, VERSION_1_1 transport. Network part of 8061228 is simple and clear separated from versioning, so I would prefer to keep it together in one CR/one push. Restriction turned off by default (I'll file separate CR to enable it later), so we have enough time to fix any issues that might come. -Dmitry > > > Thanks, > Serguei > > > On 2/28/17 01:41, Dmitry Samersoff wrote: >> Everybody, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >> >> These changes introduce new parameter[1] of the socket transport - >> allow. Users can explicitly specify a list of hosts that allowed to >> connect to jdwp server and it's the second part of JDWP hardening[2]. >> >> No restrictions are applied by default now but I'll file a separate CR >> to restrict list of allowed peers to localhost by default. >> >> Also these changes implement versioning for jdwp transport and therefor >> simplify feature development of jdwp. >> >> >> 1. Example command line: >> >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >> address=*,allow="127.0.0.0/8;192.168.0.0/24" >> >> Possible values for allow parameter: >> * - accept connections from everywhere. >> N.N.N.N - accept connections from this IP address only >> N.N.N.N/nn - accept connections from particular ip subnet >> >> >> >> 2. JDK-8052136 JDWP hardening >> >> -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 alexandre.iline at oracle.com Wed Mar 15 16:56:23 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 15 Mar 2017 09:56:23 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> Message-ID: <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> Igor, I have looked through a bunch of tests where @modules is changed - that looks good. One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because ?modules? property is concatenated through the hierarchy. java.management is already listed in test/java/lang/management/TEST.properties. Shura > On Mar 13, 2017, at 9:03 PM, Igor Ignatyev wrote: > > Shura, > > Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. > > [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html > > Thanks, > ? Igor > >> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: >> >> Igor, >> >> I have reviewed some number tests which change the @modules - they are fine. >> >> You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? >> >> Shura >> >> [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html >> [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html >> >>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >>> >>> Hi all, >>> >>> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >>> there are a couple issues w/ modules in jdk_svc tests: >>> - some tests do not specify modules which they depend on >>> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >>> - @modules directive isn't placed according to current convention (before the 1st run directive) >>> >>> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >>> >>> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >>> >>> There are two one-liners which, I hope, can simplify review: >>> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >>> test/com/sun/jdi/ArgumentValuesTest.java >>> test/com/sun/jdi/BreakpointTest.java >>> test/com/sun/jdi/FetchLocals.java >>> test/com/sun/jdi/GetLocalVariables.java >>> test/com/sun/jdi/GetSetLocalTest.java >>> test/com/sun/jdi/LambdaBreakpointTest.java >>> test/com/sun/jdi/LineNumberOnBraceTest.java >>> test/com/sun/jdi/PopAndStepTest.java >>> >>> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >>> Testing: >>> - jdk_svc on linux, windows, mac >>> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >>> >>> Thanks, >>> ? Igor >>> >>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" >> > From robbin.ehn at oracle.com Wed Mar 15 17:41:37 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Mar 2017 18:41:37 +0100 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool Message-ID: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> Hi all, please review: When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap don't work until a debugger have attach. There is an underlying issue with AttachProvider that don't list that VM even if it's attachable. That issue is present in JDK 8 (?jcmd -l? don?t list this process). This fix only fixes the regression by not validating the pid against available VirtualMachineDescriptors. One problem with not validating is that we will send SIGQUIT to that pid even if it?s not a java process, but it?s the same behavior as JDK 8. The regression was introduced by https://bugs.openjdk.java.net/browse/JDK-8156537 VirtualMachineDescriptor was not easily create-able from just a string pid, you need an AttachProvider. I instead change so we use a collection of pids where applicable. Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 Passes jdk/test/sun/tools/ and internal test group. Manual tested the regression case. A new issue for the AttachProvider will be filed. Thanks /Robbin From serguei.spitsyn at oracle.com Wed Mar 15 18:14:16 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Mar 2017 11:14:16 -0700 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> Message-ID: <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> Hi Robbin, Nice fix. Thank you for taking care about this issue so quickly! One minor comment below. http://cr.openjdk.java.net/~rehn/8176533/webrev/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java.udiff.html A typo in the comment: debugge-suspened => debuggee-suspened On 3/15/17 10:41, Robbin Ehn wrote: > Hi all, please review: > > When starting the VM with agentlib and suspended, > jcmd/jinfo/jstack/jmap don't work until a debugger have attach. > > There is an underlying issue with AttachProvider that don't list that > VM even if it's attachable. > That issue is present in JDK 8 (?jcmd -l? don?t list this process). > > This fix only fixes the regression by not validating the pid against > available VirtualMachineDescriptors. > One problem with not validating is that we will send SIGQUIT to that > pid even if it?s not a java process, but it?s the same behavior as JDK 8. > > The regression was introduced by > https://bugs.openjdk.java.net/browse/JDK-8156537 > > VirtualMachineDescriptor was not easily create-able from just a string > pid, you need an AttachProvider. > I instead change so we use a collection of pids where applicable. > > Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 > > Passes jdk/test/sun/tools/ and internal test group. > Manual tested the regression case. > > A new issue for the AttachProvider will be filed. I've filed this one: https://bugs.openjdk.java.net/browse/JDK-8176828 jtools do not list VM process launched with the debugger option suspend=y Feel free to update it if necessary. Thanks, Serguei > > Thanks > > /Robbin From dmitry.samersoff at oracle.com Wed Mar 15 18:14:42 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Mar 2017 21:14:42 +0300 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> Message-ID: <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> Robbin, Looks good to me. -Dmitry On 2017-03-15 20:41, Robbin Ehn wrote: > Hi all, please review: > > When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap > don't work until a debugger have attach. > > There is an underlying issue with AttachProvider that don't list that VM > even if it's attachable. > That issue is present in JDK 8 (?jcmd -l? don?t list this process). > > This fix only fixes the regression by not validating the pid against > available VirtualMachineDescriptors. > One problem with not validating is that we will send SIGQUIT to that pid > even if it?s not a java process, but it?s the same behavior as JDK 8. > > The regression was introduced by > https://bugs.openjdk.java.net/browse/JDK-8156537 > > VirtualMachineDescriptor was not easily create-able from just a string > pid, you need an AttachProvider. > I instead change so we use a collection of pids where applicable. > > Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 > > Passes jdk/test/sun/tools/ and internal test group. > Manual tested the regression case. > > A new issue for the AttachProvider will be filed. > > Thanks > > /Robbin -- 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 igor.ignatyev at oracle.com Wed Mar 15 18:16:47 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 15 Mar 2017 11:16:47 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> Message-ID: Shura, Thank you for your review. I have update test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked that there are no similar things in other TEST.properties files. Still looking for a review from a Reviewer. [1] > --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon Mar 13 18:54:58 2017 -0700 > +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed Mar 15 11:09:06 2017 -0700 > @@ -1,3 +1,2 @@ > -modules = java.management \ > - java.logging > +modules = java.logging Thanks, ? Igor > On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline wrote: > > Igor, > > I have looked through a bunch of tests where @modules is changed - that looks good. > > One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because ?modules? property is concatenated through the hierarchy. java.management is already listed in test/java/lang/management/TEST.properties. > > Shura > >> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev wrote: >> >> Shura, >> >> Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. >> >> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html >> >> Thanks, >> ? Igor >> >>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: >>> >>> Igor, >>> >>> I have reviewed some number tests which change the @modules - they are fine. >>> >>> You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? >>> >>> Shura >>> >>> [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html >>> [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html >>> >>>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >>>> >>>> Hi all, >>>> >>>> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >>>> there are a couple issues w/ modules in jdk_svc tests: >>>> - some tests do not specify modules which they depend on >>>> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >>>> - @modules directive isn't placed according to current convention (before the 1st run directive) >>>> >>>> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >>>> >>>> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >>>> >>>> There are two one-liners which, I hope, can simplify review: >>>> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >>>> test/com/sun/jdi/ArgumentValuesTest.java >>>> test/com/sun/jdi/BreakpointTest.java >>>> test/com/sun/jdi/FetchLocals.java >>>> test/com/sun/jdi/GetLocalVariables.java >>>> test/com/sun/jdi/GetSetLocalTest.java >>>> test/com/sun/jdi/LambdaBreakpointTest.java >>>> test/com/sun/jdi/LineNumberOnBraceTest.java >>>> test/com/sun/jdi/PopAndStepTest.java >>>> >>>> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >>>> Testing: >>>> - jdk_svc on linux, windows, mac >>>> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >>>> >>>> Thanks, >>>> ? Igor >>>> >>>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >>>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" >>> >> > From david.holmes at oracle.com Wed Mar 15 21:23:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Mar 2017 07:23:39 +1000 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> Message-ID: <94d546e3-5804-9d0a-a2a3-06252d2a74a4@oracle.com> On 16/03/2017 4:14 AM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > Nice fix. > Thank you for taking care about this issue so quickly! > > One minor comment below. > > http://cr.openjdk.java.net/~rehn/8176533/webrev/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java.udiff.html > > > A typo in the comment: debugge-suspened => debuggee-suspened typo: suspened -> suspended Not a review :) David > > > On 3/15/17 10:41, Robbin Ehn wrote: >> Hi all, please review: >> >> When starting the VM with agentlib and suspended, >> jcmd/jinfo/jstack/jmap don't work until a debugger have attach. >> >> There is an underlying issue with AttachProvider that don't list that >> VM even if it's attachable. >> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >> >> This fix only fixes the regression by not validating the pid against >> available VirtualMachineDescriptors. >> One problem with not validating is that we will send SIGQUIT to that >> pid even if it?s not a java process, but it?s the same behavior as JDK 8. >> >> The regression was introduced by >> https://bugs.openjdk.java.net/browse/JDK-8156537 >> >> VirtualMachineDescriptor was not easily create-able from just a string >> pid, you need an AttachProvider. >> I instead change so we use a collection of pids where applicable. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >> >> Passes jdk/test/sun/tools/ and internal test group. >> Manual tested the regression case. >> >> A new issue for the AttachProvider will be filed. > > I've filed this one: > https://bugs.openjdk.java.net/browse/JDK-8176828 > jtools do not list VM process launched with the debugger option > suspend=y > > Feel free to update it if necessary. > > Thanks, > Serguei > >> >> Thanks >> >> /Robbin > From serguei.spitsyn at oracle.com Wed Mar 15 21:27:08 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Mar 2017 14:27:08 -0700 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <94d546e3-5804-9d0a-a2a3-06252d2a74a4@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> <94d546e3-5804-9d0a-a2a3-06252d2a74a4@oracle.com> Message-ID: <61bf2dc6-a38b-9fa6-48d4-8c049473a400@oracle.com> On 3/15/17 14:23, David Holmes wrote: > On 16/03/2017 4:14 AM, serguei.spitsyn at oracle.com wrote: >> Hi Robbin, >> >> Nice fix. >> Thank you for taking care about this issue so quickly! >> >> One minor comment below. >> >> http://cr.openjdk.java.net/~rehn/8176533/webrev/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java.udiff.html >> >> >> >> A typo in the comment: debugge-suspened => debuggee-suspened > > typo: suspened -> suspended It is funny, I've overlooked it. :) Thanks, Serguei > > Not a review :) > > David > >> >> >> On 3/15/17 10:41, Robbin Ehn wrote: >>> Hi all, please review: >>> >>> When starting the VM with agentlib and suspended, >>> jcmd/jinfo/jstack/jmap don't work until a debugger have attach. >>> >>> There is an underlying issue with AttachProvider that don't list that >>> VM even if it's attachable. >>> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >>> >>> This fix only fixes the regression by not validating the pid against >>> available VirtualMachineDescriptors. >>> One problem with not validating is that we will send SIGQUIT to that >>> pid even if it?s not a java process, but it?s the same behavior as >>> JDK 8. >>> >>> The regression was introduced by >>> https://bugs.openjdk.java.net/browse/JDK-8156537 >>> >>> VirtualMachineDescriptor was not easily create-able from just a string >>> pid, you need an AttachProvider. >>> I instead change so we use a collection of pids where applicable. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >>> >>> Passes jdk/test/sun/tools/ and internal test group. >>> Manual tested the regression case. >>> >>> A new issue for the AttachProvider will be filed. >> >> I've filed this one: >> https://bugs.openjdk.java.net/browse/JDK-8176828 >> jtools do not list VM process launched with the debugger option >> suspend=y >> >> Feel free to update it if necessary. >> >> Thanks, >> Serguei >> >>> >>> Thanks >>> >>> /Robbin >> From serguei.spitsyn at oracle.com Thu Mar 16 04:05:59 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Mar 2017 21:05:59 -0700 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> Message-ID: Hi Robbin, You have two reviews now, so it is Ok to push assuming the testing is good. Please, let us know if anything else is needed. It seems, today is the last day before an approval will be required for a push. Thanks, Serguei On 3/15/17 11:14, Dmitry Samersoff wrote: > Robbin, > > Looks good to me. > > -Dmitry > > On 2017-03-15 20:41, Robbin Ehn wrote: >> Hi all, please review: >> >> When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap >> don't work until a debugger have attach. >> >> There is an underlying issue with AttachProvider that don't list that VM >> even if it's attachable. >> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >> >> This fix only fixes the regression by not validating the pid against >> available VirtualMachineDescriptors. >> One problem with not validating is that we will send SIGQUIT to that pid >> even if it?s not a java process, but it?s the same behavior as JDK 8. >> >> The regression was introduced by >> https://bugs.openjdk.java.net/browse/JDK-8156537 >> >> VirtualMachineDescriptor was not easily create-able from just a string >> pid, you need an AttachProvider. >> I instead change so we use a collection of pids where applicable. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >> >> Passes jdk/test/sun/tools/ and internal test group. >> Manual tested the regression case. >> >> A new issue for the AttachProvider will be filed. >> >> Thanks >> >> /Robbin > From serguei.spitsyn at oracle.com Thu Mar 16 04:53:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Mar 2017 21:53:12 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> Message-ID: <0b813bb0-4dab-24f1-0d02-8e2bc760bd79@oracle.com> Hi Igor, This looks good to me. A couple of questions below. http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html - * @modules jdk.jdi * @library /test/lib + * @modules java.management + * jdk.jdi Should the jdk.jdi be removed from this com/sun/jdi test? http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/RedefineCrossEvent.java.udiff.html * @modules java.corba * jdk.jdi Should the jdk.jdi be removed from this com/sun/jdi test? Thanks, Serguei On 3/15/17 11:16, Igor Ignatyev wrote: > Shura, > > Thank you for your review. I have update test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked that there are no similar things in other TEST.properties files. > > Still looking for a review from a Reviewer. > > [1] >> --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon Mar 13 18:54:58 2017 -0700 >> +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed Mar 15 11:09:06 2017 -0700 >> @@ -1,3 +1,2 @@ >> -modules = java.management \ >> - java.logging >> +modules = java.logging > > Thanks, > ? Igor > >> On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline wrote: >> >> Igor, >> >> I have looked through a bunch of tests where @modules is changed - that looks good. >> >> One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because ?modules? property is concatenated through the hierarchy. java.management is already listed in test/java/lang/management/TEST.properties. >> >> Shura >> >>> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev wrote: >>> >>> Shura, >>> >>> Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. >>> >>> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html >>> >>> Thanks, >>> ? Igor >>> >>>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: >>>> >>>> Igor, >>>> >>>> I have reviewed some number tests which change the @modules - they are fine. >>>> >>>> You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? >>>> >>>> Shura >>>> >>>> [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html >>>> [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html >>>> >>>>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >>>>> Hi all, >>>>> >>>>> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >>>>> there are a couple issues w/ modules in jdk_svc tests: >>>>> - some tests do not specify modules which they depend on >>>>> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >>>>> - @modules directive isn't placed according to current convention (before the 1st run directive) >>>>> >>>>> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >>>>> >>>>> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >>>>> >>>>> There are two one-liners which, I hope, can simplify review: >>>>> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >>>>> test/com/sun/jdi/ArgumentValuesTest.java >>>>> test/com/sun/jdi/BreakpointTest.java >>>>> test/com/sun/jdi/FetchLocals.java >>>>> test/com/sun/jdi/GetLocalVariables.java >>>>> test/com/sun/jdi/GetSetLocalTest.java >>>>> test/com/sun/jdi/LambdaBreakpointTest.java >>>>> test/com/sun/jdi/LineNumberOnBraceTest.java >>>>> test/com/sun/jdi/PopAndStepTest.java >>>>> >>>>> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >>>>> Testing: >>>>> - jdk_svc on linux, windows, mac >>>>> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>>>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >>>>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" From igor.ignatyev at oracle.com Thu Mar 16 05:07:23 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 15 Mar 2017 22:07:23 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: <0b813bb0-4dab-24f1-0d02-8e2bc760bd79@oracle.com> References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> <0b813bb0-4dab-24f1-0d02-8e2bc760bd79@oracle.com> Message-ID: <90416899-36EF-46FC-AEED-699B5BE7D968@oracle.com> Hi Serguei, 1s of all, thank you for your review. since these tests have dependencies on more modules than corresponding TEST.properties file declares, we have to specify @modules tag in them, and because @modules in a test overrides modules from TEST.properties, jdk.jdi module should be mentioned in the tests. ? Igor > On Mar 15, 2017, at 9:53 PM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > This looks good to me. > A couple of questions below. > > > http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html > > - * @modules jdk.jdi > * @library /test/lib > + * @modules java.management > + * jdk.jdi Should the jdk.jdi be removed from this com/sun/jdi test? > > > http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/RedefineCrossEvent.java.udiff.html > > * @modules java.corba > * jdk.jdi > > Should the jdk.jdi be removed from this com/sun/jdi test? > > > Thanks, > Serguei > > > On 3/15/17 11:16, Igor Ignatyev wrote: >> Shura, >> >> Thank you for your review. I have update test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked that there are no similar things in other TEST.properties files. >> >> Still looking for a review from a Reviewer. >> >> [1] >>> --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon Mar 13 18:54:58 2017 -0700 >>> +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed Mar 15 11:09:06 2017 -0700 >>> @@ -1,3 +1,2 @@ >>> -modules = java.management \ >>> - java.logging >>> +modules = java.logging >> >> Thanks, >> ? Igor >> >>> On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline wrote: >>> >>> Igor, >>> >>> I have looked through a bunch of tests where @modules is changed - that looks good. >>> >>> One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because ?modules? property is concatenated through the hierarchy. java.management is already listed in test/java/lang/management/TEST.properties. >>> >>> Shura >>> >>>> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev wrote: >>>> >>>> Shura, >>>> >>>> Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. >>>> >>>> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html >>>> >>>> Thanks, >>>> ? Igor >>>> >>>>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: >>>>> >>>>> Igor, >>>>> >>>>> I have reviewed some number tests which change the @modules - they are fine. >>>>> >>>>> You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? >>>>> >>>>> Shura >>>>> >>>>> [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html >>>>> [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html >>>>> >>>>>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>>>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >>>>>> Hi all, >>>>>> >>>>>> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >>>>>> there are a couple issues w/ modules in jdk_svc tests: >>>>>> - some tests do not specify modules which they depend on >>>>>> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >>>>>> - @modules directive isn't placed according to current convention (before the 1st run directive) >>>>>> >>>>>> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >>>>>> >>>>>> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >>>>>> >>>>>> There are two one-liners which, I hope, can simplify review: >>>>>> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >>>>>> test/com/sun/jdi/ArgumentValuesTest.java >>>>>> test/com/sun/jdi/BreakpointTest.java >>>>>> test/com/sun/jdi/FetchLocals.java >>>>>> test/com/sun/jdi/GetLocalVariables.java >>>>>> test/com/sun/jdi/GetSetLocalTest.java >>>>>> test/com/sun/jdi/LambdaBreakpointTest.java >>>>>> test/com/sun/jdi/LineNumberOnBraceTest.java >>>>>> test/com/sun/jdi/PopAndStepTest.java >>>>>> >>>>>> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >>>>>> Testing: >>>>>> - jdk_svc on linux, windows, mac >>>>>> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >>>>>> >>>>>> Thanks, >>>>>> ? Igor >>>>>> >>>>>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >>>>>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" > From serguei.spitsyn at oracle.com Thu Mar 16 05:10:21 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Mar 2017 22:10:21 -0700 Subject: RFR(L) : 8176176 : fix @modules in jdk_svc tests In-Reply-To: <90416899-36EF-46FC-AEED-699B5BE7D968@oracle.com> References: <9C07C5F8-9556-41E6-925C-B90D59FB3DB8@oracle.com> <356DB35F-4D93-4A1F-91ED-F08C15BD0E75@oracle.com> <84F66D3E-48DE-4930-9E85-B83232A2BAEF@oracle.com> <0b813bb0-4dab-24f1-0d02-8e2bc760bd79@oracle.com> <90416899-36EF-46FC-AEED-699B5BE7D968@oracle.com> Message-ID: Igor, It was my guess but it is nice to have it explicitly explained. Thanks! Serguei On 3/15/17 22:07, Igor Ignatyev wrote: > Hi Serguei, > > 1s of all, thank you for your review. > > since these tests have dependencies on more modules than corresponding TEST.properties file declares, we have to specify @modules tag in them, and because @modules in a test overrides modules from TEST.properties, jdk.jdi module should be mentioned in the tests. > > ? Igor > >> On Mar 15, 2017, at 9:53 PM, serguei.spitsyn at oracle.com wrote: >> >> Hi Igor, >> >> This looks good to me. >> A couple of questions below. >> >> >> http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html >> >> - * @modules jdk.jdi >> * @library /test/lib >> + * @modules java.management >> + * jdk.jdi Should the jdk.jdi be removed from this com/sun/jdi test? >> >> >> http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/RedefineCrossEvent.java.udiff.html >> >> * @modules java.corba >> * jdk.jdi >> >> Should the jdk.jdi be removed from this com/sun/jdi test? >> >> >> Thanks, >> Serguei >> >> >> On 3/15/17 11:16, Igor Ignatyev wrote: >>> Shura, >>> >>> Thank you for your review. I have update test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked that there are no similar things in other TEST.properties files. >>> >>> Still looking for a review from a Reviewer. >>> >>> [1] >>>> --- a/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Mon Mar 13 18:54:58 2017 -0700 >>>> +++ b/test/java/lang/management/PlatformLoggingMXBean/TEST.properties Wed Mar 15 11:09:06 2017 -0700 >>>> @@ -1,3 +1,2 @@ >>>> -modules = java.management \ >>>> - java.logging >>>> +modules = java.logging >>> Thanks, >>> ? Igor >>> >>>> On Mar 15, 2017, at 9:56 AM, Alexandre (Shura) Iline wrote: >>>> >>>> Igor, >>>> >>>> I have looked through a bunch of tests where @modules is changed - that looks good. >>>> >>>> One minor thing I noticed is that, in test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are explicitly calling out java.management. You do not have to do that because ?modules? property is concatenated through the hierarchy. java.management is already listed in test/java/lang/management/TEST.properties. >>>> >>>> Shura >>>> >>>>> On Mar 13, 2017, at 9:03 PM, Igor Ignatyev wrote: >>>>> >>>>> Shura, >>>>> >>>>> Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. >>>>> >>>>> [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>>>>> On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline wrote: >>>>>> >>>>>> Igor, >>>>>> >>>>>> I have reviewed some number tests which change the @modules - they are fine. >>>>>> >>>>>> You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? >>>>>> >>>>>> Shura >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArgumentValuesTest.java.sdiff.html >>>>>> [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/ArrayLengthDumpTest.sh.sdiff.html >>>>>> >>>>>>> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>>>>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >>>>>>> there are a couple issues w/ modules in jdk_svc tests: >>>>>>> - some tests do not specify modules which they depend on >>>>>>> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >>>>>>> - @modules directive isn't placed according to current convention (before the 1st run directive) >>>>>>> >>>>>>> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won?t be two massive updates in the tests. >>>>>>> >>>>>>> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >>>>>>> >>>>>>> There are two one-liners which, I hope, can simplify review: >>>>>>> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >>>>>>> test/com/sun/jdi/ArgumentValuesTest.java >>>>>>> test/com/sun/jdi/BreakpointTest.java >>>>>>> test/com/sun/jdi/FetchLocals.java >>>>>>> test/com/sun/jdi/GetLocalVariables.java >>>>>>> test/com/sun/jdi/GetSetLocalTest.java >>>>>>> test/com/sun/jdi/LambdaBreakpointTest.java >>>>>>> test/com/sun/jdi/LineNumberOnBraceTest.java >>>>>>> test/com/sun/jdi/PopAndStepTest.java >>>>>>> >>>>>>> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >>>>>>> Testing: >>>>>>> - jdk_svc on linux, windows, mac >>>>>>> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >>>>>>> >>>>>>> Thanks, >>>>>>> ? Igor >>>>>>> >>>>>>> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >>>>>>> [2] $ hg diff -w | grep -e "^\(+++ b\)\|\(--- a\)" -e "^[+-]\s*[*#]\s*@" From robbin.ehn at oracle.com Thu Mar 16 06:09:50 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Mar 2017 07:09:50 +0100 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> Message-ID: <253f078c-3724-a6d7-1fc5-a6c9ba9a2864@oracle.com> Thanks Serguei! On 03/15/2017 07:14 PM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > Nice fix. > Thank you for taking care about this issue so quickly! > > One minor comment below. > > http://cr.openjdk.java.net/~rehn/8176533/webrev/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java.udiff.html > > A typo in the comment: debugge-suspened => debuggee-suspened Yes. /Robbin > > > > On 3/15/17 10:41, Robbin Ehn wrote: >> Hi all, please review: >> >> When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap don't work until a debugger have attach. >> >> There is an underlying issue with AttachProvider that don't list that VM even if it's attachable. >> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >> >> This fix only fixes the regression by not validating the pid against available VirtualMachineDescriptors. >> One problem with not validating is that we will send SIGQUIT to that pid even if it?s not a java process, but it?s the same behavior as JDK 8. >> >> The regression was introduced by https://bugs.openjdk.java.net/browse/JDK-8156537 >> >> VirtualMachineDescriptor was not easily create-able from just a string pid, you need an AttachProvider. >> I instead change so we use a collection of pids where applicable. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >> >> Passes jdk/test/sun/tools/ and internal test group. >> Manual tested the regression case. >> >> A new issue for the AttachProvider will be filed. > > I've filed this one: > https://bugs.openjdk.java.net/browse/JDK-8176828 > jtools do not list VM process launched with the debugger option suspend=y > > Feel free to update it if necessary. > > Thanks, > Serguei > >> >> Thanks >> >> /Robbin > From robbin.ehn at oracle.com Thu Mar 16 06:10:33 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Mar 2017 07:10:33 +0100 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> Message-ID: Thanks for looking at this so quickly Dmitry! /Robbin On 03/15/2017 07:14 PM, Dmitry Samersoff wrote: > Robbin, > > Looks good to me. > > -Dmitry > > On 2017-03-15 20:41, Robbin Ehn wrote: >> Hi all, please review: >> >> When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap >> don't work until a debugger have attach. >> >> There is an underlying issue with AttachProvider that don't list that VM >> even if it's attachable. >> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >> >> This fix only fixes the regression by not validating the pid against >> available VirtualMachineDescriptors. >> One problem with not validating is that we will send SIGQUIT to that pid >> even if it?s not a java process, but it?s the same behavior as JDK 8. >> >> The regression was introduced by >> https://bugs.openjdk.java.net/browse/JDK-8156537 >> >> VirtualMachineDescriptor was not easily create-able from just a string >> pid, you need an AttachProvider. >> I instead change so we use a collection of pids where applicable. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >> >> Passes jdk/test/sun/tools/ and internal test group. >> Manual tested the regression case. >> >> A new issue for the AttachProvider will be filed. >> >> Thanks >> >> /Robbin > > From robbin.ehn at oracle.com Thu Mar 16 06:11:36 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Mar 2017 07:11:36 +0100 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: <94d546e3-5804-9d0a-a2a3-06252d2a74a4@oracle.com> References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <78a3d1f0-b6e7-eaab-da49-68a9416da454@oracle.com> <94d546e3-5804-9d0a-a2a3-06252d2a74a4@oracle.com> Message-ID: Hi David, On 03/15/2017 10:23 PM, David Holmes wrote: > On 16/03/2017 4:14 AM, serguei.spitsyn at oracle.com wrote: >> Hi Robbin, >> >> Nice fix. >> Thank you for taking care about this issue so quickly! >> >> One minor comment below. >> >> http://cr.openjdk.java.net/~rehn/8176533/webrev/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java.udiff.html >> >> >> A typo in the comment: debugge-suspened => debuggee-suspened > > typo: suspened -> suspended :) /Robbin > > Not a review :) > > David > >> >> >> On 3/15/17 10:41, Robbin Ehn wrote: >>> Hi all, please review: >>> >>> When starting the VM with agentlib and suspended, >>> jcmd/jinfo/jstack/jmap don't work until a debugger have attach. >>> >>> There is an underlying issue with AttachProvider that don't list that >>> VM even if it's attachable. >>> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >>> >>> This fix only fixes the regression by not validating the pid against >>> available VirtualMachineDescriptors. >>> One problem with not validating is that we will send SIGQUIT to that >>> pid even if it?s not a java process, but it?s the same behavior as JDK 8. >>> >>> The regression was introduced by >>> https://bugs.openjdk.java.net/browse/JDK-8156537 >>> >>> VirtualMachineDescriptor was not easily create-able from just a string >>> pid, you need an AttachProvider. >>> I instead change so we use a collection of pids where applicable. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >>> >>> Passes jdk/test/sun/tools/ and internal test group. >>> Manual tested the regression case. >>> >>> A new issue for the AttachProvider will be filed. >> >> I've filed this one: >> https://bugs.openjdk.java.net/browse/JDK-8176828 >> jtools do not list VM process launched with the debugger option >> suspend=y >> >> Feel free to update it if necessary. >> >> Thanks, >> Serguei >> >>> >>> Thanks >>> >>> /Robbin >> From robbin.ehn at oracle.com Thu Mar 16 06:12:46 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Mar 2017 07:12:46 +0100 Subject: RFR(9): 8176533: REGRESSION: a java process is not recognized by jcmd/jinfo/jstack/jmap tool In-Reply-To: References: <2c130ee5-3400-52eb-4966-abef366e8f3d@oracle.com> <63cecfc9-c4d5-4df7-c2d5-f9842ca605a0@oracle.com> Message-ID: Hi Serguei, On 03/16/2017 05:05 AM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > You have two reviews now, so it is Ok to push assuming the testing is good. > Please, let us know if anything else is needed. Yes thanks! > > It seems, today is the last day before an approval will be required for a push. Will push today! /Robbin > > Thanks, > Serguei > > > > On 3/15/17 11:14, Dmitry Samersoff wrote: >> Robbin, >> >> Looks good to me. >> >> -Dmitry >> >> On 2017-03-15 20:41, Robbin Ehn wrote: >>> Hi all, please review: >>> >>> When starting the VM with agentlib and suspended, jcmd/jinfo/jstack/jmap >>> don't work until a debugger have attach. >>> >>> There is an underlying issue with AttachProvider that don't list that VM >>> even if it's attachable. >>> That issue is present in JDK 8 (?jcmd -l? don?t list this process). >>> >>> This fix only fixes the regression by not validating the pid against >>> available VirtualMachineDescriptors. >>> One problem with not validating is that we will send SIGQUIT to that pid >>> even if it?s not a java process, but it?s the same behavior as JDK 8. >>> >>> The regression was introduced by >>> https://bugs.openjdk.java.net/browse/JDK-8156537 >>> >>> VirtualMachineDescriptor was not easily create-able from just a string >>> pid, you need an AttachProvider. >>> I instead change so we use a collection of pids where applicable. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8176533/webrev/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8176533 >>> >>> Passes jdk/test/sun/tools/ and internal test group. >>> Manual tested the regression case. >>> >>> A new issue for the AttachProvider will be filed. >>> >>> Thanks >>> >>> /Robbin >> > From robbin.ehn at oracle.com Thu Mar 16 12:59:02 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Mar 2017 13:59:02 +0100 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> Message-ID: <320d4094-b65a-3f59-2324-b53d86161e9c@oracle.com> Hi Dmitry, thanks for the update. One follow-up issue is that if you start suspended and than connect with an unallowed client the JVM starts and executes the program. Simple program prints "Hello". [rehn at rehn-ws vanilla-hs]$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:9999,allow=1.2.3.0/32 -cp . H Listening for transport dt_socket at address: 9999 ERROR: Peer not allowed to connect Listening for transport dt_socket at address: 9999 Hello I think it would be good if the VM stayed suspended when an unallowed client connects. Thanks, Robbin On 03/13/2017 08:07 PM, Dmitry Samersoff wrote: > Robbin, > > Please, see: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.11 > >> 1: >> So connecting with an unallowed client terminates the VM. > > Fixed. > >> 2: >> Starting with an bad allow filter terminates the VM when connecting a >> client. > > Moved allowed parameter (and parser call) to StartListening. > > -Dmitry > > > On 2017-03-10 15:56, Robbin Ehn wrote: >> Hi Dmitry, >> >> I took a look at this, I have two practical issues: >> >> 1: >> [rehn at rehn-ws dev]$ java >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 >> -cp runs ForEver >> Listening for transport dt_socket at address: 9999 >> ERROR: transport error 202: peer not allowed to connect: Success >> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >> error [transport.c:358] >> >> So connecting with an unallowed client terminates the VM. >> >> 2: >> [rehn at rehn-ws dev]$ java >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 >> -cp runs ForEver >> Listening for transport dt_socket at address: 9999 >> ERROR: transport error 202: unable to parse list of allowed peers: Success >> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >> error [transport.c:358] >> >> Starting with an bad allow filter terminates the VM when connecting a >> client. >> >> >> Connecting with an unallowed ip/port should not terminate the VM and we >> should verify allow filter directly at startup. >> >> Thanks >> >> /Robbin >> >> On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >>> >>> These changes introduce new parameter[1] of the socket transport - >>> allow. Users can explicitly specify a list of hosts that allowed to >>> connect to jdwp server and it's the second part of JDWP hardening[2]. >>> >>> No restrictions are applied by default now but I'll file a separate CR >>> to restrict list of allowed peers to localhost by default. >>> >>> Also these changes implement versioning for jdwp transport and therefor >>> simplify feature development of jdwp. >>> >>> >>> 1. Example command line: >>> >>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>> address=*,allow="127.0.0.0/8;192.168.0.0/24" >>> >>> Possible values for allow parameter: >>> * - accept connections from everywhere. >>> N.N.N.N - accept connections from this IP address only >>> N.N.N.N/nn - accept connections from particular ip subnet >>> >>> >>> >>> 2. JDK-8052136 JDWP hardening >>> >>> -Dmitry >>> > > From serguei.spitsyn at oracle.com Fri Mar 17 00:59:40 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Mar 2017 17:59:40 -0700 Subject: RFR (S): 8176831: Dead code: function jmm_GetLoadedClasses is not used in jmm_interface Message-ID: <84f65d92-d937-deef-827a-cbc30a03f3e1@oracle.com> Please, review the jdk 10 fix for: https://bugs.openjdk.java.net/browse/JDK-8176831 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8176831-jmm-dead.1/ Summary: It was found at the review of the 8155672 that the function jmm_GetLoadedClasses() defined in services/management.cpp is not really used in the jmm_interface. This function and dead code associated with its implementation is removed. Testing: The nsk.monitoring and jtreg jdk_management tests are in progress. Thanks, Serguei From david.holmes at oracle.com Fri Mar 17 01:15:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Mar 2017 11:15:21 +1000 Subject: RFR (S): 8176831: Dead code: function jmm_GetLoadedClasses is not used in jmm_interface In-Reply-To: <84f65d92-d937-deef-827a-cbc30a03f3e1@oracle.com> References: <84f65d92-d937-deef-827a-cbc30a03f3e1@oracle.com> Message-ID: Looks good! Don't forget to update copyright years. Thanks, David On 17/03/2017 10:59 AM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 10 fix for: > https://bugs.openjdk.java.net/browse/JDK-8176831 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8176831-jmm-dead.1/ > > > > Summary: > > It was found at the review of the 8155672 that the function > jmm_GetLoadedClasses() defined in services/management.cpp > is not really used in the jmm_interface. This function and > dead code associated with its implementation is removed. > > Testing: > The nsk.monitoring and jtreg jdk_management tests are in progress. > > > Thanks, > Serguei > > > > From serguei.spitsyn at oracle.com Fri Mar 17 01:20:42 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Mar 2017 18:20:42 -0700 Subject: RFR (S): 8176831: Dead code: function jmm_GetLoadedClasses is not used in jmm_interface In-Reply-To: References: <84f65d92-d937-deef-827a-cbc30a03f3e1@oracle.com> Message-ID: <480b2c46-c094-de6e-2b90-05b90b3ea783@oracle.com> David, Thank you for the review! On 3/16/17 18:15, David Holmes wrote: > Looks good! > > Don't forget to update copyright years. Yes, of course. Thanks, Serguei > > Thanks, > David > > On 17/03/2017 10:59 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 10 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8176831 >> >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8176831-jmm-dead.1/ >> >> >> >> >> Summary: >> >> It was found at the review of the 8155672 that the function >> jmm_GetLoadedClasses() defined in services/management.cpp >> is not really used in the jmm_interface. This function and >> dead code associated with its implementation is removed. >> >> Testing: >> The nsk.monitoring and jtreg jdk_management tests are in progress. >> >> >> Thanks, >> Serguei >> >> >> >> From serguei.spitsyn at oracle.com Fri Mar 17 01:38:14 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Mar 2017 18:38:14 -0700 Subject: RFR (S): 8176831: Dead code: function jmm_GetLoadedClasses is not used in jmm_interface In-Reply-To: <480b2c46-c094-de6e-2b90-05b90b3ea783@oracle.com> References: <84f65d92-d937-deef-827a-cbc30a03f3e1@oracle.com> <480b2c46-c094-de6e-2b90-05b90b3ea783@oracle.com> Message-ID: <0b347619-f5f7-4804-ab3a-1cbb7871be0e@oracle.com> I've reloaded the webrev with pulled latest jdk10 changes. It looks almost the same but has the recent update from Coleen. Thanks, Serguei On 3/16/17 18:20, serguei.spitsyn at oracle.com wrote: > David, > > Thank you for the review! > > > On 3/16/17 18:15, David Holmes wrote: >> Looks good! >> >> Don't forget to update copyright years. > > Yes, of course. > > > Thanks, > Serguei >> >> Thanks, >> David >> >> On 17/03/2017 10:59 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 10 fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8176831 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8176831-jmm-dead.1/ >>> >>> >>> >>> >>> Summary: >>> >>> It was found at the review of the 8155672 that the function >>> jmm_GetLoadedClasses() defined in services/management.cpp >>> is not really used in the jmm_interface. This function and >>> dead code associated with its implementation is removed. >>> >>> Testing: >>> The nsk.monitoring and jtreg jdk_management tests are in progress. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> > From serguei.spitsyn at oracle.com Fri Mar 17 07:03:48 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Mar 2017 00:03:48 -0700 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <09941e94-e755-0318-04fa-19117eb14195@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> <09941e94-e755-0318-04fa-19117eb14195@oracle.com> Message-ID: <48211785-ef73-2a12-d449-813ea796bc66@oracle.com> Hi Dmitry, On 3/15/17 00:56, Dmitry Samersoff wrote: > Serguei, > >> I still see the C .vs. C++ related change in the jdwpTransport.h. > done. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/ Good. Thank you for the update! > > see also inline. > > On 2017-03-15 00:40, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> We already had a big review thread back in 2014 on this. >> I think, it is again going in the wrong order. >> >> First, I think, it is better to start from a CCC (or its equivalent, CSR). >> This will allow to focus on and sort out the changes in interface/behavior >> first before going into the implementation details. > CCC was filed and approved. The only reason I withdraw it - the fix > didn't go to jdk9 but CCC tool doesn't have jdk10. > > CSR process is also not yet implemented. The CSR preview message from Joe is attached. My understanding is that we can continue to use CCC. At some points the CCC process will be moved to the CSR. The CCC is out of date now as it does not match the webrev 12. Also, I do not like the addition of new function StartListening11() next to StartListening(). Does it mean, that for transport version 1.2 we might have more function clones with 12 suffix? Perhaps, we need something smarter here but I'm unsure yet what it has to be. >> Second, I'd suggest to separate a couple of other things. >> I still see the C .vs. C++ related change in the jdwpTransport.h. >> It is better to leave it along for now as it was suggested in early >> review rounds. >> If you still want to fix it then it is better to file a separate bug that >> should include the JNI as well (as it was discussed with Alan before). > Do you mean? > > 39 #ifdef __cplusplus > 40 extern "C" { > 41 #endif > > I'll add it back to avoid any confusion. Yes. I see you added it back in new version of webrev. > >> Also, I'm thinking if it is a good idea to separate the transport >> versioning to an RFE. >> It would allow to focus on this aspect as necessary. >> In this case, the 8061228 will depend on the versioning. >> However, it is much more simple and can be resolved faster. > It's hard to test versioning code without implementation of > new, VERSION_1_1 transport. > > Network part of 8061228 is simple and clear separated from versioning, > so I would prefer to keep it together in one CR/one push. No pressure. I've got your point above. Thanks, Serguei > > Restriction turned off by default (I'll file separate CR to enable it > later), so we have enough time to fix any issues that might come. > > -Dmitry > >> >> Thanks, >> Serguei >> >> >> On 2/28/17 01:41, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >>> >>> These changes introduce new parameter[1] of the socket transport - >>> allow. Users can explicitly specify a list of hosts that allowed to >>> connect to jdwp server and it's the second part of JDWP hardening[2]. >>> >>> No restrictions are applied by default now but I'll file a separate CR >>> to restrict list of allowed peers to localhost by default. >>> >>> Also these changes implement versioning for jdwp transport and therefor >>> simplify feature development of jdwp. >>> >>> >>> 1. Example command line: >>> >>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>> address=*,allow="127.0.0.0/8;192.168.0.0/24" >>> >>> Possible values for allow parameter: >>> * - accept connections from everywhere. >>> N.N.N.N - accept connections from this IP address only >>> N.N.N.N/nn - accept connections from particular ip subnet >>> >>> >>> >>> 2. JDK-8052136 JDWP hardening >>> >>> -Dmitry >>> > -------------- next part -------------- An embedded message was scrubbed... From: joe darcy Subject: Preview: the ccc is retiring; long live the csr! Date: Wed, 14 Dec 2016 14:55:42 -0800 Size: 38862 URL: From serguei.spitsyn at oracle.com Fri Mar 17 09:20:23 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Mar 2017 02:20:23 -0700 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <48211785-ef73-2a12-d449-813ea796bc66@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> <09941e94-e755-0318-04fa-19117eb14195@oracle.com> <48211785-ef73-2a12-d449-813ea796bc66@oracle.com> Message-ID: <69f44e02-2690-5643-a5d8-f982a6eac3d2@oracle.com> Dmitry, Some quick comments on the webrev.12. The style of comments must be /* */, not //. http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/src/jdk.jdwp.agent/share/native/libjdwp/transport.c.frames.html 205 // Pass MAXIMAL supported version, expect actual transport version in Would it better to replace 'MAXIMAL' with 'the latest' ? 516 // interface version 1.0 doesn't support versioning, so we have to 517 // a use global variable and set the version artifically. 518 // Use (*t)->extra_data->version directly when 1.0 is gone 516: interface => Interface 517: Typo: a use => use 518: Dot is missed at the end. 33 static unsigned transportVersion = JDWPTRANSPORT_VERSION_1_0; ... 207 ver = (*onLoad)(jvm, &callback, JDWPTRANSPORT_VERSION_1_1, &t); 208 if (ver == JNI_EVERSION) { 209 ver = (*onLoad)(jvm, &callback, JDWPTRANSPORT_VERSION_1_0, &t); 210 // Special handling for versionless transports 211 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; 212 } 213 else { 214 info->transportVersion = (*t)->extra_data->version; 215 } ...263 transportVersion = pTransportVersion; ... 459 info->transportVersion = transportVersion; It is not clear why do you need the static variable transportVersion and this dance with it. It seems, the transport version is always enforced by the TransportOnLoad function anyway. At the line 459, you could just have: 459 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; Thanks, Serguei On 3/17/17 00:03, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, On 3/15/17 00:56, Dmitry Samersoff wrote: >> Serguei, >>> I still see the C .vs. C++ related change in the jdwpTransport.h. >> done. http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/ > Good. Thank you for the update! >> see also inline. On 2017-03-15 00:40, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, We already had a big review thread back in 2014 on this. >>> I think, it is again going in the wrong order. First, I think, it is >>> better to start from a CCC (or its equivalent, CSR). This will allow >>> to focus on and sort out the changes in interface/behavior first >>> before going into the implementation details. >> CCC was filed and approved. The only reason I withdraw it - the fix >> didn't go to jdk9 but CCC tool doesn't have jdk10. CSR process is >> also not yet implemented. > The CSR preview message from Joe is attached. My understanding is that > we can continue to use CCC. At some points the CCC process will be > moved to the CSR. The CCC is out of date now as it does not match the > webrev 12. Also, I do not like the addition of new function > StartListening11() next to StartListening(). Does it mean, that for > transport version 1.2 we might have more function clones with 12 > suffix? Perhaps, we need something smarter here but I'm unsure yet > what it has to be. >>> Second, I'd suggest to separate a couple of other things. I still >>> see the C .vs. C++ related change in the jdwpTransport.h. It is >>> better to leave it along for now as it was suggested in early review >>> rounds. If you still want to fix it then it is better to file a >>> separate bug that should include the JNI as well (as it was >>> discussed with Alan before). >> Do you mean? 39 #ifdef __cplusplus 40 extern "C" { 41 #endif >> I'll add it back to avoid any confusion. > Yes. I see you added it back in new version of webrev. >>> Also, I'm thinking if it is a good idea to separate the transport >>> versioning to an RFE. It would allow to focus on this aspect as >>> necessary. In this case, the 8061228 will depend on the versioning. >>> However, it is much more simple and can be resolved faster. >> It's hard to test versioning code without implementation of new, >> VERSION_1_1 transport. Network part of 8061228 is simple and clear >> separated from versioning, so I would prefer to keep it together in >> one CR/one push. > No pressure. I've got your point above. Thanks, Serguei >> Restriction turned off by default (I'll file separate CR to enable it >> later), so we have enough time to fix any issues that might come. >> -Dmitry >>> Thanks, Serguei On 2/28/17 01:41, Dmitry Samersoff wrote: >>>> Everybody, Please review: >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ These >>>> changes introduce new parameter[1] of the socket transport - allow. >>>> Users can explicitly specify a list of hosts that allowed to >>>> connect to jdwp server and it's the second part of JDWP >>>> hardening[2]. No restrictions are applied by default now but I'll >>>> file a separate CR to restrict list of allowed peers to localhost >>>> by default. Also these changes implement versioning for jdwp >>>> transport and therefor simplify feature development of jdwp. 1. >>>> Example command line: >>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>>> address=*,allow="127.0.0.0/8;192.168.0.0/24" Possible values for >>>> allow parameter: * - accept connections from >>>> everywhere. N.N.N.N - accept connections from this IP >>>> address only N.N.N.N/nn - accept connections from particular >>>> ip subnet 2. JDK-8052136 JDWP hardening -Dmitry From igor.ignatyev at oracle.com Wed Mar 22 20:09:53 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 Mar 2017 13:09:53 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests Message-ID: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html > 40 lines changed: 26 ins; 13 del; 1 mod; Hi all, could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? testing: :jdk_svc tests webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 [1] https://bugs.openjdk.java.net/browse/JDK-8176176 Thanks, -- Igor From serguei.spitsyn at oracle.com Wed Mar 22 20:16:11 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Mar 2017 13:16:11 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: Hi Igor, It looks good. Thanks, Serguei On 3/22/17 13:09, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >> 40 lines changed: 26 ins; 13 del; 1 mod; > Hi all, > > could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? > > testing: :jdk_svc tests > webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 > > [1] https://bugs.openjdk.java.net/browse/JDK-8176176 > > Thanks, > -- Igor From mandy.chung at oracle.com Wed Mar 22 21:01:47 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Mar 2017 14:01:47 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: > On Mar 22, 2017, at 1:09 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >> 40 lines changed: 26 ins; 13 del; 1 mod; > > Hi all, > > could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? > > testing: :jdk_svc tests > webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java This test should need java.management. Where is it declared? Does the webrev miss some new file? Can you keep @modules sorted? e.g. the following in a few files: 42 * @modules jdk.management.agent/jdk.internal.agent 43 * java.management 44 * jdk.attach Mandy From igor.ignatyev at oracle.com Wed Mar 22 23:09:57 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 Mar 2017 16:09:57 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> Hi Mandy, I've (re)sorted @modules in all the tests which I touched -- http://cr.openjdk.java.net/~iignatyev/8177374/webrev.01/index.html > test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > This test should need java.management. Where is it declared? it's declared in test/java/lang/management/TEST.properties which has been pushed by JDK-8176176. Thanks, -- Igor > On Mar 22, 2017, at 2:01 PM, Mandy Chung wrote: > > >> On Mar 22, 2017, at 1:09 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >>> 40 lines changed: 26 ins; 13 del; 1 mod; >> >> Hi all, >> >> could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? >> >> testing: :jdk_svc tests >> webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 > > > test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > This test should need java.management. Where is it declared? > Does the webrev miss some new file? > > Can you keep @modules sorted? e.g. the following in a few files: > 42 * @modules jdk.management.agent/jdk.internal.agent > 43 * java.management > 44 * jdk.attach > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Mar 22 23:29:11 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Mar 2017 16:29:11 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> Message-ID: > On Mar 22, 2017, at 4:09 PM, Igor Ignatyev wrote: > > Hi Mandy, > > I've (re)sorted @modules in all the tests which I touched -- http://cr.openjdk.java.net/~iignatyev/8177374/webrev.01/index.html > +1 >> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> This test should need java.management. Where is it declared? > it's declared in test/java/lang/management/TEST.properties which has been pushed by JDK-8176176. > Ah I see. this is in jdk9/hs/jdk repo and not yet integrated in jdk9/dev/jdk. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 23 07:18:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Mar 2017 07:18:39 +0000 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: On 22/03/2017 20:09, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >> 40 lines changed: 26 ins; 13 del; 1 mod; > Hi all, > > could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? > > testing: :jdk_svc tests > webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 > The updated @summary tag for test/com/sun/tools/attach/BasicTests.java looks really ugly now. Personally I think I would put the summary at the end and intent the second line to make it easier to read. I also see lots of random empty lines introduced. What is the reason to put empty lines between the @modules and @library tags? I can see what the information tags might be grouped but @library and @modules should also be grouped with the @compile/@run/@build). -Alan From michael.rasmussen at zeroturnaround.com Thu Mar 23 09:30:45 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 23 Mar 2017 11:30:45 +0200 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> <1fef2eae-529f-4c01-2faf-30481a04e1d9@oracle.com> Message-ID: On Mar 14, 2017 23:03, "Vladimir Ivanov" wrote: Yes, you are right. Then the only option is: -XX:+UnlockDiagnosticVMOptions -XX:-CheckIntrinsics Best regards, Vladimir Ivanov Thinking about this a bit further, are these messages going to be enabled by default when jdk9 is released? These kind of messages are clearly only for the benefit of hotspot developers, and has zero value to end users, who wouldn't know anything about this annotation or the implications of it. For the average user, heck you have to be a pretty advanced user to even know what intrinsic means, getting warnings like this, I can only think it would do a lot more harm than good, thinking that their installation is broken or something. /Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Mar 23 11:43:21 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Mar 2017 12:43:21 +0100 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> <1fef2eae-529f-4c01-2faf-30481a04e1d9@oracle.com> Message-ID: On Thu, Mar 23, 2017 at 10:30 AM, Michael Rasmussen wrote: > On Mar 14, 2017 23:03, "Vladimir Ivanov" > wrote: > > Yes, you are right. Then the only option is: > -XX:+UnlockDiagnosticVMOptions -XX:-CheckIntrinsics > > Best regards, > Vladimir Ivanov > > > Thinking about this a bit further, are these messages going to be enabled > by default when jdk9 is released? > > These kind of messages are clearly only for the benefit of hotspot > developers, and has zero value to end users, who wouldn't know anything > about this annotation or the implications of it. > > For the average user, heck you have to be a pretty advanced user to even > know what intrinsic means, getting warnings like this, I can only think it > would do a lot more harm than good, thinking that their installation is > broken or something. > I think this issue is somehow a counterpart of and related to "JDK-8013579: Intrinsics for Java methods don't take class redefinition into account" :) So if you transform a non-native method which is subject to intrinsification you should be aware that your transformations will be lost, once the method will be intrinsified! That said, I agree that the warning message is hard to understand for the average Java developer but I think it has a value. As Vladimir pointed out, if you wrap a native method, which would be intrinisfied otherwise, through class transformation / SetNativeMethodPrefix, that method will not be intrinsified any more. So if you do the transformation for profiling for example, you'd profile a different thing. I actually somehow missed "8131326: Enable CheckIntrinsics in all types of builds" which enabled CheckIntrinsics in product builds by default (before it was only enabled in debug builds). Not sure what was the rational behind this change (CC'ed Zoltan who did the change) but I'm pretty sure that the effects of SetNativeMethodPrefix haven't been taken into account when that change was made. In the end it paid off, otherwise you wouldn't have found this issue :) Regards, Volker > /Michael From daniel.fuchs at oracle.com Thu Mar 23 14:33:32 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 Mar 2017 14:33:32 +0000 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> Message-ID: <9fb37d41-528b-e040-4114-a154e55c777b@oracle.com> Hi Igor, small nit: 42 * @modules java.management 43 * jdk.attach 44 * jdk.management.agent/jdk.internal.agent I don't think java.management needs to be specified as a dependency when the test requires jdk.management.agent, because jdk.management.agent already requires java.management. best regards, -- daniel On 22/03/2017 23:09, Igor Ignatyev wrote: > Hi Mandy, > > I've (re)sorted @modules in all the tests which I touched -- > http://cr.openjdk.java.net/~iignatyev/8177374/webrev.01/index.html > >> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> This test should need java.management. Where is it declared? > it's declared in test/java/lang/management/TEST.properties which has > been pushed by JDK-8176176. > > Thanks, > -- Igor >> On Mar 22, 2017, at 2:01 PM, Mandy Chung > > wrote: >> >> >>> On Mar 22, 2017, at 1:09 PM, Igor Ignatyev >> > wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >>>> 40 lines changed: 26 ins; 13 del; 1 mod; >>> >>> Hi all, >>> >>> could you please review this changeset which fixes in a few jdk_svc >>> tests which were missed by JDK-8176176[1]? >>> >>> testing: :jdk_svc tests >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 >> >> >> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> This test should need java.management. Where is it declared? >> Does the webrev miss some new file? >> >> Can you keep @modules sorted? e.g. the following in a few files: >> 42 * @modules jdk.management.agent/jdk.internal.agent >> 43 * java.management >> 44 * jdk.attach >> Mandy >> > From zoltan.majo at oracle.com Thu Mar 23 14:01:32 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 23 Mar 2017 15:01:32 +0100 Subject: @HotSpotIntrinsicCandidate and native prefixes In-Reply-To: References: <14e87480-fd1e-7481-4c9f-d9939472e50b@oracle.com> <1fef2eae-529f-4c01-2faf-30481a04e1d9@oracle.com> Message-ID: Hi Volker, On 03/23/2017 12:43 PM, Volker Simonis wrote: > [...] > > > I actually somehow missed "8131326: Enable CheckIntrinsics in all > types of builds" which enabled CheckIntrinsics in product builds by > default (before it was only enabled in debug builds). Not sure what > was the rational behind this change (CC'ed Zoltan who did the change) > but I'm pretty sure that the effects of SetNativeMethodPrefix haven't > been taken into account when that change was made. In the end it paid > off, otherwise you wouldn't have found this issue :) I mentioned the following in the RFR for 8131326: "Problem: The CheckIntrinsics flag added by JDK-8076112 is currently enabled only in debug builds. As a result, users of product builds might easier oversee potential mismatches between VM-level and classfile-level intrinsics." http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-July/018425.html I don't recall any other reason for doing this change, although somebody might have asked me in a private message to do it (maybe with more/different justification). Best regards, Zoltan > > Regards, > Volker > >> /Michael From mandy.chung at oracle.com Thu Mar 23 16:39:49 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Mar 2017 09:39:49 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <9fb37d41-528b-e040-4114-a154e55c777b@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> <9fb37d41-528b-e040-4114-a154e55c777b@oracle.com> Message-ID: > On Mar 23, 2017, at 7:33 AM, Daniel Fuchs wrote: > > Hi Igor, > > small nit: > > 42 * @modules java.management > 43 * jdk.attach > 44 * jdk.management.agent/jdk.internal.agent > > I don't think java.management needs to be specified as > a dependency when the test requires jdk.management.agent, > because jdk.management.agent already requires java.management. That?s true. Igor - How do you analyze the dependency? Are you using jdeps ?-list-reduced-deps? Mandy From igor.ignatyev at oracle.com Thu Mar 23 20:07:42 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 Mar 2017 13:07:42 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> <9fb37d41-528b-e040-4114-a154e55c777b@oracle.com> Message-ID: <1FB79522-93C4-4FC5-B351-935D1355C67C@oracle.com> Mandy/Daniel, yes, jdk.management.agent does require java.management, but not transitively. Shura and I have discussed that and agreed that in such cases a test should declare dependency explicitly, otherwise it can start to fail when some of transitive requires (which are not a part of the contract) are changed. I used jdeps with the post-proceccing which makes reduction similar to list-reduced-deps. I have run 'jdeps --list-reduced-deps' on classes from sun/management/jmxremote/bootstrap/CustomLauncherTest.java test run, and it showed the same: > java.management > jdk.attach > jdk.management.agent/jdk.internal.agent > unnamed module: /tmp/run/jdk/sun/management/jmxremote/bootstrap/JTwork-sun-management-jmxremote-bootstrap-CustomLauncherTest-java_0/classes Thanks, -- Igor > On Mar 23, 2017, at 9:39 AM, Mandy Chung wrote: > > >> On Mar 23, 2017, at 7:33 AM, Daniel Fuchs wrote: >> >> Hi Igor, >> >> small nit: >> >> 42 * @modules java.management >> 43 * jdk.attach >> 44 * jdk.management.agent/jdk.internal.agent >> >> I don't think java.management needs to be specified as >> a dependency when the test requires jdk.management.agent, >> because jdk.management.agent already requires java.management. > > That?s true. > > Igor - How do you analyze the dependency? Are you using jdeps ?-list-reduced-deps? > > Mandy > From mandy.chung at oracle.com Thu Mar 23 20:28:20 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Mar 2017 13:28:20 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <1FB79522-93C4-4FC5-B351-935D1355C67C@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <3056CF52-47EB-4C5D-B650-81CDCFFD568F@oracle.com> <9fb37d41-528b-e040-4114-a154e55c777b@oracle.com> <1FB79522-93C4-4FC5-B351-935D1355C67C@oracle.com> Message-ID: <3F51C4BA-8557-43D1-8DE8-73FE159F1628@oracle.com> > On Mar 23, 2017, at 1:07 PM, Igor Ignatyev wrote: > > Mandy/Daniel, > > yes, jdk.management.agent does require java.management, but not transitively. Shura and I have discussed that and agreed that in such cases a test should declare dependency explicitly, otherwise it can start to fail when some of transitive requires (which are not a part of the contract) are changed. > > I used jdeps with the post-proceccing which makes reduction similar to list-reduced-deps. I have run 'jdeps --list-reduced-deps' on classes from sun/management/jmxremote/bootstrap/CustomLauncherTest.java test run, and it showed the same: >> java.management >> jdk.attach >> jdk.management.agent/jdk.internal.agent >> unnamed module: /tmp/run/jdk/sun/management/jmxremote/bootstrap/JTwork-sun-management-jmxremote-bootstrap-CustomLauncherTest-java_0/classes > It?s good you are using `jdeps --list-reduced-deps`. It includes java.management because the test references the exported APIs from java.management. I agree that @modules should list java.management even though the test selection would work properly without it. Mandy From igor.ignatyev at oracle.com Thu Mar 23 22:06:49 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 Mar 2017 15:06:49 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: Hi Alan, > I can see what the information tags might be grouped but @library and @modules should also be grouped with the @compile/@run/@build). from my point of view, there are 3 different groups of tags: - information tags: @test, @bug, @key, @summary, @author. these tags describe a test, some of them can be used for test selection, but they do not affect test execution. - declarative tags: @library, @modules, @requires. they change how a test is executed, but they don't specify any test actions - imperative tags: @run and all its shortcuts -- @compile, @build, @ignore. these tags are action tags, their order is important, and they basically define that a test does. I use empty lines to separate these groups, so it will be easier to maintain tests. for example in past, we had problems with tests which have @ignore tag placed before @library tag. if we had had this separation, a chance to make such mistakes would have been much lower. > What is the reason to put empty lines between the @modules and @library tags? there should be not lines b/w @modules and @library, in what test do you see it? -- Igor > On Mar 23, 2017, at 12:18 AM, Alan Bateman wrote: > > On 22/03/2017 20:09, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >>> 40 lines changed: 26 ins; 13 del; 1 mod; >> Hi all, >> >> could you please review this changeset which fixes in a few jdk_svc tests which were missed by JDK-8176176[1]? >> >> testing: :jdk_svc tests >> webrev: http://cr.openjdk.java.net/~iignatyev/8177374/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177374 >> > The updated @summary tag for test/com/sun/tools/attach/BasicTests.java looks really ugly now. Personally I think I would put the summary at the end and intent the second line to make it easier to read. > > I also see lots of random empty lines introduced. What is the reason to put empty lines between the @modules and @library tags? I can see what the information tags might be grouped but @library and @modules should also be grouped with the @compile/@run/@build). > > -Alan From Alan.Bateman at oracle.com Fri Mar 24 07:10:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 07:10:28 +0000 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> Message-ID: <202a32f5-4828-aa7d-8594-904b203a7008@oracle.com> On 23/03/2017 22:06, Igor Ignatyev wrote: > Hi Alan, > >> I can see what the information tags might be grouped but @library and @modules should also be grouped with the @compile/@run/@build). > from my point of view, there are 3 different groups of tags: > - information tags: @test, @bug, @key, @summary, @author. these tags describe a test, some of them can be used for test selection, but they do not affect test execution. I agree it's nicer to have most of these grouped, I'm less sure that including @summary is always right. The main issue with @summary is that it gets very messy when the descriptions spans multiple lines. Often it is better to put the @summary at the end and/or indent the second/subsequent lines so that it doesn't gets mixed up with the subsequent lines. > - declarative tags: @library, @modules, @requires. they change how a test is executed, but they don't specify any test actions > - imperative tags: @run and all its shortcuts -- @compile, @build, @ignore. these tags are action tags, their order is important, and they basically define that a test does. If you group the @modules with @library/@build/@compile/etc. then I'm okay. Several of the tests that I looked at in the initial rounds where very inconsistent on this and maybe they have been fixed up now. -Alan From Alan.Bateman at oracle.com Fri Mar 24 08:59:09 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 08:59:09 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: References: Message-ID: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> On 24/03/2017 08:45, serguei.spitsyn at oracle.com wrote: > Please, pre-review the JDK 9 fix for: > https://bugs.openjdk.java.net/browse/JDK-8177154 > > > JDK webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.jdk0/ > > > Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.hs0/ > > A few initial comment: I don't think the jdk side should be dependent on the message in the reply, it might be simpler to do: throw new AgentLoadException("Failed to load agent library: " + message) As you are changing RunnerUtil then it would be good to trim down the line that sets myArgs as it is way too long now for side-by-side reviews. On the hotspot side then the flag name looks okay to me. In the message then "Use flag -XX:..." should be reduced to "Use -XX:..." to term the term "flag" out of the message. -Alan From forax at univ-mlv.fr Fri Mar 24 09:34:39 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 24 Mar 2017 10:34:39 +0100 (CET) Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> Message-ID: <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> Please, can we have a discussion on the merit of not of allowing loadAgent by default before discussing about how to implement that. There is only one interesting method in VirtualMachine, loadAgent, and if this method do not work by default, there is no point to have the whole API. If you have to specify a command line flag at load time, why not deploy the agent at load time. So like David Holmes said in the comments of the bug, i don't understand how this will not disrupt every codes that using an agent at runtime. One of strong feature that makes choosing Java on server is that you can attach, at runtime, a monitoring/troubleshooting tool when an event occurs, please do not send us back to the pre Java 6 world ! regards, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "serguei spitsyn" , "serviceability-dev" , > hotspot-runtime-dev at openjdk.java.net > Envoy?: Vendredi 24 Mars 2017 09:59:09 > Objet: Re: PRE-RFR: 8177154: Default configuration should disallow loading agents > On 24/03/2017 08:45, serguei.spitsyn at oracle.com wrote: > >> Please, pre-review the JDK 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8177154 >> >> >> JDK webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.jdk0/ >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.hs0/ >> >> > A few initial comment: > > I don't think the jdk side should be dependent on the message in the > reply, it might be simpler to do: > throw new AgentLoadException("Failed to load agent library: " + message) > > As you are changing RunnerUtil then it would be good to trim down the > line that sets myArgs as it is way too long now for side-by-side reviews. > > On the hotspot side then the flag name looks okay to me. In the message > then "Use flag -XX:..." should be reduced to "Use -XX:..." to term the > term "flag" out of the message. > > -Alan From Alan.Bateman at oracle.com Fri Mar 24 09:48:24 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 09:48:24 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> Message-ID: <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> On 24/03/2017 09:34, Remi Forax wrote: > : > > One of strong feature that makes choosing Java on server is that you can attach, at runtime, a monitoring/troubleshooting tool when an event occurs, > please do not send us back to the pre Java 6 world ! > This does not send us back to the pre JDK 6. The changes have no impact on the troubleshooting tools and no impact on management tools that use the attach API to start the JMX agent in the running VM. The change is simply to make loading of arbitrary code with the attach API opt-in. On the server then you the launch script can specify the proposed option and tools that are loading agents will not see a difference. -Alan. From adinn at redhat.com Fri Mar 24 10:09:33 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Mar 2017 10:09:33 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> Message-ID: <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> On 24/03/17 09:48, Alan Bateman wrote: > This does not send us back to the pre JDK 6. The changes have no impact > on the troubleshooting tools and no impact on management tools that use > the attach API to start the JMX agent in the running VM. The change is > simply to make loading of arbitrary code with the attach API opt-in. On > the server then you the launch script can specify the proposed option > and tools that are loading agents will not see a difference. You are right, Alan, that /strictly/ this doesn't send us back to the pre JDK 6. As you say, users can opt in rather than opt out. But they can also make that choice, mutatis mutandis, if the default is reversed. So, the argument here regards on which side the choice lies. The point I think Remi is making is that /pragmatically/ we will be back in pre-JDK6 land with the current proposed default. You blithely use the words 'the launch script can specify' above. In practice, your use of the definite article belies the fact that there is not 'a' launch script but a plethora of command lines and scripts employed by a multitude of users. It is the practical concerns involved in managing the complexity that that multiplicity implies I am concerned with. I think I probably speak for Remi here too and, perhaps, others agent implementors. I'd like to see a much better argument for the security benefits of this change before it gets rolled into a release. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri Mar 24 11:15:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 11:15:50 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> Message-ID: On 24/03/2017 10:09, Andrew Dinn wrote: > : > The point I think Remi is making is that /pragmatically/ we will be back > in pre-JDK6 land with the current proposed default. You blithely use the > words 'the launch script can specify' above. In practice, your use of > the definite article belies the fact that there is not 'a' launch script > but a plethora of command lines and scripts employed by a multitude of > users. It is the practical concerns involved in managing the complexity > that that multiplicity implies I am concerned with. I think I probably > speak for Remi here too and, perhaps, others agent implementors. I'd > like to see a much better argument for the security benefits of this > change before it gets rolled into a release. > Just to re-cap, the Attach API has several users: 1. The troubleshooting tools such as jcmd, jstack, and jmap 2. Management tools that use the API to start a JMX agent 3. Tools that load JVM TI or java agents into running VMs. The proposal here does not impact #1 and #2, this is why I said thaht it does not bring us back to JDK 5. Opinions will differ but I think #1 is by far the most useful aspect to the attach mechanism. #3 has always been controversial. The issue in JIRA might be only a few days old but the concerns with the dynamic agent loading part go back years (more like 10 years). I did the original attach API back in JDK 6 and regret that the agent loading part wasn't opt-in from the start. Yes, it's hard to change it now. In general then we've done a lot of changes in JDK 8 and JDK 9 to make the platform more secure by default, this fits with that direction. You mentioned in the other mail about the mechanism being restricted to same uid/gid but that is also a bit too restrictive (there are complaints periodically on this). I expect it will have to be relaxed at some point to allow root, users with specific capabilities, Windows Terminal Server environments, etc. In addition, the changes in JDK 9 makes it too easy to use the attach API from regular applications or libraries - something that was never the intention. I don't think it's possible to lock things down from the API side of things, it has to be the VM side. If it is changed to needing to opt-in then the question comes up as to how many tools are impacted and what is the impact. I can't say exactly how many tools using this API to load code into running VM but it doesn't seem to be many. The impact would be that these tools would need to document that the VM needs to be launched with the opt-in option in order to use the tool in this way. It shouldn't impact the IDE environment too much. Server deployments where profilers are other tools would need the CLI option, that could be disruptive to add initially. -Alan From adinn at redhat.com Fri Mar 24 12:09:07 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Mar 2017 12:09:07 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> Message-ID: <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> On 24/03/17 11:15, Alan Bateman wrote: > Just to re-cap, the Attach API has several users: > > 1. The troubleshooting tools such as jcmd, jstack, and jmap > 2. Management tools that use the API to start a JMX agent > 3. Tools that load JVM TI or java agents into running VMs. > > The proposal here does not impact #1 and #2, this is why I said thaht it > does not bring us back to JDK 5. Opinions will differ but I think #1 is > by far the most useful aspect to the attach mechanism. I agree that only #3 is affected. However, my opinion does indeed differ as to what is most useful when it comes to my agent. Byteman usage relies almost exclusively on #3: when used with the BMUnit extension to manage unit or integration testing the ability for BMUnit to hoist the agent into a running JVM makes a critical difference to usability when used for ad hoc trouble shooting of problems at the point where they arise, either in sandbox or production deployments, it is equally critical that the agent can be loaded without prior, explicit preparation for that necessity > #3 has always been controversial. The issue in JIRA might be only a few > days old but the concerns with the dynamic agent loading part go back > years (more like 10 years). I did the original attach API back in JDK 6 > and regret that the agent loading part wasn't opt-in from the start. > Yes, it's hard to change it now. In general then we've done a lot of > changes in JDK 8 and JDK 9 to make the platform more secure by default, > this fits with that direction. You mentioned in the other mail about the > mechanism being restricted to same uid/gid but that is also a bit too > restrictive (there are complaints periodically on this). I expect it > will have to be relaxed at some point to allow root, users with specific > capabilities, Windows Terminal Server environments, etc. In addition, > the changes in JDK 9 makes it too easy to use the attach API from > regular applications or libraries - something that was never the > intention. I don't think it's possible to lock things down from the API > side of things, it has to be the VM side. It may well have been controversial for years as far as you regard it but that is not necessarily grounds to take it as a the definitive position. I discussed this very question with Marc Schoenefeld in much the same timescale you are referring to (this was just around when he moved from working with Red Hat's security team to working for Oracle's security team). He was then perfectly happy with the status quo. IN fact, he even went on to praise Byteman as a very valuable tool in his book on Java security issues. So, before we argue what history is relevant here (of if, indeed, we need to trawl the realms of history when making a present decision) let's have a fuller discussion of what the potential security problems are. You mention the need to allow, for example, root access rather than same gid access as a potential change that might justify this new default. I have to (respectfully) suggest that once root access on the JVM host is compromised then any further closing of gates is akin to Nero fiddling in a burning citadel. The other cases you suggest are, perhaps, more interesting. However, given that you are indeed referring to existing mechanisms for securing access then I'd like to be sure that they are not actually already adequate before determining that this change is required. The current situation already restricts command line access to 'users with specific capabilities' i.e. the same uid and/or gid. Can you provide a precise scenario where there will be a need to employ more relaxed control of such capabilities. Can you also explain why, in consequence, there is a need for the JVM to fix a hole left open by this alternative use of existing user access controls? I am unclear as to why you say there was never an intention to 'use the attach API from regular applications or libraries'. Perhaps this was just a bad design decision in the way VirtualMachine.attach or the native code which underpins it was crafted. It's fairly clear that having implemented this API in Java it would be open for use to load into the current VM as well as into a foreign VM and it's hard top see how the Genie is not out of the bottle by that point. You could, for example, try to plug the gap by refusing to load an agent when the target JVM is the requesting JVM. Of course, you could still then suffer from cyclical loads via one or more intermediate JVMs so I don't think that tactic constitutes a full remedy. I do agree, albeit only to a small degree, JDK9 has made it easier to use the VirtualMachine.attach API: in earlier releases the classes needed to perform the attach were in tools.jar but not in rt.jar so were not normally immediately available to the JDK runtime; in JDK9 they are now in the base image. I qualify that difference as small because I think that it is, perhaps, more an apparent than real level of protection. Any compromise significant enough to allow rogue code into the JVM in JDK9 (i.e. significant enough to allow dynamic loading of an agent using VirtualMachine.attach) could equally have allowed rogue code loaded into a JDK8 to perform the same operation by including the VirtualMachine class in the rogue bundle. > If it is changed to needing to opt-in then the question comes up as to > how many tools are impacted and what is the impact. I can't say exactly > how many tools using this API to load code into running VM but it > doesn't seem to be many. The impact would be that these tools would need > to document that the VM needs to be launched with the opt-in option in > order to use the tool in this way. It shouldn't impact the IDE > environment too much. Server deployments where profilers are other tools > would need the CLI option, that could be disruptive to add initially. Well, that is indeed a good thing to consider. Perhaps that should have been done before raising a JIRA and then posting a commit for review 3 days later? Perhaps it still needs doing? Also, it's not the number of tools affected that counts but the impact of the change on users of those tools vs the gains in security that result from the change. On the debit side, I can assure you that the former is something Red Hat consider to be very serious. It's not simply documentation (and the need to promulgate the required understanding beyond mere written words) it is also, as I mention in mye earlier note, legacy and the ability to interoperate between JDK releases. On the credit side, I'm not yet convinced that this change achieves an improvement in security that is not available via other, better means. Perhaps, you could provide more meat on that particular bone? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri Mar 24 12:25:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Mar 2017 12:25:32 +0000 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> Message-ID: <8f1a70be-b3f7-2a46-b52d-3beb7cd87d45@oracle.com> On 24/03/2017 12:09, Andrew Dinn wrote: > : > I am unclear as to why you say there was never an intention to 'use the > attach API from regular applications or libraries'. Perhaps this was > just a bad design decision in the way VirtualMachine.attach or the > native code which underpins it was crafted. It's fairly clear that > having implemented this API in Java it would be open for use to load > into the current VM as well as into a foreign VM and it's hard top see > how the Genie is not out of the bottle by that point. You could, for > example, try to plug the gap by refusing to load an agent when the > target JVM is the requesting JVM. Of course, you could still then suffer > from cyclical loads via one or more intermediate JVMs so I don't think > that tactic constitutes a full remedy. > It was designed as an API for tools, that is why it was in tools.jar and not the runtime/JRE. Tools or applications with tools.jar on the class path could use it to load agents into the current running VM, that has always been possible. It's futile (as I said) to try to prevent this on the API side, it can only be disabled on the VM side. -Alan. From neugens at redhat.com Fri Mar 24 12:43:02 2017 From: neugens at redhat.com (Mario Torre) Date: Fri, 24 Mar 2017 13:43:02 +0100 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> Message-ID: On Fri, Mar 24, 2017 at 10:48 AM, Alan Bateman wrote: > On 24/03/2017 09:34, Remi Forax wrote: > >> : >> >> One of strong feature that makes choosing Java on server is that you can >> attach, at runtime, a monitoring/troubleshooting tool when an event occurs, >> please do not send us back to the pre Java 6 world ! >> > This does not send us back to the pre JDK 6. The changes have no impact on > the troubleshooting tools and no impact on management tools that use the > attach API to start the JMX agent in the running VM. The change is simply to > make loading of arbitrary code with the attach API opt-in. On the server > then you the launch script can specify the proposed option and tools that > are loading agents will not see a difference. Hello Alan, This solution feels like a bit of a quick hack to me. Nevertheless, I think it should be opt-out, or at least with a configurable default. I can see the only reasonable use case where you don't want to have external code to plug in but still want to start with a default agent, for instance if you want to use byteman with the jvm, but not allow anything else to plug in at runtime (byteman or similar tools of course). Cheers, Mario From neugens at redhat.com Fri Mar 24 12:50:02 2017 From: neugens at redhat.com (Mario Torre) Date: Fri, 24 Mar 2017 13:50:02 +0100 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> Message-ID: On Fri, Mar 24, 2017 at 12:15 PM, Alan Bateman wrote: > I expect it will have to be relaxed at some point to allow root FWIW, we had the need for such use case in Thermostat and we had to work around this requirement, Elliot even sent a patch some time ago. With that said, I do think that it's reasonable that root can't access to the JVM, nothing should run as root and if you need that, something smells troubles. I'm not sure, especially in a containerised world, that this requirement makes sense at all, so I wouldn't relax it. Cheers, Mario From serguei.spitsyn at oracle.com Fri Mar 24 18:01:33 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Mar 2017 11:01:33 -0700 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> Message-ID: Alan, Thank you for the suggestions. I've updated my repository accordingly. Thanks, Serguei On 3/24/17 01:59, Alan Bateman wrote: > On 24/03/2017 08:45, serguei.spitsyn at oracle.com wrote: > >> Please, pre-review the JDK 9 fix for: >> https://bugs.openjdk.java.net/browse/JDK-8177154 >> >> >> JDK webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.jdk0/ >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.hs0/ >> >> > A few initial comment: > > I don't think the jdk side should be dependent on the message in the > reply, it might be simpler to do: > throw new AgentLoadException("Failed to load agent library: " + > message) > > As you are changing RunnerUtil then it would be good to trim down the > line that sets myArgs as it is way too long now for side-by-side reviews. > > On the hotspot side then the flag name looks okay to me. In the > message then "Use flag -XX:..." should be reduced to "Use -XX:..." to > term the term "flag" out of the message. > > -Alan > > From igor.ignatyev at oracle.com Fri Mar 24 20:34:05 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Mar 2017 13:34:05 -0700 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: <202a32f5-4828-aa7d-8594-904b203a7008@oracle.com> References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <202a32f5-4828-aa7d-8594-904b203a7008@oracle.com> Message-ID: > On Mar 24, 2017, at 12:10 AM, Alan Bateman wrote: > On 23/03/2017 22:06, Igor Ignatyev wrote: >> >>> I can see what the information tags might be grouped but @library and @modules should also be grouped with the @compile/@run/@build). >> from my point of view, there are 3 different groups of tags: >> - information tags: @test, @bug, @key, @summary, @author. these tags describe a test, some of them can be used for test selection, but they do not affect test execution. > I agree it's nicer to have most of these grouped, I'm less sure that including @summary is always right. The main issue with @summary is that it gets very messy when the descriptions spans multiple lines. Often it is better to put the @summary at the end and/or indent the second/subsequent lines so that it doesn't gets mixed up with the subsequent lines. if we agreed to have @summary at the end of this group and indent subsequent lines, it will be both readable and grouped w/ other information tags. in the test you mentioned (test/com/sun/tools/attach/BasicTests.java), we actually had a bug, 'This test will ...' line was passed to a test as an argument, and wasn't a part of summary at all, I saw similar things in many other tests and am planning to fix them in a separate cleanup RFE. >> - declarative tags: @library, @modules, @requires. they change how a test is executed, but they don't specify any test actions >> - imperative tags: @run and all its shortcuts -- @compile, @build, @ignore. these tags are action tags, their order is important, and they basically define that a test does. > If you group the @modules with @library/@build/@compile/etc. then I'm okay. if we group @library w/ @run/@build/@compile we will still have the problem I described w/ adding @ignore. and since @modules and @library are quite different from @run/@build/@compile, I'd prefer to have them in separate groups. could you please elaborate more on why you want to have declarative and imperative tags grouped together? -- Igor From igor.ignatyev at oracle.com Fri Mar 24 20:56:34 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Mar 2017 13:56:34 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified Message-ID: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 > 295 lines changed: 176 ins; 15 del; 104 mod; Hi all, could you please review this fix for 8177507? due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 testing: test/com/sun/jdi Thanks, -- Igor From Alan.Bateman at oracle.com Sat Mar 25 07:34:56 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Mar 2017 07:34:56 +0000 Subject: RFR(S) : 8177374 : fix module dependency declaration in jdk_svc tests In-Reply-To: References: <0DADE381-4D06-42B9-8BD4-28C274E87BC4@oracle.com> <202a32f5-4828-aa7d-8594-904b203a7008@oracle.com> Message-ID: <81356e57-0657-506a-0cad-27b252791522@oracle.com> On 24/03/2017 20:34, Igor Ignatyev wrote: > : > if we agreed to have @summary at the end of this group and indent subsequent lines, it will be both readable and grouped w/ other information tags. > in the test you mentioned (test/com/sun/tools/attach/BasicTests.java), we actually had a bug, 'This test will ...' line was passed to a test as an argument, and wasn't a part of summary at all, I saw similar things in many other tests and am planning to fix them in a separate cleanup RFE. If the @summary is the last tag then you shouldn't have a problem. -Alan From amy.lu at oracle.com Mon Mar 27 03:06:12 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 27 Mar 2017 11:06:12 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group Message-ID: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> jdk/internal/loader jdk/internal/util com/sun/jarsigner jdk/internal/agent Somehow these are missed in TEST.group. Please review this patch to update TEST.group Tested on all platforms, TestVersionedStream.java fails on Windows, put it in ProblemList.txt for now. bug: https://bugs.openjdk.java.net/browse/JDK-8177638 webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 @@ -286,6 +286,7 @@ java/util/BitSet/BitSetStreamTest.java 8079538 generic-all +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all ############################################################################ --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 @@ -70,6 +70,7 @@ sun/reflect \ jdk/internal/reflect \ jdk/lambda \ + jdk/internal/loader \ jdk/internal/misc \ jdk/internal/ref \ jdk/internal/jimage \ @@ -87,6 +88,7 @@ jdk_util_other = \ java/util \ sun/util \ + jdk/internal/util \ -:jdk_collections \ -:jdk_concurrent \ -:jdk_stream @@ -189,6 +191,7 @@ lib/security jdk_security4 = \ + com/sun/jarsigner \ com/sun/security/jgss \ javax/security/auth/kerberos \ sun/security/krb5 \ @@ -207,7 +210,8 @@ jdk_management = \ java/lang/management \ com/sun/management \ - sun/management + sun/management \ + jdk/internal/agent jdk_instrument = \ java/lang/instrument -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 27 03:25:32 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Mar 2017 11:25:32 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> Message-ID: <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> The com/sun/jarsigner line should be added to jdk_security3. Roughly, the categories mean: 1: public APIs 2: JCE 3: implementation and private APIs 4: JGSS/krb5 Thanks Max On 03/27/2017 11:06 AM, Amy Lu wrote: > jdk/internal/loader > jdk/internal/util > com/sun/jarsigner > jdk/internal/agent > > Somehow these are missed in TEST.group. > > Please review this patch to update TEST.group > > Tested on all platforms, TestVersionedStream.java fails on Windows, put > it in ProblemList.txt for now. > > bug: https://bugs.openjdk.java.net/browse/JDK-8177638 > webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > @@ -286,6 +286,7 @@ > > java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > > +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all > > ############################################################################ > > --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > @@ -70,6 +70,7 @@ > sun/reflect \ > jdk/internal/reflect \ > jdk/lambda \ > + jdk/internal/loader \ > jdk/internal/misc \ > jdk/internal/ref \ > jdk/internal/jimage \ > @@ -87,6 +88,7 @@ > jdk_util_other = \ > java/util \ > sun/util \ > + jdk/internal/util \ > -:jdk_collections \ > -:jdk_concurrent \ > -:jdk_stream > @@ -189,6 +191,7 @@ > lib/security > > jdk_security4 = \ > + com/sun/jarsigner \ > com/sun/security/jgss \ > javax/security/auth/kerberos \ > sun/security/krb5 \ > @@ -207,7 +210,8 @@ > jdk_management = \ > java/lang/management \ > com/sun/management \ > - sun/management > + sun/management \ > + jdk/internal/agent > > jdk_instrument = \ > java/lang/instrument > > From amy.lu at oracle.com Mon Mar 27 05:12:27 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 27 Mar 2017 13:12:27 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> Message-ID: Sure. Moved to jdk_security3. webrev updated: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ Thanks, Amy On 3/27/17 11:25 AM, Weijun Wang wrote: > The com/sun/jarsigner line should be added to jdk_security3. > > Roughly, the categories mean: > > 1: public APIs > 2: JCE > 3: implementation and private APIs > 4: JGSS/krb5 > > Thanks > Max > > On 03/27/2017 11:06 AM, Amy Lu wrote: >> jdk/internal/loader >> jdk/internal/util >> com/sun/jarsigner >> jdk/internal/agent >> >> Somehow these are missed in TEST.group. >> >> Please review this patch to update TEST.group >> >> Tested on all platforms, TestVersionedStream.java fails on Windows, put >> it in ProblemList.txt for now. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8177638 >> webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> @@ -286,6 +286,7 @@ >> >> java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >> >> +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all >> >> ############################################################################ >> >> >> --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> @@ -70,6 +70,7 @@ >> sun/reflect \ >> jdk/internal/reflect \ >> jdk/lambda \ >> + jdk/internal/loader \ >> jdk/internal/misc \ >> jdk/internal/ref \ >> jdk/internal/jimage \ >> @@ -87,6 +88,7 @@ >> jdk_util_other = \ >> java/util \ >> sun/util \ >> + jdk/internal/util \ >> -:jdk_collections \ >> -:jdk_concurrent \ >> -:jdk_stream >> @@ -189,6 +191,7 @@ >> lib/security >> >> jdk_security4 = \ >> + com/sun/jarsigner \ >> com/sun/security/jgss \ >> javax/security/auth/kerberos \ >> sun/security/krb5 \ >> @@ -207,7 +210,8 @@ >> jdk_management = \ >> java/lang/management \ >> com/sun/management \ >> - sun/management >> + sun/management \ >> + jdk/internal/agent >> >> jdk_instrument = \ >> java/lang/instrument >> >> From igor.ignatyev at oracle.com Wed Mar 29 00:42:34 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Mar 2017 17:42:34 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: Message-ID: Hi, still looking for a reviewer, anyone? -- Igor > On Mar 24, 2017, at 1:56 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >> 295 lines changed: 176 ins; 15 del; 104 mod; > > Hi all, > > could you please review this fix for 8177507? > > due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. > > some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. > > webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 > testing: test/com/sun/jdi > > Thanks, > -- Igor From amy.lu at oracle.com Wed Mar 29 01:16:58 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 29 Mar 2017 09:16:58 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> Message-ID: <92343987-fb71-0345-fb13-b98da6ad404e@oracle.com> Ping ~ On 3/27/17 1:12 PM, Amy Lu wrote: > Sure. Moved to jdk_security3. > > webrev updated: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ > > Thanks, > Amy > > On 3/27/17 11:25 AM, Weijun Wang wrote: >> The com/sun/jarsigner line should be added to jdk_security3. >> >> Roughly, the categories mean: >> >> 1: public APIs >> 2: JCE >> 3: implementation and private APIs >> 4: JGSS/krb5 >> >> Thanks >> Max >> >> On 03/27/2017 11:06 AM, Amy Lu wrote: >>> jdk/internal/loader >>> jdk/internal/util >>> com/sun/jarsigner >>> jdk/internal/agent >>> >>> Somehow these are missed in TEST.group. >>> >>> Please review this patch to update TEST.group >>> >>> Tested on all platforms, TestVersionedStream.java fails on Windows, put >>> it in ProblemList.txt for now. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8177638 >>> webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >>> +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >>> @@ -286,6 +286,7 @@ >>> >>> java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >>> >>> +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all >>> >>> ############################################################################ >>> >>> >>> --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >>> +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >>> @@ -70,6 +70,7 @@ >>> sun/reflect \ >>> jdk/internal/reflect \ >>> jdk/lambda \ >>> + jdk/internal/loader \ >>> jdk/internal/misc \ >>> jdk/internal/ref \ >>> jdk/internal/jimage \ >>> @@ -87,6 +88,7 @@ >>> jdk_util_other = \ >>> java/util \ >>> sun/util \ >>> + jdk/internal/util \ >>> -:jdk_collections \ >>> -:jdk_concurrent \ >>> -:jdk_stream >>> @@ -189,6 +191,7 @@ >>> lib/security >>> >>> jdk_security4 = \ >>> + com/sun/jarsigner \ >>> com/sun/security/jgss \ >>> javax/security/auth/kerberos \ >>> sun/security/krb5 \ >>> @@ -207,7 +210,8 @@ >>> jdk_management = \ >>> java/lang/management \ >>> com/sun/management \ >>> - sun/management >>> + sun/management \ >>> + jdk/internal/agent >>> >>> jdk_instrument = \ >>> java/lang/instrument >>> >>> > From david.holmes at oracle.com Wed Mar 29 01:37:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Mar 2017 11:37:38 +1000 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: Message-ID: Hi Igor, This cleanup looks good to me! One query: test/com/sun/jdi/LineNumberOnBraceTest.java The old version seems to have the wrong line numbers - was it failing? Two nits: - test/com/sun/jdi/FetchLocals.java - test/com/sun/jdi/LambdaBreakpointTest.java Second copyright year should be 2017. Thanks, David ----- On 29/03/2017 10:42 AM, Igor Ignatyev wrote: > Hi, > > still looking for a reviewer, anyone? > > -- Igor >> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>> 295 lines changed: 176 ins; 15 del; 104 mod; >> >> Hi all, >> >> could you please review this fix for 8177507? >> >> due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. >> >> some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >> testing: test/com/sun/jdi >> >> Thanks, >> -- Igor > From igor.ignatyev at oracle.com Wed Mar 29 02:50:22 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Mar 2017 19:50:22 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: Message-ID: <3754452A-699C-48CD-924A-6DC963B3AFFF@oracle.com> Hi David, thank you for review. please see my answers inlined. > On Mar 28, 2017, at 6:37 PM, David Holmes wrote: > > Hi Igor, > > This cleanup looks good to me! One query: > > test/com/sun/jdi/LineNumberOnBraceTest.java > > The old version seems to have the wrong line numbers - was it failing? it didn't run, because it had @test/nodynamiccopyright/ instead of @test > > Two nits: > - test/com/sun/jdi/FetchLocals.java > - test/com/sun/jdi/LambdaBreakpointTest.java > > Second copyright year should be 2017. sure, I'll update it before push. -- Igor > > Thanks, > David > ----- > > On 29/03/2017 10:42 AM, Igor Ignatyev wrote: >> Hi, >> >> still looking for a reviewer, anyone? >> >> -- Igor >>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>> 295 lines changed: 176 ins; 15 del; 104 mod; >>> >>> Hi all, >>> >>> could you please review this fix for 8177507? >>> >>> due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. >>> >>> some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>> testing: test/com/sun/jdi >>> >>> Thanks, >>> -- Igor >> From dmitry.samersoff at oracle.com Wed Mar 29 15:10:40 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Mar 2017 18:10:40 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <320d4094-b65a-3f59-2324-b53d86161e9c@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <320d4094-b65a-3f59-2324-b53d86161e9c@oracle.com> Message-ID: <41366a7c-f92d-b02f-01e3-85832c1086db@oracle.com> Robbin, > One follow-up issue is that if you start suspended > and than connect with > an unallowed client the JVM starts and executes the program. Fixed. see http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.15 -Dmitry On 2017-03-16 15:59, Robbin Ehn wrote: > Hi Dmitry, thanks for the update. > > One follow-up issue is that if you start suspended and than connect with > an unallowed client the JVM starts and executes the program. > Simple program prints "Hello". > > [rehn at rehn-ws vanilla-hs]$ java > -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:9999,allow=1.2.3.0/32 > -cp . H > Listening for transport dt_socket at address: 9999 > ERROR: Peer not allowed to connect > Listening for transport dt_socket at address: 9999 > Hello > > I think it would be good if the VM stayed suspended when an unallowed > client connects. > > Thanks, Robbin > > On 03/13/2017 08:07 PM, Dmitry Samersoff wrote: >> Robbin, >> >> Please, see: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.11 >> >>> 1: >>> So connecting with an unallowed client terminates the VM. >> >> Fixed. >> >>> 2: >>> Starting with an bad allow filter terminates the VM when connecting a >>> client. >> >> Moved allowed parameter (and parser call) to StartListening. >> >> -Dmitry >> >> >> On 2017-03-10 15:56, Robbin Ehn wrote: >>> Hi Dmitry, >>> >>> I took a look at this, I have two practical issues: >>> >>> 1: >>> [rehn at rehn-ws dev]$ java >>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 >>> >>> -cp runs ForEver >>> Listening for transport dt_socket at address: 9999 >>> ERROR: transport error 202: peer not allowed to connect: Success >>> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >>> error [transport.c:358] >>> >>> So connecting with an unallowed client terminates the VM. >>> >>> 2: >>> [rehn at rehn-ws dev]$ java >>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 >>> >>> -cp runs ForEver >>> Listening for transport dt_socket at address: 9999 >>> ERROR: transport error 202: unable to parse list of allowed peers: >>> Success >>> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >>> error [transport.c:358] >>> >>> Starting with an bad allow filter terminates the VM when connecting a >>> client. >>> >>> >>> Connecting with an unallowed ip/port should not terminate the VM and we >>> should verify allow filter directly at startup. >>> >>> Thanks >>> >>> /Robbin >>> >>> On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >>>> >>>> These changes introduce new parameter[1] of the socket transport - >>>> allow. Users can explicitly specify a list of hosts that allowed to >>>> connect to jdwp server and it's the second part of JDWP hardening[2]. >>>> >>>> No restrictions are applied by default now but I'll file a separate CR >>>> to restrict list of allowed peers to localhost by default. >>>> >>>> Also these changes implement versioning for jdwp transport and therefor >>>> simplify feature development of jdwp. >>>> >>>> >>>> 1. Example command line: >>>> >>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>>> address=*,allow="127.0.0.0/8;192.168.0.0/24" >>>> >>>> Possible values for allow parameter: >>>> * - accept connections from everywhere. >>>> N.N.N.N - accept connections from this IP address only >>>> N.N.N.N/nn - accept connections from particular ip subnet >>>> >>>> >>>> >>>> 2. JDK-8052136 JDWP hardening >>>> >>>> -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 mikhailo.seledtsov at oracle.com Wed Mar 29 18:08:50 2017 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Wed, 29 Mar 2017 11:08:50 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: Message-ID: <58DBF832.2010902@oracle.com> Hi Igor, Looks good. One style nit: LineNumberOnBraceTarg: All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) for line number variables, but this test uses 'stopLine'. Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. The rest looks good to me (+ David's comments) Thank you, Misha On 3/28/17, 5:42 PM, Igor Ignatyev wrote: > Hi, > > still looking for a reviewer, anyone? > > -- Igor >> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>> 295 lines changed: 176 ins; 15 del; 104 mod; >> Hi all, >> >> could you please review this fix for 8177507? >> >> due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. >> >> some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >> testing: test/com/sun/jdi >> >> Thanks, >> -- Igor From omajid at redhat.com Wed Mar 29 19:51:01 2017 From: omajid at redhat.com (Omair Majid) Date: Wed, 29 Mar 2017 15:51:01 -0400 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> Message-ID: <20170329195101.GI7241@redhat.com> Hi, * Mandy Chung [2017-01-30 18:42]: > java.management is the module for JMX and JMX remote API and > java.lang.management. JDK management agent provides the JDK-specific > out-of-the-box monitoring and management support and it?s cleaner > for it to live in its own module. It is proposed to move it > to a new module named `jdk.management.agent`. Sorry to dig up this old thread, but I was looking at this changeset [1] and was wondering what happened to the snmp.acl.template file. Am I correct in understanding that since the SNMP agent is not part of OpenJDK, the ACL file is now also not part of OpenJDK anymore? Thanks, Omair [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7bd7a7ffa84b -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From serguei.spitsyn at oracle.com Wed Mar 29 19:57:35 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Mar 2017 12:57:35 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <58DBF832.2010902@oracle.com> References: <58DBF832.2010902@oracle.com> Message-ID: Hi Igor, +1 to the Mikhailo's comment. This one also does not look unified: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html But I do not have a strong opinion on it and leave it up to you. Thanks, Serguei On 3/29/17 11:08, Mikhailo Seledtsov wrote: > Hi Igor, > > Looks good. One style nit: > > LineNumberOnBraceTarg: > All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) > for line number variables, but this test uses 'stopLine'. > Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. > > The rest looks good to me (+ David's comments) > > > Thank you, > Misha > > > > On 3/28/17, 5:42 PM, Igor Ignatyev wrote: >> Hi, >> >> still looking for a reviewer, anyone? >> >> -- Igor >>> On Mar 24, 2017, at 1:56 PM, Igor >>> Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>> 295 lines changed: 176 ins; 15 del; 104 mod; >>> Hi all, >>> >>> could you please review this fix for 8177507? >>> >>> due to their nature, some of jdi tests are line number sensitive. >>> unfortunately different tests indicate that differently, so it's >>> quite easy to overlook that and incidentally break tests, for >>> example by changing module dependency declaration or license >>> modification. this fix unifies the way line number sensitivity is >>> indicated and also improves readability/maintainability of some >>> tests by using constant fields instead of magic numbers. >>> >>> some of line number sensitive tests have been unexpectedly removed >>> from execution because they had @test/nodynamiccopyright/ instead of >>> @test tag. this changeset fixes and returns them to regular execution. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>> testing: test/com/sun/jdi >>> >>> Thanks, >>> -- Igor From mandy.chung at oracle.com Wed Mar 29 20:07:07 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Mar 2017 13:07:07 -0700 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <20170329195101.GI7241@redhat.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <20170329195101.GI7241@redhat.com> Message-ID: > On Mar 29, 2017, at 12:51 PM, Omair Majid wrote: > > Hi, > > * Mandy Chung [2017-01-30 18:42]: >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. > > Sorry to dig up this old thread, but I was looking at this changeset [1] > and was wondering what happened to the snmp.acl.template file. Am I > correct in understanding that since the SNMP agent is not part of > OpenJDK, the ACL file is now also not part of OpenJDK anymore? Correct. snmp.acl.template belongs to SNMP agent and it was a bug that this file was left in the openjdk source. Mandy From omajid at redhat.com Wed Mar 29 20:08:02 2017 From: omajid at redhat.com (Omair Majid) Date: Wed, 29 Mar 2017 16:08:02 -0400 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <20170329195101.GI7241@redhat.com> Message-ID: <20170329200802.GK7241@redhat.com> Hi Mandy, * Mandy Chung [2017-03-29 16:07]: > > On Mar 29, 2017, at 12:51 PM, Omair Majid wrote: > > * Mandy Chung [2017-01-30 18:42]: > >> java.management is the module for JMX and JMX remote API and > >> java.lang.management. JDK management agent provides the JDK-specific > >> out-of-the-box monitoring and management support and it?s cleaner > >> for it to live in its own module. It is proposed to move it > >> to a new module named `jdk.management.agent`. > > > > Sorry to dig up this old thread, but I was looking at this changeset [1] > > and was wondering what happened to the snmp.acl.template file. Am I > > correct in understanding that since the SNMP agent is not part of > > OpenJDK, the ACL file is now also not part of OpenJDK anymore? > > Correct. snmp.acl.template belongs to SNMP agent and it was a bug > that this file was left in the openjdk source. Thanks for clarifying! Regards, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mark.reinhold at oracle.com Thu Mar 30 15:38:45 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Mar 2017 08:38:45 -0700 (PDT) Subject: Disallowing the dynamic loading of agents by default In-Reply-To: <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> <3a67f8d4-84aa-77cb-989d-3e06d6171aa2@redhat.com> <843dfb0f-04cd-6af7-90ad-ce6f0d48b86d@redhat.com> Message-ID: <20170330153845.72C9B96BD9@eggemoggin.niobe.net> // Moving the general discussion to jigsaw-dev for the record; // bcc'ing {hotspot-runtime,serviceability}-dev for reference. Andrew, Thanks for your feedback on this topic [1][2][3]. First, we apologize for the way in which this topic was raised. Our intent was to post a proposal for discussion prior to code review, but unfortunately that review was posted prematurely (as is evident by its inclusion of Oracle-internal e-mail addresses and URLs). Second, I agree with your earlier analysis as to the security impact of this change. If an attack is possible via this vector then closing the vector would only slow the attack, not prevent it. The motivation for this change is, however, not merely to improve the security of the platform but to improve its integrity, which is one of the principal goals of the entire modularity effort. Integrity has benefits for security and also for maintainability, of both the JDK itself and of code that runs upon it, since it makes it clear exactly which APIs are intended for external use, and which are not. To improve platform integrity we've strongly encapsulated (most) of the internal APIs of the JDK. That can be, as we all know, a source of pain for developers trying to get existing applications to run on JDK 9, so we've provided workarounds via the encapsulation-busting `--add-opens` and `--add-exports` command-line options and, recently, the temporary but more powerful (and verbose) `--permit-illegal-access` option. There are no API equivalents to these command-line options [4]. That's intentional: We want developers and deployers using Java out-of-the-box to be assured that their code is only using APIs actually intended for external use. They can choose explicitly to expose internal APIs, via the command line, but then that's a deliberate choice that they make, and they own the consequences. It's reasonable to allow this via the command line since we assume that anyone with access to the command line already has the power to corrupt the JDK in any way they please. The proposal to disable the loading of dynamic agents by default is one more part of the overall integrity story. As things stand today, code in any JAR file can use the `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's running and, via that agent, break into any module it likes. Changing the default and providing a new command-line option, in this case `-XX:+EnableDyanmicAgentLoading`, is consistent with the other encapsulation-busting options we've introduced. It allows a developer or deployer to choose to bend, if not violate, the integrity of the platform, yet also to know that by default the platform is whole. (Changing this default is also consistent, as Alan has noted, with the original intent of the `VirtualMachine.loadAgent` API.) I understand your points about the practical difficulties of having to educate users about this new option and enhance startup scripts to use the option only when invoking JDK 9. Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options anyway, in order to expose internal APIs? If so then would it really be that much more burdensome for users also to think explicitly, at the same time, about whether they want to enable dynamic agent loading? This change would be disruptive to some but it's the best way we've found, so far, to preserve platform integrity in the face of dynamic agent loading. If there's a better way to do that, we'd like to know. - Mark [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022948.html [2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022951.html [3] https://bugs.openjdk.java.net/browse/JDK-8177154 [4] There are limited reflective APIs via which code in a module can apply some of these operations to just that module, and via which code that creates a module layer can do so for modules in that layer, but none of these APIs can break into arbitrary modules. From kirk at kodewerk.com Thu Mar 30 19:37:52 2017 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 30 Mar 2017 21:37:52 +0200 Subject: PRE-RFR: 8177154: Default configuration should disallow loading agents In-Reply-To: References: <4eaf97bc-3856-b3f5-a917-b1d52540f45f@oracle.com> <85733674.1623074.1490348079163.JavaMail.zimbra@u-pem.fr> <5dddcc51-1f26-36cb-ad98-9036133b5d3c@oracle.com> Message-ID: Hi Alan, I have to agree with Mario here. I think a natural reaction would be to configure the JVM to opt-in by default. Otherwise you will break just about every APM/Monitoring tool out there. If opt-in is almost an automatic then you have to question the value of this change. Kind regards, Kirk > On Mar 24, 2017, at 1:43 PM, Mario Torre wrote: > > On Fri, Mar 24, 2017 at 10:48 AM, Alan Bateman wrote: >> On 24/03/2017 09:34, Remi Forax wrote: >> >>> : >>> >>> One of strong feature that makes choosing Java on server is that you can >>> attach, at runtime, a monitoring/troubleshooting tool when an event occurs, >>> please do not send us back to the pre Java 6 world ! >>> >> This does not send us back to the pre JDK 6. The changes have no impact on >> the troubleshooting tools and no impact on management tools that use the >> attach API to start the JMX agent in the running VM. The change is simply to >> make loading of arbitrary code with the attach API opt-in. On the server >> then you the launch script can specify the proposed option and tools that >> are loading agents will not see a difference. > > Hello Alan, > > This solution feels like a bit of a quick hack to me. Nevertheless, I > think it should be opt-out, or at least with a configurable default. I > can see the only reasonable use case where you don't want to have > external code to plug in but still want to start with a default agent, > for instance if you want to use byteman with the jvm, but not allow > anything else to plug in at runtime (byteman or similar tools of > course). > > Cheers, > Mario From amy.lu at oracle.com Fri Mar 31 05:42:31 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 31 Mar 2017 13:42:31 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> Message-ID: I'm still waiting for reviewer's feedback for the TEST.groups update: jdk/internal/loader (add to jdk_lang) jdk/internal/util (add to jdk_util_other) jdk/internal/agent (add to jdk_management) (Security part has been reviewed. Thank you Max!) Thanks, Amy On 3/27/17 11:06 AM, Amy Lu wrote: > jdk/internal/loader > jdk/internal/util > com/sun/jarsigner > jdk/internal/agent > > Somehow these are missed in TEST.group. > > Please review this patch to update TEST.group > > Tested on all platforms, TestVersionedStream.java fails on Windows, > put it in ProblemList.txt for now. > > bug: https://bugs.openjdk.java.net/browse/JDK-8177638 > webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > @@ -286,6 +286,7 @@ > > java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > > +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all > > ############################################################################ > > > --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > @@ -70,6 +70,7 @@ > sun/reflect \ > jdk/internal/reflect \ > jdk/lambda \ > + jdk/internal/loader \ > jdk/internal/misc \ > jdk/internal/ref \ > jdk/internal/jimage \ > @@ -87,6 +88,7 @@ > jdk_util_other = \ > java/util \ > sun/util \ > + jdk/internal/util \ > -:jdk_collections \ > -:jdk_concurrent \ > -:jdk_stream > @@ -189,6 +191,7 @@ > lib/security > > jdk_security4 = \ > + com/sun/jarsigner \ > com/sun/security/jgss \ > javax/security/auth/kerberos \ > sun/security/krb5 \ > @@ -207,7 +210,8 @@ > jdk_management = \ > java/lang/management \ > com/sun/management \ > - sun/management > + sun/management \ > + jdk/internal/agent > > jdk_instrument = \ > java/lang/instrument > > From serguei.spitsyn at oracle.com Fri Mar 31 08:05:31 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 31 Mar 2017 01:05:31 -0700 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> Message-ID: <8f840944-501f-13bb-1117-cb33f009a3dc@oracle.com> Hi Amy, It looks good to me. Thanks, Serguei On 3/30/17 22:42, Amy Lu wrote: > I'm still waiting for reviewer's feedback for the TEST.groups update: > > jdk/internal/loader (add to jdk_lang) > jdk/internal/util (add to jdk_util_other) > jdk/internal/agent (add to jdk_management) > > (Security part has been reviewed. Thank you Max!) > > Thanks, > Amy > > On 3/27/17 11:06 AM, Amy Lu wrote: >> jdk/internal/loader >> jdk/internal/util >> com/sun/jarsigner >> jdk/internal/agent >> >> Somehow these are missed in TEST.group. >> >> Please review this patch to update TEST.group >> >> Tested on all platforms, TestVersionedStream.java fails on Windows, >> put it in ProblemList.txt for now. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8177638 >> webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> @@ -286,6 +286,7 @@ >> >> java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >> >> +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all >> >> ############################################################################ >> >> >> --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> @@ -70,6 +70,7 @@ >> sun/reflect \ >> jdk/internal/reflect \ >> jdk/lambda \ >> + jdk/internal/loader \ >> jdk/internal/misc \ >> jdk/internal/ref \ >> jdk/internal/jimage \ >> @@ -87,6 +88,7 @@ >> jdk_util_other = \ >> java/util \ >> sun/util \ >> + jdk/internal/util \ >> -:jdk_collections \ >> -:jdk_concurrent \ >> -:jdk_stream >> @@ -189,6 +191,7 @@ >> lib/security >> >> jdk_security4 = \ >> + com/sun/jarsigner \ >> com/sun/security/jgss \ >> javax/security/auth/kerberos \ >> sun/security/krb5 \ >> @@ -207,7 +210,8 @@ >> jdk_management = \ >> java/lang/management \ >> com/sun/management \ >> - sun/management >> + sun/management \ >> + jdk/internal/agent >> >> jdk_instrument = \ >> java/lang/instrument >> >> >