Re: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar

Looks good! nit: test/com/sun/jdi/ShellScaffold.sh:947, the alignment for ">&2” got broken. Thanks, /Staffan > On 28 jan 2015, at 17:24, Alexander Kulyakhtin > wrote: > > Hi, > > Could you, please, review the fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071464 > webrev: ht

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

Hi Dmitry, It looks good in general. src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c I agree with David, the fix needs the "END_WITH_LOCAL_REFS(env);" before the line 50. src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c 159 * It never throws OOM Minor: Could yo

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

On 1/29/15 12:06 AM, serguei.spit...@oracle.com wrote: Hi Dmitry, It looks good in general. In fact, I've reviewed the webrev.3 (but replied on the wrong email with webrev.2): http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ Thanks, Serguei src/jdk.jdwp.agent/share/native

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

Serguei, Thanks. -Dmitry On 2015-01-29 11:10, serguei.spit...@oracle.com wrote: > > > On 1/29/15 12:06 AM, serguei.spit...@oracle.com wrote: >> Hi Dmitry, >> >> >> It looks good in general. > > In fact, I've reviewed the webrev.3 (but replied on the wrong email with > webrev.2): > http://cr

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

David, Agree! Will change it. -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >> >> done. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.0

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

David, Fixed in place (press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return?

Re: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans

On 28/01/15 07:46, Mandy Chung wrote: com/sun/management/internal/PlatformMBeanProviderImpl.java line 43: does this mxbeanList have to be created lazily? Would it be better to make it a final field and create it at the constructor? Hi Mandy, I was the one to suggest the lazy initializa

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

Looks good. Thanks, David On 29/01/2015 8:29 PM, Dmitry Samersoff wrote: David, Fixed in place (press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ -Dmitry On 2015-01-29 10:26, David Holmes wrote: On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: David, Don'

Re: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar

Hi Katja, Stafan I've corrected the alignment issue, per Stafan's review, and attached the patch. Could it be possible to push the patch? Thank you very much for your help. Best regards, Alex - Original Message - From: staffan.lar...@oracle.com To: alexander.kulyakh...@oracle.com Cc:

Re: RFR 8068976: Remove JSDT implementation

Looks good to me. Thanks, /Staffan > On 14 jan 2015, at 15:05, Jaroslav Bachorik > wrote: > > Please, review the following removal of functionality. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068976 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068976/webrev.00 > > JDK-8062303

Re: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar

Alex, I'll push. // Katja On 01/29/2015 01:21 PM, Alexander Kulyakhtin wrote: Hi Katja, Stafan I've corrected the alignment issue, per Stafan's review, and attached the patch. Could it be possible to push the patch? Thank you very much for your help. Best regards, Alex - Original Mess

RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ The test fails very intermittently with NPE. This seems to be caused by a data race between Thread.getStatus() and ThreadMXBean.get

RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined

Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071784 webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ Thanks, Katja

Re: RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined

Looks good! -JB- On 29.1.2015 14:23, Yekaterina Kantserova wrote: Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071784 webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ Thanks, Katja

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

Jaroslav Bachorik wrote: Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ The test fails very intermittently with NPE. This seems to be caused by a data race between Thread.getSta

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

Hi Jaroslav, The only thread state that this test is waiting on seems to be Thread.State.BLOCKED - which makes me wonder if you could add a method: String waitForBlockedState(Thread t) throws InterruptedException { long tid = lt.getId(); ThreadInfo ti; while ( (ti = mbean.getThreadInf

Re: RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined

Looks good! Thanks, /Staffan > On 29 jan 2015, at 14:23, Yekaterina Kantserova > wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071784 > webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ > > Thanks, >

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

On 29.1.2015 14:58, Daniel Fuchs wrote: Hi Jaroslav, The only thread state that this test is waiting on seems to be Thread.State.BLOCKED - which makes me wonder if you could add a method: String waitForBlockedState(Thread t) throws InterruptedException { long tid = lt.getId(); ThreadInf

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

On 29.1.2015 14:43, shanliang wrote: Jaroslav Bachorik wrote: Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ The test fails very intermittently with NPE. This seems to be caused

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

On 29/01/15 16:21, Jaroslav Bachorik wrote: On 29.1.2015 14:58, Daniel Fuchs wrote: Hi Jaroslav, The only thread state that this test is waiting on seems to be Thread.State.BLOCKED - which makes me wonder if you could add a method: String waitForBlockedState(Thread t) throws InterruptedExcepti

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

On 29.1.2015 16:44, Daniel Fuchs wrote: On 29/01/15 16:21, Jaroslav Bachorik wrote: On 29.1.2015 14:58, Daniel Fuchs wrote: Hi Jaroslav, The only thread state that this test is waiting on seems to be Thread.State.BLOCKED - which makes me wonder if you could add a method: String waitForBlocked

Re: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE

Jaroslav Bachorik wrote: On 29.1.2015 14:43, shanliang wrote: Jaroslav Bachorik wrote: Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ The test fails very intermittently with NP

Review request: Backport of JDK-8046282 to 8u

Hello, Review request for the backport of 8046282 to 8u: Bug: JDK-8046282 SA update Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ Thanks, Poonam

Re: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans

On 1/29/15 3:07 AM, Daniel Fuchs wrote: On 28/01/15 07:46, Mandy Chung wrote: com/sun/management/internal/PlatformMBeanProviderImpl.java line 43: does this mxbeanList have to be created lazily? Would it be better to make it a final field and create it at the constructor? Hi Mandy, I w

Re: RFR 8068976: Remove JSDT implementation

Looks good to me. Do you plan to push the jdk side change to remove com.sun.tracing together with the hotspot change? I notice that you have a separate bug JDK-8062303 for jdk change. It's fine to choose to do. It'd also be fine to push the jdk change together with this hotspot change. M

RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Hi, Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive”. In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

On 1/29/15 5:13 PM, Jiangli Zhou wrote: Hi, Please review the change for JDK-8071962 , "The SA code needs to be updated to support Symbol lookup from the shared archive”. In JDK-8059510 , we

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Hi Serguei, Thanks for noticing that. It’s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. Thanks, Jiangli On Jan 29, 2015, at 5:40 PM, serguei.spit...@oracle.com wrote: > On 1/29/15 5:13 PM, Jiangli Zhou wrote

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Hi Jiangli, Thank you for fixing this! Serguei On 1/29/15 5:46 PM, Jiangli Zhou wrote: Hi Serguei, Thanks for noticing that. It’s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Looks good to me. Not a 'R'eviwer. Thanks Yumin On 1/29/2015 5:46 PM, Jiangli Zhou wrote: Hi Serguei, Thanks for noticing that. It’s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. Thanks, Jiangli On Jan 29,

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Hi Yumin, Thank you for the quick review! Jiangli On Jan 29, 2015, at 6:03 PM, Yumin Qi wrote: > Looks good to me. Not a 'R'eviwer. > > Thanks > Yumin > > On 1/29/2015 5:46 PM, Jiangli Zhou wrote: >> Hi Serguei, >> >> Thanks for noticing that. It’s actually a duplicated bug ID for the same

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Jiangli, The fix looks good. One minor comment/question though. It looks like the comment needs an update as it does not return null anymore if the string has not been found in the symbol table. agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java @@ -74,20 +81,23 @@ /** Clone of