Re: Review quest for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently

Hi Mandy, Yes, I have tested and all settings are passed, as you mentioned the test hangs with -XX:+UseG1GC -XX:+ExplicitGCInvokesConcurrent and default heap size as no GC happens on Old Gen. That is why to add -Xmx2m and big object to make sure GC happens. I didn't realized the -Xconcgc is

hg: jdk8/tl/jdk: 8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout

Changeset: 5ac7cd164300 Author:juh Date: 2013-11-27 15:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ac7cd164300 8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout Reviewed-by: xuelei, wetmore Contributed-by: rajan.hal...@oracle.com ! test/su

Re: RFR 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS

Thumbs up Mandy > On Nov 27, 2013, at 1:15 PM, Jaroslav Bachorik > wrote: > > Thanks for looking at this, Mandy. > > Here is the patch with added explanatory comments - > http://cr.openjdk.java.net/~jbachorik/6987597/webrev.05 > > -JB- > >> On 27.11.2013 21:33, Mandy Chung wrote: >>> On 11

Re: RFR 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS

Thanks for looking at this, Mandy. Here is the patch with added explanatory comments - http://cr.openjdk.java.net/~jbachorik/6987597/webrev.05 -JB- On 27.11.2013 21:33, Mandy Chung wrote: On 11/27/2013 10:41 AM, Jaroslav Bachorik wrote: Hi, I've uploaded the patch with the minimal changes

Re: RFR 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS

On 11/27/2013 10:41 AM, Jaroslav Bachorik wrote: Hi, I've uploaded the patch with the minimal changes that should resolve this particular problem. http://cr.openjdk.java.net/~jbachorik/6987597/webrev.04 Looks good. I'm happy to see this simple change resolves the issue. It would be usefu

Re: RFR 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS

Hi, I've uploaded the patch with the minimal changes that should resolve this particular problem. http://cr.openjdk.java.net/~jbachorik/6987597/webrev.04 -JB- On 22.11.2013 14:57, Jaroslav Bachorik wrote: On 21.11.2013 17:51, Mandy Chung wrote: Hi Jaroslav, On 11/19/2013 6:23 AM, Jaroslav

hg: jdk8/tl/jdk: 8028771: regression test java/util/Locale/LocaleProviders.sh failed

Changeset: 2370d285d08b Author:naoto Date: 2013-11-27 10:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2370d285d08b 8028771: regression test java/util/Locale/LocaleProviders.sh failed Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale

Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40

Hi, Markus I think the bug report should link to 8005849 which introduced this additional check and regression. Is it possible to prepare a jtreg test which will use AsynchGetCallTrace and catch such situations in a future? The fix itself looks good. Thanks, Vladimir On 11/27/13 1:47 AM,

Re: Codereview request: 8029063 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds

On 11/27/13 4:41 PM, shanliang wrote: This is a simple test fix, have to remove the test in OpenJDK because the SNMP classes in the OpenJDK will not be compiled if the closed part is not present. looks good. -- daniel

Re: Codereview request: 8029063 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds

On 27/11/2013 15:41, shanliang wrote: This is a simple test fix, have to remove the test in OpenJDK because the SNMP classes in the OpenJDK will not be compiled if the closed part is not present. Deleting it make sense, thumbs up from me. -Alan.

Codereview request: 8029063 test/com/sun/jmx/snmp/NoInfoLeakTest.java does not compile with OpenJDK builds

This is a simple test fix, have to remove the test in OpenJDK because the SNMP classes in the OpenJDK will not be compiled if the closed part is not present. diff8029063-open Description: video/flv

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

I think test should test instrumentation of custom, JDK, JDK shared classes as a part of scenario. This is how tools could use this mechanism. May be I am wrong. Also I found * JDK-5002268 Allow class sharing use with RedefineClasses which

hg: hsx/hotspot-rt/hotspot: 7050685: jsdbproc64.sh has a typo in the package name

Changeset: 8a42e81e2f9d Author:dsamersoff Date: 2013-11-27 14:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a42e81e2f9d 7050685: jsdbproc64.sh has a typo in the package name Summary: fixed typeo Reviewed-by: sla, kmo, sspitsyn ! agent/make/jsdbproc64.sh

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

According to the test documentation and bug references the test verifies the manifest attribute "Can-Redefine-Classes". The test does not mention shared class archive or -Xshare. But maybe the test has found a problem accidentally... Mattias - Original Message - From: david.hol...@oracle

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

