Re: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g

2016-04-19 Thread Yasumasa Suenaga
Hi David, > You still removed the size bounds checks: > > 190 size_t value = parse_value(value_str); > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { > 192 errstream->print_cr("Invalid option: %s must be in range [0, " > 193 SIZE_FORMAT

Re: RFR(S): JDK-8153278 sun/tools/jps/TestJpsJar.java fails in hs nightly

2016-04-19 Thread David Holmes
Hi Dmitry, On 19/04/2016 11:06 PM, Dmitry Samersoff wrote: Everybody, Please review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8153278/webrev.01/ The test (a) get it's own name then (b) launch JPS and check that it's name is present in the output. If for some reason the

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

2016-04-19 Thread serguei.spit...@oracle.com
On 4/19/16 19:06, serguei.spit...@oracle.com wrote: On 4/19/16 02:22, serguei.spit...@oracle.com wrote: On 4/19/16 02:16, Severin Gehwolf wrote: Hi, On Tue, 2016-04-19 at 01:33 -0700, serguei.spit...@oracle.com wrote: Hi Severin, Please, find my comments below. On 4/15/16 13:52,

Re: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g

2016-04-19 Thread David Holmes
Hi Yasumasa, On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > > I uploaded new webrev. Could you review again? >http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ You still removed the size bounds checks: 190 size_t value =

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

2016-04-19 Thread serguei.spit...@oracle.com
On 4/19/16 02:22, serguei.spit...@oracle.com wrote: On 4/19/16 02:16, Severin Gehwolf wrote: Hi, On Tue, 2016-04-19 at 01:33 -0700, serguei.spit...@oracle.com wrote: Hi Severin, Please, find my comments below. On 4/15/16 13:52, serguei.spit...@oracle.com wrote: On 4/15/16 11:59, Dmitry

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Daniel D. Daugherty
Yup. I saw that after I was caught up with my hg/Mercurial notifications mailbox... My general (unfiltered) Inbox gets priority since that's where code review happen... :-) Dan On 4/19/16 1:23 PM, Robbin Ehn wrote: Hi Dan, This was pushed with: -Xlog:jvmti+objecttagging=debug /Robbin On

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Robbin Ehn
Hi Dan, This was pushed with: -Xlog:jvmti+objecttagging=debug /Robbin On 04/19/2016 06:06 PM, Daniel D. Daugherty wrote: Please, no shorter than 'objtag'. Object needs to be in there somewhere... 'tagging' is just too general. Dan On 4/19/16 5:16 AM, Robbin Ehn wrote: Hi Serguei,

Re: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS

2016-04-19 Thread serguei.spit...@oracle.com
Hi Dmitry, 144 // Clazz become invalid since the time we get the class list 145 // Skip this entry 146 if (error == JVMTI_ERROR_INVALID_CLASS) { 147 continue; 148 } 149 I'd like to better understand the root cause of this issue. Could you, please, give an idea why a class in this test becomes

Re: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS

2016-04-19 Thread serguei.spit...@oracle.com
On 4/19/16 09:42, serguei.spit...@oracle.com wrote: Hi Dmitry, 144 // Clazz become invalid since the time we get the class list 145 // Skip this entry 146 if (error == JVMTI_ERROR_INVALID_CLASS) { 147 continue; 148 } 149 I'd like to better understand the root cause of this issue. Could you,

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Daniel D. Daugherty
Please, no shorter than 'objtag'. Object needs to be in there somewhere... 'tagging' is just too general. Dan On 4/19/16 5:16 AM, Robbin Ehn wrote: Hi Serguei, Thanks! /Robbin On 04/19/2016 12:05 PM, serguei.spit...@oracle.com wrote: Hi Robbin, The fix loos good. I'd like to have the

Re: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS

2016-04-19 Thread Dmitry Samersoff
Any reviewers? On 2016-04-13 19:24, Dmitry Samersoff wrote: > Everybody. > > Please review a small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ > > I don't have a reproducer, so the fix is based on coredump analyzes. > > Tested with rbt > > -Dmitry > > --

Re: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd

2016-04-19 Thread Yasumasa Suenaga
I adapted changes to jdk9/hs/hotspot repos. http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ Please review. Yasumasa On 2016/04/18 23:09, Yasumasa Suenaga wrote: > PING: > > I've sent review request for JDK-8153074. > Could you review it? > >

Re: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g

2016-04-19 Thread Yasumasa Suenaga
Hi David, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ > Which makes me wonder if atomull needs renaming - does the "m" mean > memory? atojulong would seem more appropriate regardless. I renamed to

RFR(S): JDK-8153278 sun/tools/jps/TestJpsJar.java fails in hs nightly

2016-04-19 Thread Dmitry Samersoff
Everybody, Please review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8153278/webrev.01/ The test (a) get it's own name then (b) launch JPS and check that it's name is present in the output. If for some reason the directory from where the test is run changes it name between (a) and

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Robbin Ehn
Hi Serguei, Thanks! /Robbin On 04/19/2016 12:05 PM, serguei.spit...@oracle.com wrote: Hi Robbin, The fix loos good. I'd like to have the tag-set name shorter but prefer "objecttagging" over "tagging". Also, I'm thinking if the tag-set name should include the "jvmti" prefix. But, please, use

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread serguei.spit...@oracle.com
Hi Robbin, The fix loos good. I'd like to have the tag-set name shorter but prefer "objecttagging" over "tagging". Also, I'm thinking if the tag-set name should include the "jvmti" prefix. But, please, use your judgement as it has to be consistent with the overall design. Thanks, Serguei

Re: RFR: 8154041: JVMTI to Unified Logging

2016-04-19 Thread Robbin Ehn
Hi Serguei, Thanks! /Robbin On 04/19/2016 11:47 AM, serguei.spit...@oracle.com wrote: Hi Robbin, The fix looks good. Also, I'm Ok with the removal of comments. Thanks, Serguei On 4/19/16 02:43, Robbin Ehn wrote: Hi Marcus, On 04/19/2016 11:07 AM, Marcus Larsson wrote: Hi, On

Re: RFR: 8154041: JVMTI to Unified Logging

2016-04-19 Thread serguei.spit...@oracle.com
Hi Robbin, The fix looks good. Also, I'm Ok with the removal of comments. Thanks, Serguei On 4/19/16 02:43, Robbin Ehn wrote: Hi Marcus, On 04/19/2016 11:07 AM, Marcus Larsson wrote: Hi, On 04/14/2016 01:36 PM, Robbin Ehn wrote: Hi all, Please review: This moves jvmti trace output to

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Robbin Ehn
Hi Marcus, On 04/19/2016 11:16 AM, Marcus Larsson wrote: Hi, On 04/14/2016 01:52 PM, Robbin Ehn wrote: Hi all, Please review: This moves jvmti object-tagging output to the tag-set jvmti,objecttagging on debug level. The TraceJVMTIObjectTagging argument is deprecated and aliased with:

Re: RFR: 8154041: JVMTI to Unified Logging

2016-04-19 Thread Robbin Ehn
Hi Marcus, On 04/19/2016 11:07 AM, Marcus Larsson wrote: Hi, On 04/14/2016 01:36 PM, Robbin Ehn wrote: Hi all, Please review: This moves jvmti trace output to the tag jvmti on trace level. The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have a lot of functionality, e.g.

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

2016-04-19 Thread Severin Gehwolf
Hi, On Tue, 2016-04-19 at 01:33 -0700, serguei.spit...@oracle.com wrote: > Hi Severin, > > Please, find my comments below. > > On 4/15/16 13:52, serguei.spit...@oracle.com wrote: > > On 4/15/16 11:59, Dmitry Samersoff wrote:  > > > Severin,  > > > > > > Looks good for me.  > > > > > > But I'm

Re: RFR: 8154059: JVMTI ObjectTagging to UL

2016-04-19 Thread Marcus Larsson
Hi, On 04/14/2016 01:52 PM, Robbin Ehn wrote: Hi all, Please review: This moves jvmti object-tagging output to the tag-set jvmti,objecttagging on debug level. The TraceJVMTIObjectTagging argument is deprecated and aliased with: "-Xlog:jvmti+objecttagging=debug" Did this on top of:

Re: RFR: 8154041: JVMTI to Unified Logging

2016-04-19 Thread Marcus Larsson
Hi, On 04/14/2016 01:36 PM, Robbin Ehn wrote: Hi all, Please review: This moves jvmti trace output to the tag jvmti on trace level. The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have a lot of functionality, e.g. can filter on func, in/out, etc, so it if left as is.

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

2016-04-19 Thread serguei.spit...@oracle.com
Hi Severin, Please, find my comments below. On 4/15/16 13:52, serguei.spit...@oracle.com wrote: On 4/15/16 11:59, Dmitry Samersoff wrote: Severin, Looks good for me. But I'm a little afraid of the fact that now we are holding eventHandler_lock while doing invoke*. It seems, I have this