Re: RFR 8034168: ThreadMXBean/Locks.java failed, blocked on wrong object

2014-02-18 Thread Jaroslav Bachorik
On 18.2.2014 18:06, Martin Buchholz wrote: Not checking any details, but tests that want to wait for a particular thread state are a good reason to use volatile boolean flag; ... while (!flag) Thread.yield(); I prefer calling Thread.yield to sleeping in this special case, in part because I don'

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread shanliang
I am looking at the old file: 143 while (bkptCount < maxBkpts) { 144 prevBkptCount = bkptCount; suppose the following execution sequence: 1) when Line 143 was called by Thread1, we had bkptCount == maxBkpts - 1; 2) bkptCount++ was executed by thread2; 3) Line 144 was calle

JDK-8005604, instance size/metaspace data in HPROF

2014-02-18 Thread Vladimir Sitnikov
Seems like HPROF does not include information on non-heap memory. It would be nice to have accurate class size (e.g. with @Contended), space wastage, permgen/metaspace (e.g. constant pool size or whatever is in C-heap), code cache blobs in the heap dump. Alexey Shipilёv raised similar question reg

Re: 8034856/8034857: More gcc warnings

2014-02-18 Thread Mikael Vidstedt
On 2014-02-18 00:33, Alan Bateman wrote: On 18/02/2014 03:59, Mikael Vidstedt wrote: How about: http://cr.openjdk.java.net/~mikael/webrevs/isspace/webrev.00/webrev/ Cheers, Mikael I checked the java.lang.instrument spec and for the Boot-Class-Path attribute then it doesn't say any more tha

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread David Holmes
On 18/02/2014 11:03 PM, Staffan Larsen wrote: On 18 feb 2014, at 13:09, David Holmes wrote: Hi Staffan, If you get a spurious wakeup from wait(): 151 try { 152 synchronized (bkptSignal) { 153 bkptSignal.wait(5000); 154 } 155

RFR 8034168: ThreadMXBean/Locks.java failed, blocked on wrong object

2014-02-18 Thread Jaroslav Bachorik
Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8034168 Webrev: http://cr.openjdk.java.net/~jbachorik/8034168/webrev.00 The test fails because of falsely evaluating the thread being parked as actually waiting on a monitor. This is because there is no d

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread Staffan Larsen
On 18 feb 2014, at 13:09, David Holmes wrote: > Hi Staffan, > > If you get a spurious wakeup from wait(): > > 151 try { > 152 synchronized (bkptSignal) { > 153 bkptSignal.wait(5000); > 154 } > 155 } catch (InterruptedE

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread David Holmes
Hi Staffan, If you get a spurious wakeup from wait(): 151 try { 152 synchronized (bkptSignal) { 153 bkptSignal.wait(5000); 154 } 155 } catch (InterruptedException ee) { 156 } 157 if (prevBk

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread serguei.spit...@oracle.com
The fix looks good. Thanks, Serguei On 2/18/14 2:19 AM, Staffan Larsen wrote: Still looking for Reviewer for this change. Thanks, /Staffan On 11 feb 2014, at 15:12, Staffan Larsen wrote: Updated the test to use proper synchronization and notification between threads. Should be more stable

Re: RFR(S): 6952105 TEST_BUG: testcase failure, not very often, com/sun/jdi/SuspendThreadTest.java

2014-02-18 Thread Staffan Larsen
Still looking for Reviewer for this change. Thanks, /Staffan On 11 feb 2014, at 15:12, Staffan Larsen wrote: > Updated the test to use proper synchronization and notification between > threads. Should be more stable and much faster. > > bug: https://bugs.openjdk.java.net/browse/JDK-6952105 >

Re: RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException

2014-02-18 Thread serguei.spit...@oracle.com
On 2/17/14 12:04 AM, Jaroslav Bachorik wrote: On 14.2.2014 23:13, serguei.spit...@oracle.com wrote: On 2/14/14 12:33 PM, Daniel D. Daugherty wrote: On 2/14/14 11:46 AM, serguei.spit...@oracle.com wrote: Jaroslav, It looks good in general modulo indent comments from Dan. But I have a doubt th

Re: RFR(XS): JDK-4515292: ReferenceType.isStatic() returns true for arrays

2014-02-18 Thread Staffan Larsen
Looks good! Thanks, /Staffan On 17 feb 2014, at 10:46, Fredrik Arvidsson wrote: > Hi please review this minor JDI fix. > > This bug was found when investigating failing JDI tests. According to the > JavaDoc all calls to ReferenceType when it is an array type should return > false for isStat

RFR(XS): JDK-8034203: Change JavaDoc for com.sun.jdi.request.EventRequest.setEnabled(boolean val)

2014-02-18 Thread Fredrik Arvidsson
Hi Please help me review this small change: This is a minor change to the JavaDoc in the JDI API. The problem was discovered when trying to fix a failing test. Webrev: 8034203 Bug: JDK-8034203

Re: RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException

2014-02-18 Thread David Holmes
On 18/02/2014 6:47 PM, Jaroslav Bachorik wrote: Hi David, On 18.2.2014 06:28, David Holmes wrote: Hi Jaroslav, It seems to me that this issue extends to other places in the VM. In particular class initialization in instanceKlass.cpp - anywhere that one exception is "caught" in the VM and then

Re: 8034856/8034857: More gcc warnings

2014-02-18 Thread Dmitry Samersoff
Mikael, > http://cr.openjdk.java.net/~mikael/webrevs/isspace/webrev.00/webrev/ 1. I agree that ctypes isspace usually cause more problems than solve and it's good to have our own version. 2. one of possible implementation is #define isspaceASCII(c) (strchr(SPACE_CHARS,c) != NULL) -Dmitry On

Re: RFR 4505697: nsk/jdi/ExceptionEvent/_itself_/exevent006 and exevent008 tests fail with InvocationTargetException

2014-02-18 Thread Jaroslav Bachorik
Hi David, On 18.2.2014 06:28, David Holmes wrote: Hi Jaroslav, It seems to me that this issue extends to other places in the VM. In particular class initialization in instanceKlass.cpp - anywhere that one exception is "caught" in the VM and then wrapped with, or replaced by, another exception,

Re: 8034856/8034857: More gcc warnings

2014-02-18 Thread Alan Bateman
On 18/02/2014 03:59, Mikael Vidstedt wrote: How about: http://cr.openjdk.java.net/~mikael/webrevs/isspace/webrev.00/webrev/ Cheers, Mikael I checked the java.lang.instrument spec and for the Boot-Class-Path attribute then it doesn't say any more than "space". It might be worth checking the