On 27 nov 2013, at 12:21, David Holmes wrote: > On 27/11/2013 8:46 PM, Mattias Tobiasson wrote: >> Hi, I now have a reproducer for this test that fails every time. >> I just need to verify that it really is a test bug and not a product bug. >> >> This is a summary of the test: >> 1. It loads a

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

On 27/11/2013 8:46 PM, Mattias Tobiasson wrote: Hi, I now have a reproducer for this test that fails every time. I just need to verify that it really is a test bug and not a product bug. This is a summary of the test: 1. It loads a javaagent jar that implements ClassFileTransformer. 2. The agent

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

Hi, I now have a reproducer for this test that fails every time. I just need to verify that it really is a test bug and not a product bug. This is a summary of the test: 1. It loads a javaagent jar that implements ClassFileTransformer. 2. The agent loads class java.math.BigInteger and expects a ca

Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40

On 11/27/13 2:32 AM, Markus Gronlund wrote: Hi Sergei, I have already worked with Nik on this issue and got his confirmation on the fix. Cool! Thanks, Serguei Thanks Markus *From:*Serguei Spitsyn *Sent:* den 27 november 2013 11:31 *To:* Markus Gronlund; hotspot-compiler-...@openjdk.ja

RE: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40

Hi Sergei, I have already worked with Nik on this issue and got his confirmation on the fix. Thanks Markus From: Serguei Spitsyn Sent: den 27 november 2013 11:31 To: Markus Gronlund; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; serviceability-dev Cc:

Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40

Hi Markus, The fix looks Ok. It'd be helpful if Oleg and the Solaris Studio guys could confirm this fix works fine for them. I've added Oleg and Nik to the CC-list. They might request a link to the Solaris or Linux binaries. Thanks, Serguei On 11/27/13 1:47 AM, Markus Gronlund wrote: Gree

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Thanks, Dmitry! Serguei On 11/27/13 2:13 AM, Dmitry Samersoff wrote: Serguei, Thank you for the explanation. Looks good for me. -Dmitry On 2013-11-27 13:31, serguei.spit...@oracle.com wrote: Dmitry, Thank you for reviewing! On 11/27/13 12:08 AM, Dmitry Samersoff wrote: Serguei, Is it bet

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Serguei, Thank you for the explanation. Looks good for me. -Dmitry On 2013-11-27 13:31, serguei.spit...@oracle.com wrote: > Dmitry, > > Thank you for reviewing! > > On 11/27/13 12:08 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Is it better to just convert >> assert at ll. 273 into if (vf !=

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Hi David, Thank you for the review! On 11/27/13 1:04 AM, David Holmes wrote: Hi Serguei, This looks fine to me. Definitely low risk but not sure it is critical enough for 8. Thanks. The priority is high and it impacts the tests stabilization as some other tests may potentially intermittent

RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40

Greetings, Kindly asking for reviews for the following change: Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ Description: AsynchGetCallTrace() uses platform specific code for stack frame traversals. On x86

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Dmitry, Thank you for reviewing! On 11/27/13 12:08 AM, Dmitry Samersoff wrote: Serguei, Is it better to just convert assert at ll. 273 into if (vf != NULL) ... ? Your suggestion does not help as we hit another assert in the call to last_java_vframe(): javaVFrame* vf = _thread->last_jav

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Hi Serguei, This looks fine to me. Definitely low risk but not sure it is critical enough for 8. Minor nit: _method_id = (jmethodID)NULL; It should never be necessary to cast NULL if assigning to a pointer type. Thanks, David On 27/11/2013 11:34 AM, serguei.spit...@oracle.com wrote: Plea

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Thanks, Staffan! Serguei On 11/27/13 12:07 AM, Staffan Larsen wrote: Looks good! The fix looks safe enough to include in jdk8, however this does not look like a recent regression - the bug must have been there for a long time. Let’s try to get it approved for jdk8. Thanks, /Staffan On 27 no

Re: RFR (S): 6461635: [TESTBUG] BasicTests.sh test fails intermittently

Hi Generally I am ok with your comments and fix. However you still needed to get official review. The only question is about failure related from retransformation of j.l.BigInteger with CDS. Could it be JDK issue? In this case it would be better to file it as a part of fix. I understand that

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Serguei, Is it better to just convert assert at ll. 273 into if (vf != NULL) ... ? -Dmitry On 2013-11-27 05:34, serguei.spit...@oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8028126 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/

Re: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

Looks good! The fix looks safe enough to include in jdk8, however this does not look like a recent regression - the bug must have been there for a long time. Let’s try to get it approved for jdk8. Thanks, /Staffan On 27 nov 2013, at 02:34, serguei.spit...@oracle.com wrote: > Please, review th