RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules

Hi All, Please review fix for issue, JDK-8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules with webrev located at, http://cr.openjdk.java.net/~hb/8131061/webrev.00/ Regards Harsha

Re: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

On 12/08/2016 11:25 AM, Daniel D. Daugherty wrote: David, Sorry I forgot to respond before I left for Santa Fe, NM... More below... No problem. On 8/8/16 5:57 PM, David Holmes wrote: Hi Dan, Thanks for the review. On 9/08/2016 2:07 AM, Daniel D. Daugherty wrote: On 8/4/16 8:28 PM, David

Re: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

David, Sorry I forgot to respond before I left for Santa Fe, NM... More below... On 8/8/16 5:57 PM, David Holmes wrote: Hi Dan, Thanks for the review. On 9/08/2016 2:07 AM, Daniel D. Daugherty wrote: On 8/4/16 8:28 PM, David Holmes wrote: Hi Volker, Thanks for looking at this. On 5/08/20

Re: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file

Hi Dmitry, On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: David, Please see updated webrev. http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ I didn't touch windows version because it quite different from *NIX one. Do we ever see failures on Windows? Is so we should add diagnost

Re: RFR(XXXS): 8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently

Added back serviceability-dev@... The "reply to list" option usually only replies to one of the lists when more than one is specified... One of the few cases where "reply to all" is useful... :-) Thanks Harold! Dan On 8/11/16 12:59 PM, harold seigel wrote: Looks good! Harold On 8/11/2016 1

RFR(XXXS): 8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently

Greetings, I'm quarantining a test that hung in the 2016-08-09 and 2016-08-10 JDK9-hs nightlies: JDK-8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently https://bugs.openjdk.java.net/browse/JDK-8163879 $ hg diff diff -r 14f97d7574bf test/se

Re: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file

David, Please see updated webrev. http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ I didn't touch windows version because it quite different from *NIX one. -Dmitry On 2016-08-08 02:40, David Holmes wrote: > Hi Dmitry, > > On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >> Everybody

Re: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Looks fine; thanks, -Joe On 8/10/2016 11:30 PM, John Jiang wrote: Hi, Please review another updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all The above line shouldn't be removed, and 8031555 should be replaced by 690212

Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap

Hi Jini, I added this check in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ Thanks, Yasumasa On 2016/08/11 15:33, Jini Susan George wrote: Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your c

RE: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames

Thank you, Dmitry ! -jini > -Original Message- > From: Dmitry Samersoff > Sent: Thursday, August 11, 2016 12:50 PM > To: Jini Susan George; serviceability-dev@openjdk.java.net; Lindenmaier, > Goetz > Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames in > SA due to

Re: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames

Jini, Looks good for me! -Dmitry On 2016-08-11 08:57, Jini Susan George wrote: > Thank you very much, Dmitry for the review. I have created a new webrev with > a launchJStack() method in BasicLauncherTest.java. The exit value is 0, > despite the error -- so that does not help. Please do take