Re: [RFR]8215623: Add incremental dump for jmap histo

On 5/13/19 23:46, 臧琳 wrote: Dear Serguei, Thanks for your comments. > > - incremental[:], enable the incremental dump of heap, dumped > > data will be saved to, by default it is "IncrementalHisto.dump" > > Q1: Should the be full path or short name? >

Re: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0

Hi Coleen, Looks good to me. Thanks, Serguei On 5/15/19 10:04, Jean Christophe Beyler wrote: Hi Coleen, Looks good to me (not an official reviewer), Jc *From: *Vladimir Kozlov *Date: *Wed, May 15, 2019 at 9:34 AM *To: * , hotspot-dev developers, serviceability-dev@openjdk.java.net Looks

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi Jc, On 5/15/19 19:57, Jean Christophe Beyler wrote: Hi both, For the linux question, I was doing that less for the AGCT code itself but more for the dlsym I was doing in the test; I was

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi JC, That will work for now, but if support for other OSes is added, separating out the OS and CPU requirements won't work. You will need a list out each && combo that is supported. I guess that can wait until it's needed. I leave it up to you

Re: RFR: 8223666: SA: debugd options should follow jhsdb style

Hi Osamu, On 5/15/19 19:45, Osamu Sakamoto wrote: Hi Serguei, > I'm Okay with the fix. Thank you for reviewing. I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status of CSR changes to Approved Great! > But we have to use correct subject line which includes bug number and

RFR: 8223666: SA: debugd options should follow jhsdb style

Hi Serguei, > I'm Okay with the fix. Thank you for reviewing. I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status of CSR changes to Approved > But we have to use correct subject line which includes bug number and > the exact bug title. > Otherwise, these emails are not

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi Jc, I'm Okay with this fix in general modulo some suggestion from Chris below. On 5/15/19 18:49, Chris Plummer wrote: Hi JC, Looks like s390 is also not supported. Do we know for usre if it is implemented

Re: debugd options should regard to jhsdb style

Hi Osamu, I'm Okay with the fix. But we have to use correct subject line which includes bug number and the exact bug title. Otherwise, these emails are not searchable by the bug number. Thanks, Serguei On 5/15/19 17:57, 坂本 統 wrote: Hi Serguei, Do you think which is better, to add angle

Re: debugd options should regard to jhsdb style

On 5/15/19 18:20, serguei.spit...@oracle.com wrote: Hi Osamu, On 5/14/19 00:21, Osamu Sakamoto wrote: Hi Serguei, Thank you for reviewing the CSR. I answer your questions. Q1 & Q2: and can accept both full path and relative path. It has to be clear in the help. I've updated the CSR

Re: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null

LGTM too :) *From: *Chris Plummer *Date: *Wed, May 15, 2019 at 6:55 PM *To: *Daniil Titov, David Holmes, Jean Christophe Beyler *Cc: *OpenJDK Serviceability LGTM > > Chris > > On 5/15/19 12:15 PM, Daniil Titov wrote: > > Hi David, Chris, and JC, > > > > Please review a new version of the change

Re: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null

LGTM Chris On 5/15/19 12:15 PM, Daniil Titov wrote: Hi David, Chris, and JC, Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi JC, Looks like s390 is also not supported. Do we know for usre if it is implemented on other architectures, like aarch64? I wouldn't necessarily rely on the lack of a negative comment in JavaThread::pd_get_top_frame_for_signal_handler() to determine

Re: debugd options should regard to jhsdb style

Hi Osamu, On 5/14/19 00:21, Osamu Sakamoto wrote: Hi Serguei, Thank you for reviewing the CSR. I answer your questions. Q1 & Q2: and can accept both full path and relative path. It has to be clear in the help. I've updated the CSR with this. Q3: Other commands

RE: debugd options should regard to jhsdb style

Hi Serguei, Do you think which is better, to add angle bracket or not to? > By the way, you've added angle brackets to jhsdb debugd --help in the CSR. > But current other commands --help don't have it. > I think this modification should be also added to other commands --help if it > is added to

Re: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA)

Hi Robbin, Looks good to me. Thanks, Serguei On 5/14/19 07:02, Robbin Ehn wrote: Hi Dan, Full: http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html Inc: http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html On 2019-05-08 18:02, Daniel D. Daugherty wrote: General

Re: RFR: 8221707: JDWP support for IPv6 - spec update

Hi Alex, The fix looks good to me. Thanks, Serguei On 5/15/19 14:07, Alex Menkov wrote: Hi all, Please review the fix for "Connection and Invocation Details" page related to JDWP IPv6 support implementation. JBS: https://bugs.openjdk.java.net/browse/JDK-8221707 webrev:

RFR: 8221707: JDWP support for IPv6 - spec update

Hi all, Please review the fix for "Connection and Invocation Details" page related to JDWP IPv6 support implementation. JBS: https://bugs.openjdk.java.net/browse/JDK-8221707 webrev: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/webrev/ resulting docs: old:

Re: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null

Hi David, Chris, and JC, Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the common code that iterates over all loaded types while

Re: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0

Thanks Vladimir! Coleen On 5/15/19 12:34 PM, Vladimir Kozlov wrote: Looks good. Thanks, Vladimir On 5/15/19 6:46 AM, coleen.phillim...@oracle.com wrote: Summary: adjust old method table by only one thread. Entries were removed from the redefinition old method table by G1 by multiple

Re: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0

Thanks JC! Coleen On 5/15/19 1:04 PM, Jean Christophe Beyler wrote: Hi Coleen, Looks good to me (not an official reviewer), Jc *From: *Vladimir Kozlov > *Date: *Wed, May 15, 2019 at 9:34 AM *To: * >, hotspot-dev

Re: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0

Looks good. Thanks, Vladimir On 5/15/19 6:46 AM, coleen.phillim...@oracle.com wrote: Summary: adjust old method table by only one thread. Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the CodeCache_lock. Moved the removal

Re: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA)

Still looks good.  I guess we'll not have any lambdas to cut and paste in the SA now. Do you no longer need this? 191 public interface JavaThreadsDo { 192 void doJavaThread(JavaThread thread); 193 } 194 195 public void doJavaThreads(JavaThreadsDo jtDo) { 196 for (int i = 0; i <

RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0

Summary: adjust old method table by only one thread. Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the CodeCache_lock. Moved the removal to nmethod->flush().  The bug is confidential because there's a confidential comment

Re: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA)

On 2019-05-15 14:59, David Holmes wrote: Lambdas removed! I got caught out by the cumulative patch file again :( Changes look good! Thanks David! /Robbin src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java Existing: 76 JavaThread cur =

Re: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA)

Hi Robbin, On 15/05/2019 12:08 am, Robbin Ehn wrote: Hi David, Full: http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html Inc: http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html On 2019-05-09 06:46, David Holmes wrote: As Dan also hints at you are a bit inconsistent

Re: PING: Re: RFR: JDK-8184770: JDWP support for IPv6

Alex, On 13/05/2019 22:06, Alex Menkov wrote: Hi Chris, Serguei, Updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/ I'm ok with this version. CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8223104 Changes (vs. webrev.04): - setsockopt(IPV6_V6ONLY) was moved

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 14/05/2019 21:20, serguei.spit...@oracle.com wrote: : Summary:  The spec of the "can_redefine_any_class" needs to be more clear and consistent.  The suggestion is to change the "can_redefine_any_class" capability spec|   from:||     "Can modify (retransform or redefine) any modifiable