RE: RFR (M): 8201247: Various cleanups in the attach framework

Hi Goetz, thanks for the review. > You say you are sorting the includes, but in the VirtualMachineImpl.c > files the order is changed, but according to which order? It's > not alphabetical as in other files. It is. However, I have put "subdirs" first. That is, the includes from sys/* come first

RE: RFR (M): 8201247: Various cleanups in the attach framework

Thanks Chris, I'll push it then today. > -Original Message- > From: Chris Plummer [mailto:chris.plum...@oracle.com] > Sent: Mittwoch, 11. April 2018 07:37 > To: Langer, Christoph ; serviceability- > d...@openjdk.java.net > Cc: hotspot-...@openjdk.java.net > Subject: Re: RFR (M): 8201247: V

RE: RFR (M): 8201247: Various cleanups in the attach framework

Hi Christoph, I'm familiar with the non-system includes in hotspot, there mostly a total alphabetical ordering is followed, like in http://hg.openjdk.java.net/jdk/hs/file/0d8ed8b2ac4f/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp > It is. However, I have put "subdirs" first. That is, the includes fr

RE: RFR (M): 8201247: Various cleanups in the attach framework

Hi Goetz, I did not aim to sort the includes in the attachListener_.cpp files. I also just saw that I made a change in attachListener_aix.cpp for some other merge-related reasons - but it was not correctly sorted before and neither is after 😉 This has to be done in a future change... Best rega

Re: RFR: Fix race condition in jdwp

Thanks Serguei, I terms of a standalone testcase it is quite tricky, as due to the nature of the issue which took a lot of investigation to solve it's very timing dependent and will only occur randomly. It can be forced as I indicated below by adding a "sleep" in the VMInit report code but that'

Re: RFR: Fix race condition in jdwp

Hi Andrew, I've filed the bug:   https://bugs.openjdk.java.net/browse/JDK-8201409 Also, this is a webrev with your patch:   http://cr.openjdk.java.net/~sspitsyn/webrevs/2018/8201409-jdwp-initsync.ibm.1/ I agree that creating a standalone

Re: RFR: Fix race condition in jdwp

Hi Serguei, Thank you for raising the bug. I had a chat with one of my colleagues who could recreate it, and it's probably related to the handshaking that is done in the particular scenario. So with the JCK harness: com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck /jck8b/

Re: RFR(xxs): 8200384: jcmd help output should be sorted

Hi Thomas, Sorry, I did not reply to this. Thank you a lot for providing the output! I agree, the sorted one looks much better. Probably, it is late to say but I'm Ok with a push. :) Thanks, Serguei On 4/9/18 02

Re: RFR(xxs): 8200384: jcmd help output should be sorted

Hi Thomas, Sorry, I did not reply to this. Thank you a lot for providing the output! I agree, the sorted one looks much better. Probably, it is late to say but I'm Ok with a push. :) Thanks, Serguei On 4/9/18 02

Re: RFR(xxs): 8200384: jcmd help output should be sorted

Hi Serguei, On Wed, Apr 11, 2018 at 7:51 PM, serguei.spit...@oracle.com wrote: > Hi Thomas, > > Sorry, I did not reply to this. no problem. > Thank you a lot for providing the output! > I agree, the sorted one looks much better. > > Probably, it is late to say but I'm Ok with a push. :) > Than

Re: RFR: JDK-8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS

Ping: Gentle reminder ! Thanks, Jini. On 4/6/2018 9:51 PM, Jini George wrote: Hello! Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8174994 Webrev: http://cr.openjdk.java.net/~jgeorge/8174994/webrev.00/ While trying to identify the type given an address, a WrongTypeException