Re: RFR [9] 8153737: Unsupported Module

2016-04-07 Thread Mandy Chung
> On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc

Re: RFR [9] 8153737: Unsupported Module

2016-04-07 Thread Alan Bateman
On 07/04/2016 18:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the

Re: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing

2016-04-07 Thread serguei.spit...@oracle.com
Dmitry, I agree with Tim. The message at L85 should not be alarming but look similar to the one at L107. Something, like this: 85System.out.println("This test is not expected to work on OS X. Skipping"); Thanks, Serguei On 4/7/16 11:13, Tim Bell wrote: On 04/07/16 10:56,

Re: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing

2016-04-07 Thread Tim Bell
On 04/07/16 10:56, Dmitry Samersoff wrote: Everybody, Please review small changes. Note: I am not a "R"eviewer in Serviceability. Free advice follows: http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ Test that is not expected to work on OS X, detect OS X and exits. 84

RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing

2016-04-07 Thread Dmitry Samersoff
Everybody, Please review small changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ Test that is not expected to work on OS X, detect OS X and exits. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but

RFR [9] 8153737: Unsupported Module

2016-04-07 Thread Chris Hegarty
Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized

RE: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

2016-04-07 Thread Cheleswer Sahu
Thanks Dmitry and Leonid for review. Thanks Dan for information, I will do the needful before pushing this fix. Regards, Cheleswer -Original Message- From: Daniel D. Daugherty Sent: Thursday, April 07, 2016 7:52 PM To: Dmitry Samersoff; Cheleswer Sahu; Leonid Mesnik;

Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

2016-04-07 Thread Daniel D. Daugherty
Cheleswer, When you re-sync with the current JDK9-hs-rt, you'll have to re-enable this test. It was quarantined yesterday with this fix: JDK-8153671 Quarantine serviceability/tmtools/jstack/JstackThreadTest.java until JDK-8153319 is fixed

Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

2016-04-07 Thread Dmitry Samersoff
Cheleswer, Looks good for me. Reviewed. -Dmitry On 2016-04-07 16:50, Cheleswer Sahu wrote: > Hi , > Thanks for your review and suggestion. I agree that sleep is not the best and > reliable way to achieve the objective of test case. I also found the idea of > using j.u.c.CountDownLatch very

Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

2016-04-07 Thread Leonid Mesnik
Hi Thank you for improving test stability. I am fine with fix. I am not 'R'eviewer so you still need to get official review. Leonid On 07.04.2016 16:50, Cheleswer Sahu wrote: Hi , Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the

RE: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

2016-04-07 Thread Cheleswer Sahu
Hi , Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

2016-04-07 Thread Dmitry Fazunenko
Per, On 07.04.2016 14:55, Per Liden wrote: On 2016-04-07 13:24, Dmitry Fazunenko wrote: Hi Per, The fix looks good, but a couple of suggestions regarding: Thanks Dima! GcCapacityTest.java.frames.html 1) -Xmx128 --> -Xmx128m Ah, thanks for catching that! 2) Remove @ignore 8149778

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

2016-04-07 Thread Per Liden
On 2016-04-07 13:24, Dmitry Fazunenko wrote: Hi Per, The fix looks good, but a couple of suggestions regarding: Thanks Dima! GcCapacityTest.java.frames.html 1) -Xmx128 --> -Xmx128m Ah, thanks for catching that! 2) Remove @ignore 8149778 Adding -Xmx should fix 8149778 as well. I

Re: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

2016-04-07 Thread Dmitry Fazunenko
Hi Per, The fix looks good, but a couple of suggestions regarding: GcCapacityTest.java.frames.html 1) -Xmx128 --> -Xmx128m 2) Remove @ignore 8149778 Adding -Xmx should fix 8149778 as well. Thanks, Dima On 06.04.2016 12:32, Per Liden wrote: Summary: This patch updates the tests in