From david.holmes at oracle.com Fri Mar 1 01:07:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Mar 2019 11:07:28 +1000 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> Message-ID: <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> Hi Dmitry, On 1/03/2019 6:15 am, Dmitry Chuyko wrote: > Hello, > > Please review a small fix for GCC 8.x warning in log_messages.c. Buffer > sizes for parts of timestamp string can be adjusted to not exceed > maximum buffer size when combined, while being able to hold necessary > information. > > webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8214854 > testing: after the fix GCC 8 compiles working OpenJDK on Linux. > Dev-submit job started. This looks good. One query: 51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; Is this needed so that the size of the buffer is known by gcc inside get_time_stamp? (Generally I prefer to see explicitly when an array is being stack allocated, not have it hidden behind a typedef.) Thanks, David > -Dmitry > From zanglin5 at jd.com Fri Mar 1 03:33:39 2019 From: zanglin5 at jd.com (=?iso-2022-jp?B?GyRCZ0lOVhsoQg==?=) Date: Fri, 1 Mar 2019 03:33:39 +0000 Subject: Protocol version of Attach API In-Reply-To: <7965FB48-52AE-46C1-964A-9FDF78B0D644@amazon.com> References: <3dabf14d-e0bd-1ed1-4e37-f81332c1d68b@gmail.com> <01c706d8-600d-d823-6ebc-2d7e153c305f@oracle.com> <04aadf26-d2c9-6f65-9815-06ad36c53219@gmail.com> <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com>, <7965FB48-52AE-46C1-964A-9FDF78B0D644@amazon.com> Message-ID: Dear Paul, That sounds reasonable to me. I suggest to try it (and I will) later if reduce arg_count_max to 3 works fine at present, so we can reduce the affect from 8215622 ASAP. Then I will consider it when refining the patch for adding more options (such as "incremental" for jmap histo , described in 8215623). what do you think? BRs, Lin ________________________________________ From: Hohensee, Paul Sent: Thursday, February 28, 2019 7:48:06 PM To: ??; David Holmes; Yasumasa Suenaga Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: Protocol version of Attach API I'd like to propose an alternative approach, namely, we could add another argument parsing feature on top of the old functionality intact and leave the latter intact. We currently have just a single constant AttachOperation::arg_count_max, which the patch changed from 3 to 4. We could leave it at 3 and add another constant, call it extra_arg_count, and set extra_arg_count to 1 for now. The required number of attachListener args stays at 3, and we add code that checks for up to extra_arg_count arguments. As part of the new code, add a sentinel argument value (all 1s?) to signal end of extra arguments, rather than overloading the null string, since a null string is a valid argument. Opinion(s)? Thanks, Paul From chris.plummer at oracle.com Fri Mar 1 03:36:36 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 28 Feb 2019 19:36:36 -0800 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> Message-ID: On 2/28/19 5:07 PM, David Holmes wrote: > Hi Dmitry, > > On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >> Hello, >> >> Please review a small fix for GCC 8.x warning in log_messages.c. >> Buffer sizes for parts of timestamp string can be adjusted to not >> exceed maximum buffer size when combined, while being able to hold >> necessary information. >> >> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >> Dev-submit job started. > > This looks good. > > One query: > > ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; > > Is this needed so that the size of the buffer is known by gcc inside > get_time_stamp? (Generally I prefer to see explicitly when an array is > being stack allocated, not have it hidden behind a typedef.) This also caught my attention and then got me thinking on what basis is gcc producing the warning in the first place. The warning is: ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: error: '%.3d' directive output may be truncated writing between 3 and 11 bytes into a region of size between 0 and 80 [-Werror=format-truncation=] ??????????????????? "%s.%.3d %s", timestamp_prefix, ??????????????????????? ^~~~ I think it deduced this by seeing that the call to get_time_stamp() is passing in a char[80] for the tbuf argument. It then also sees that the argument for the first %s is also a char[80] array, so is pointing out that this first %s might fill (or nearly fill) tbuf, not leaving room for the %.3d argument. If this is the case, there is no need for the timestamp_buffer typedef. The real fix was making timestamp_date_time and timestamp_timezone smaller so gcc doesn't think they can overflow tbuf. Chris > > Thanks, > David > > >> -Dmitry >> From zanglin5 at jd.com Fri Mar 1 03:39:16 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Fri, 1 Mar 2019 03:39:16 +0000 Subject: Protocol version of Attach API In-Reply-To: <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> References: <3dabf14d-e0bd-1ed1-4e37-f81332c1d68b@gmail.com> <01c706d8-600d-d823-6ebc-2d7e153c305f@oracle.com> <04aadf26-d2c9-6f65-9815-06ad36c53219@gmail.com> <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com>, <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> Message-ID: <5d2d51087deb43988867ae66918482aa@jd.com> Hi David, My understanding about those "arg" is that they are trying to make limitation of the overall message length and make it convince to communicate with sockets. I will do more test try to see whether changing back to 3 makes everything fine, and then prepare a webrev. Thanks. Lin ________________________________________ From: David Holmes Sent: Thursday, February 28, 2019 7:55:01 PM To: ??; Yasumasa Suenaga Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: Protocol version of Attach API Hi Lin, On 28/02/2019 7:30 pm, ?? wrote: > Hi David, > I am a little confused, do you think it is proper to made the patch as a fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't need to backout and REDO? Generally I'd prefer to do the backout and then apply the revised fix as it will make the changes easier to track. However, if you are saying that everything works fine just by changing the 4 back to 3 everywhere, then that does seem a very simple fix to apply directly. I admit that if that does work then I really don't understand what these "arg" values actually means. :( Though it would explain why windows appears to work fine even though it was left at 3. Thanks, David > Thanks, > LIn > ________________________________________ > From: ?? > Sent: Thursday, February 28, 2019 4:50:12 PM > To: David Holmes; Yasumasa Suenaga > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: Protocol version of Attach API > > Dear All, > I have tried simply recover the max argument count makes jmap -histo works and also makes the compatibility works fine. > Following are the changes I made: > > diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp > --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 16:48:19 2019 +0800 > @@ -106,7 +106,7 @@ > enum { > name_length_max = 16, // maximum length of name > arg_length_max = 1024, // maximum length of argument > - arg_count_max = 4 // maximum number of arguments > + arg_count_max = 3 // maximum number of arguments > }; > > // name of special operation that can be enqueued when all > diff -r 07dd34f487d4 src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > @@ -138,7 +138,7 @@ > * Execute the given command in the target VM. > */ > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > - assert args.length <= 4; // includes null > + assert args.length <= 3; // includes null > > // did we detach? > synchronized (this) { > @@ -166,7 +166,7 @@ > writeString(s, PROTOCOL_VERSION); > writeString(s, cmd); > > - for (int i = 0; i < 4; i++) { > + for (int i = 0; i < 3; i++) { > if (i < args.length && args[i] != null) { > writeString(s, (String)args[i]); > } else { > diff -r 07dd34f487d4 src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > @@ -143,7 +143,7 @@ > * Execute the given command in the target VM. > */ > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > - assert args.length <= 4; // includes null > + assert args.length <= 3; // includes null > > // did we detach? > synchronized (this) { > diff -r 07dd34f487d4 src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > @@ -139,7 +139,7 @@ > * Execute the given command in the target VM. > */ > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > - assert args.length <= 4; // includes null > + assert args.length <= 3; // includes null > > // did we detach? > synchronized (this) { > diff -r 07dd34f487d4 src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > @@ -126,7 +126,7 @@ > * Execute the given command in the target VM. > */ > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > - assert args.length <= 4; // includes null > + assert args.length <= 3; // includes null > > // first check that we are still attached > int door; > diff -r 07dd34f487d4 src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > +++ b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > @@ -77,7 +77,7 @@ > InputStream execute(String cmd, Object ... args) > throws AgentLoadException, IOException > { > - assert args.length <= 4; // includes null > + assert args.length <= 3; // includes null > > // create a pipe using a random name > Random rnd = new Random(); > > > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Thursday, February 28, 2019 3:24:52 PM > To: David Holmes; Yasumasa Suenaga > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: RE: Protocol version of Attach API > > Hi David, > Since I don't have the access to JBS, may I ask your help to ceate sub-task? Thanks. > > BRs, > Lin > >> -----Original Message----- >> From: David Holmes >> Sent: Thursday, February 28, 2019 3:16 PM >> To: ?? ; Yasumasa Suenaga >> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> >> Subject: Re: Protocol version of Attach API >> >> Hi Lin, >> >> On 28/02/2019 4:49 pm, ?? wrote: >>> Hi David, >>> Your are right and thanks for pointing it out. when I worte that patch, I >> was considering implement -filename and -incremental together. and I must >> be too stupid to forget recover it when I divided the patch into two. >>> And it seems a good solution is to refine the original patch of jmap histo, >> and try to composite all args as one when passing it to socket and let >> attachlistener to handle the analyze. >>> I will try that. >>> One more, do I need to consider changing the jmap -dump also? >> >> I'm assuming -dump already works fine, so I'm just expecting to see -histo >> handle the file in a similar manner. >> >> If you find this works I suggest creating a sub-task of 8215622 to first backout >> the original changes (hg backout), and a second sub-task to REDO with the >> new implementation. Each will need reviewing separately in their own RFR >> thread. >> >> Thanks, >> David >> >>> BRs, >>> Lin >>> ________________________________________ >>> From: David Holmes >>> Sent: Thursday, February 28, 2019 12:59:28 PM >>> To: ??; Yasumasa Suenaga >>> Cc: serviceability-dev at openjdk.java.net >>> serviceability-dev at openjdk.java.net >>> Subject: Re: Protocol version of Attach API >>> >>> Sorry I'm going to pick up on the rollback and re-do option here as I >>> just had a closer look at jmap. Given jmap -dump already has more >>> options than -histo does, why was any change to the "maximum number of >>> args" needed in the first place ??? >>> >>> David >>> >>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>> Hi everyone, >>>> >>>> I'm not sure we're converging on a suitable solution here, but to >>>> address the issues flagged by Lin below ... >>>> >>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>> Hi Suenaga, >>>>> >>>>> Thanks for your expaination about the arg_length_max, I >>>>> generally agree with you that it is better to consider using dynamic >>>>> memory, and that would be handled carefully to aviod introduce >>>>> compatibility issue, plus it would be a big change. So let?s see >>>>> what others suggest. >>>>> >>>>> Hi All, >>>>> >>>>> It seems for me that there are basically three problems forked by >>>>> this >>>>> thread? >>>>> >>>>> ?Compatibility issue with old jcmd alike tools with attachListener?s >>>>> change. >>>> >>>> This is issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>> >>>>> ?Only 3 arguments limited to passed by socket to attachListener for >>>>> Windows, which cause 8215622 work abnormally on Windows. >>>> >>>> I have filed a new bug for this: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>> >>>>> ?The arg_length_max may not be enough for handling filename. >>>> >>>> I have filed a new bug for this: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>> >>>> though it seems very related to this issue. >>>> >>>>> So I suggest we keep the first problem discussed in this thread, and >>>>> create separate thread for the others. Do you agree? >>>> >>>> There is some overlap but yes this can be broken down somewhat - >>>> though dealing with the variable length "packet" is going to have to >>>> consider that what is received is in fact much larger than the >>>> purported maximum packet size if these long paths are expected and >> accepted. >>>> >>>> FWIW I don't see crashes or anything drastic if the arguments are too >>>> long - the operations just fail (in somewhat obscure ways sometimes). >>>> >>>>> >>>>> For me, I will refine my patch to use timeout as a fix for the first >>>>> one, and update it in this thread. And I will try to fix the second >>>>> one for Windows, and create a separate thread for discussing. And if >>>>> possible, I can help to fix the third one. >>>>> >>>>> What?s your opinion? >>>> >>>> That sounds fine ... >>>> >>>> Or you could choose to rollback JDK-8215622 and see how to solve that >>>> without increasing the arg count. Given this usage: >>>> >>>> jmap -histo:live,file=foo.txt >>>> >>>> I'm not sure why this is sent to the VM as multiple args rather than >>>> as a single composite arg that can then be parsed again by the actual >>>> "jmap" logic. There would be some double-up perhaps if the front-end >>>> tool wants to perform the command-line validation, but it would be >>>> easy enough I think to do that checking then send the original composite >> arg. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> BRs, >>>>> >>>>> Lin >>>>> >>>>> *From:*Yasumasa Suenaga >>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>> *To:* ?? >>>>> *Cc:* David Holmes ; >>>>> serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: Protocol version of Attach API >>>>> >>>>> 2019?2?28?(?) 0:04 ?? > >: >>>>> >>>>> Dear Suenaga, >>>>> Thanks for your reviewing. I will try to refine the patch. >>>>> For the argument length you mentioned, do you mean the >>>>> "arg_length_max" should be large enough to accept the max filename >>>>> length? >>>>> >>>>> Yes, but it is not enough. >>>>> >>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. >>>>> >>>>> IMHO, all the handling of the argument length is at receiver >>>>> side in the attachListener, such as >>>>> >>>>> >> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/linux/att >> achListener_linux.cpp#l322, >>>>> for me it means that the VM side limits the argments length less >>>>> than arg_length_max, otherwise it will return NULL, which cause the >>>>> sender side (tools like jcmd and jmap) exits with error message. so >>>>> I think there may be no need to limit the argument size in tool side. >>>>> >>>>> IMHO all programs which use filesystem should support any locations >>>>> on it. >>>>> >>>>> So I think we should use dynamic memory (or GrowableArray) for it if >>>>> we do not change client side for compatibility. >>>>> >>>>> And from my experiment with jmap, the arguments send to >>>>> sockets are not arg0 only. as you can see in >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>> >>>>> and >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>> are/classes/sun/tools/jmap/JMap.java#l133, >>>>> >>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both of >>>>> them can be NULL. so 00000 can be >>>>> 0000, and file can be null. so 00 may not >>>>> indicate it reach the end. >>>>> >>>>> We should consider for other tools - jstack and jinfo. >>>>> >>>>> (jstack is ok because it will not have long arguments) >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> BRs, >>>>> Lin >>>>> ________________________________________ >>>>> From: Yasumasa Suenaga >>>> > >>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>> To: ?? >>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>> >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Hi Lin, >>>>> >>>>> I think we need to research more about this. >>>>> IMHO we need to match length of arguments between >>>>> server (AttachListener) and client (serviceability tools) at least. >>>>> (please see previous email from me). >>>>> >>>>> I have some comments for your change: >>>>> >>>>> On 2019/02/27 18:22, ?? wrote: >>>>> > Dear All, >>>>> >? Here I have figured out one solution based on timeout. would >>>>> you like help to see whether this is OK? >>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb >>>>> 26 14:57:23 2019 +0530 >>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed Feb >>>>> 27 17:21:48 2019 +0800 >>>>> > @@ -263,9 +263,29 @@ >>>>> >? int off = 0; >>>>> >? int left = max_len; >>>>> > >>>>> > + memset(buf, 0, max_len); >>>>> > + // set timeout for read >>>>> > + struct timeval timeout; >>>>> > + timeout.tv_sec = 3; >>>>> > + timeout.tv_usec = 0; >>>>> >>>>> I think timeout value should be configurable. >>>>> For example, we can introduce new flag in globals.hpp . >>>>> >>>>> >>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>> timeval*)&timeout, sizeof(timeout))) { >>>>> > + log_debug(attach)("Failed to set socket option SO_RCVTIMEO: >>>>> %s\n", strerror(errorno)); >>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: >>>>> %s!!!\n", strerror(errno)); >>>>> >>>>> You should not use printf(), and do you need to pass '\n' to >>>>> log_debug()? >>>>> >>>>> >>>>> > + } >>>>> >? do { >>>>> >? int n; >>>>> > - RESTARTABLE(read(s, buf+off, left), n); >>>>> > + log_debug(attach)("start reading data from socket....\n"); >>>>> > + n = read(s, buf+off, left); >>>>> >>>>> You should use RESTARTABLE macro. >>>>> read(2) might be interrupted by signal. >>>>> >>>>> >>>>> > + if (n < 0) { >>>>> > + if (errno == EWOULDBLOCK) { >>>>> >>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. >>>>> So you should check both errno. >>>>> >>>>> >>>>> > + for (int i = str_count; i < expected_str_count; i++) { >>>>> > + //timeout, fill reminded arguments with \0; >>>>> > + buf[off+i] = '\0'; >>>>> > + str_count++; >>>>> > + } >>>>> >>>>> You set zero to buf[] in above. >>>>> So you can remove this loop, and set str_count to expected_str_count >>>>> without manipulating buf[]. >>>>> >>>>> In addition, I prefer to add log_debug() at this >>>>> to record NULL arguments are added. >>>>> >>>>> >>>>> > + break;; >>>>> > + } >>>>> > + } >>>>> >? assert(n <= left, "buffer was too small, impossible!"); >>>>> >? buf[max_len - 1] = '\0'; >>>>> >? if (n == -1) { >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> > Thanks. >>>>> > Lin >>>>> > >>>>> > ________________________________________ >>>>> > From: Yasumasa Suenaga >>>> > >>>>> > Sent: Wednesday, February 27, 2019 15:15 >>>>> > To: David Holmes; ?? >>>>> > Cc: serviceability-dev at openjdk.java.net >>>>> >>>>> > Subject: Re: Protocol version of Attach API >>>>> > >>>>> > On 2019/02/27 15:59, David Holmes wrote: >>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>> >>> Hi, >>>>> >>> >>>>> >>> Buffer size for receiving packets from client is >>>>> determined at [1]. >>>>> >> >>>>> >> Maximum buffer size, yes. >>>>> >> >>>>> >>> It defines length of command name and of argument. >>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining >>>>> bytes and >>>>> >>> might be able to assume all arguments are passed with >>>>> empty string. >>>>> >> >>>>> >> Not sure what you mean. >>>>> >> >>>>> >> // The buffer is expected to be formatted as follows: >>>>> >> // 00000 >>>>> >> >>>>> >> so we can expect to read at least two things - the ver and cmd. >>>>> If we encounter 00 we can infer we reached the end. But we may not >>>>> have read the full data into the buffer, so can't tell if another >>>>> call to read() is needed yet - you only know after you've read >>>>> the 00. >>>>> >> >>>>> >>> BTW length of arguments is defined to 1024 in [2]. >>>>> >>> jcmd and jmap might pas file path - it might be JVM_MAXPATHLEN >>>>> (4097 bytes). >>>>> >>> Buffer size which is used in AttachListener seems not to >>>>> be enough. >>>>> >> >>>>> >> One has to assume/hope that the code sending the data is working >>>>> to the same protocol rules as the receiver! Otherwise this is just >>>>> completely broken. >>>>> > >>>>> > On Linux, client (VirtualMachineImpl) seems not to check length >>>>> of arguments: >>>>> > >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.attach/ >>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>> >>>>> > >>>>> > In case of jcmd, all options are passed to arg #1. It seems not >>>>> to check the length: >>>>> > >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>> >>>>> > >>>>> > >>>>> > I guess other tools (jstack, jmap, etc) which connect to >>>>> AttachListener are same. >>>>> > So we can fix both Attach API and AttachListener (it will be big >>>>> change!), >>>>> > but I concern we can keep protocol version... >>>>> > >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Yasumasa >>>>> > >>>>> > >>>>> >> David >>>>> >> ----- >>>>> >> >>>>> >>> We might have to change more. >>>>> >>> >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Yasumasa >>>>> >>> >>>>> >>> >>>>> >>> [1] >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/ >>>>> linux/attachListener_linux.cpp#l254 >>>>> >>>>> >>> [2] >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/sha >>>>> re/services/attachListener.hpp#l106 >>>>> >>>>> >>> >>>>> >>> >>>>> >>> On 2019/02/27 15:00, ?? wrote: >>>>> >>>> Another solution I can figure out is try to add timeout for >>>>> socket read. I will also investigate whether is works. >>>>> >>>> >>>>> >>>> Cheers, >>>>> >>>> Lin >>>>> >>>> >>>>> >>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: ?? >>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>> >>>>> To: 'David Holmes' >>>> >; Yasumasa Suenaga >>>>> >>>>> > >>>>> >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> >>>>> >>>>> Subject: RE: Protocol version of Attach API >>>>> >>>>> >>>>> >>>>> Dear David, Yasumasa, >>>>> >>>>>? I think it is hard to know how long the buffer is >>>>> passed from socket >>>>> >>>>> without changing the info of the message from the >>>>> receiver side. >>>>> >>>>>? So how about when str_count reach to 3, we test it >>>>> with non_blocking >>>>> >>>>> read? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Lin >>>>> >>>>>> -----Original Message----- >>>>> >>>>>> From: David Holmes >>>> > >>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>> >>>>>> To: Yasumasa Suenaga >>>> >; ?? >>>> > >>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>> >>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>>> >>>>> >>>>>> Hi Yasumasa, >>>>> >>>>>> >>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>> >>>>>>> Hi Lin, >>>>> >>>>>>> >>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. >>>>> >>>>>>> >>>>> >>>>>>> AttachListener receives raw command. >>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see >>>>> >>>>>>> HotSpotVirtualMachine and extended classes. >>>>> >>>>>>> >>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive message >>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it well). >>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not reach >>>>> to maximum. >>>>> >>>>>> >>>>> >>>>>> I don't see how this approach can work. You have to know >> how >>>>> many >>>>> >>>>>> arguments are coming in the "packet", but that information >>>>> is not >>>>> >>>>>> available in the current Linux implementation.Without it you >>>>> can't >>>>> >>>>>> know when to stop calling read(). >>>>> >>>>>> >>>>> >>>>>> The protocol would need to be changed to send the "packet" >>>>> size, but >>>>> >>>>>> that's not compatible with older JDKs. >>>>> >>>>>> >>>>> >>>>>> Otherwise I think we have no choice but to use a >>>>> non-blocking read ... >>>>> >>>>>> though I'm still unsure if you can know for certain >>>>> that you've >>>>> >>>>>> reached the end of the "packet" ... >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> David >>>>> >>>>>> >>>>> >>>>>>> >>>>> >>>>>>> Thanks, >>>>> >>>>>>> >>>>> >>>>>>> Yasumasa >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>> wrote: >>>>> >>>>>>>> Dear Yasumasa, >>>>> >>>>>>>>? The fix you mentioned seems not work as expected. >>>>> >>>>>>>>? I have done an experiment that use jdk1.8's "jcmd >>>>> help" to >>>>> >>>>>>>> attach to latest jdk. >>>>> >>>>>>>>? it seem the whole "jcmd help"? buffer is not >>>>> >>>>>>>>? read completely at one time. in my case it is "jcmd", >>>>> "", >>>>> >>>>>>>> "help", and then block at while(). >>>>> >>>>>>>>? After applied your change, it seems only the "jcmd" is >>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. >>>>> >>>>>>>> >>>>> >>>>>>>> BRs, >>>>> >>>>>>>> Lin >>>>> >>>>>>>> >>>>> From yasuenag at gmail.com Fri Mar 1 03:54:54 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Mar 2019 12:54:54 +0900 Subject: Protocol version of Attach API In-Reply-To: <5d2d51087deb43988867ae66918482aa@jd.com> References: <3dabf14d-e0bd-1ed1-4e37-f81332c1d68b@gmail.com> <01c706d8-600d-d823-6ebc-2d7e153c305f@oracle.com> <04aadf26-d2c9-6f65-9815-06ad36c53219@gmail.com> <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> Message-ID: Hi, I agree with David. I think we should backout 8215622. We should re-do 8215622 completely for all platforms (includes Windows) and support receiving requests from earlier serviceability tools. Problems about arguments of AttachListener should be worked as another issues. Thanks, Yasumasa 2019?3?1?(?) 12:39 ?? : > > Hi David, > My understanding about those "arg" is that they are trying to make limitation of the overall message length and make it convince to communicate with sockets. > I will do more test try to see whether changing back to 3 makes everything fine, and then prepare a webrev. > Thanks. > > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, February 28, 2019 7:55:01 PM > To: ??; Yasumasa Suenaga > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: Protocol version of Attach API > > Hi Lin, > > On 28/02/2019 7:30 pm, ?? wrote: > > Hi David, > > I am a little confused, do you think it is proper to made the patch as a fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't need to backout and REDO? > > Generally I'd prefer to do the backout and then apply the revised fix as > it will make the changes easier to track. > > However, if you are saying that everything works fine just by changing > the 4 back to 3 everywhere, then that does seem a very simple fix to > apply directly. > > I admit that if that does work then I really don't understand what these > "arg" values actually means. :( Though it would explain why windows > appears to work fine even though it was left at 3. > > Thanks, > David > > > Thanks, > > LIn > > ________________________________________ > > From: ?? > > Sent: Thursday, February 28, 2019 4:50:12 PM > > To: David Holmes; Yasumasa Suenaga > > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > > Subject: Re: Protocol version of Attach API > > > > Dear All, > > I have tried simply recover the max argument count makes jmap -histo works and also makes the compatibility works fine. > > Following are the changes I made: > > > > diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp > > --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 16:48:19 2019 +0800 > > @@ -106,7 +106,7 @@ > > enum { > > name_length_max = 16, // maximum length of name > > arg_length_max = 1024, // maximum length of argument > > - arg_count_max = 4 // maximum number of arguments > > + arg_count_max = 3 // maximum number of arguments > > }; > > > > // name of special operation that can be enqueued when all > > diff -r 07dd34f487d4 src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > > --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > > @@ -138,7 +138,7 @@ > > * Execute the given command in the target VM. > > */ > > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > > - assert args.length <= 4; // includes null > > + assert args.length <= 3; // includes null > > > > // did we detach? > > synchronized (this) { > > @@ -166,7 +166,7 @@ > > writeString(s, PROTOCOL_VERSION); > > writeString(s, cmd); > > > > - for (int i = 0; i < 4; i++) { > > + for (int i = 0; i < 3; i++) { > > if (i < args.length && args[i] != null) { > > writeString(s, (String)args[i]); > > } else { > > diff -r 07dd34f487d4 src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > > --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > > @@ -143,7 +143,7 @@ > > * Execute the given command in the target VM. > > */ > > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > > - assert args.length <= 4; // includes null > > + assert args.length <= 3; // includes null > > > > // did we detach? > > synchronized (this) { > > diff -r 07dd34f487d4 src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > > --- a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > > @@ -139,7 +139,7 @@ > > * Execute the given command in the target VM. > > */ > > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > > - assert args.length <= 4; // includes null > > + assert args.length <= 3; // includes null > > > > // did we detach? > > synchronized (this) { > > diff -r 07dd34f487d4 src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > > --- a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > > @@ -126,7 +126,7 @@ > > * Execute the given command in the target VM. > > */ > > InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { > > - assert args.length <= 4; // includes null > > + assert args.length <= 3; // includes null > > > > // first check that we are still attached > > int door; > > diff -r 07dd34f487d4 src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java > > --- a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 > > +++ b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 > > @@ -77,7 +77,7 @@ > > InputStream execute(String cmd, Object ... args) > > throws AgentLoadException, IOException > > { > > - assert args.length <= 4; // includes null > > + assert args.length <= 3; // includes null > > > > // create a pipe using a random name > > Random rnd = new Random(); > > > > > > > > Thanks, > > Lin > > ________________________________________ > > From: ?? > > Sent: Thursday, February 28, 2019 3:24:52 PM > > To: David Holmes; Yasumasa Suenaga > > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > > Subject: RE: Protocol version of Attach API > > > > Hi David, > > Since I don't have the access to JBS, may I ask your help to ceate sub-task? Thanks. > > > > BRs, > > Lin > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Thursday, February 28, 2019 3:16 PM > >> To: ?? ; Yasumasa Suenaga > >> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > >> > >> Subject: Re: Protocol version of Attach API > >> > >> Hi Lin, > >> > >> On 28/02/2019 4:49 pm, ?? wrote: > >>> Hi David, > >>> Your are right and thanks for pointing it out. when I worte that patch, I > >> was considering implement -filename and -incremental together. and I must > >> be too stupid to forget recover it when I divided the patch into two. > >>> And it seems a good solution is to refine the original patch of jmap histo, > >> and try to composite all args as one when passing it to socket and let > >> attachlistener to handle the analyze. > >>> I will try that. > >>> One more, do I need to consider changing the jmap -dump also? > >> > >> I'm assuming -dump already works fine, so I'm just expecting to see -histo > >> handle the file in a similar manner. > >> > >> If you find this works I suggest creating a sub-task of 8215622 to first backout > >> the original changes (hg backout), and a second sub-task to REDO with the > >> new implementation. Each will need reviewing separately in their own RFR > >> thread. > >> > >> Thanks, > >> David > >> > >>> BRs, > >>> Lin > >>> ________________________________________ > >>> From: David Holmes > >>> Sent: Thursday, February 28, 2019 12:59:28 PM > >>> To: ??; Yasumasa Suenaga > >>> Cc: serviceability-dev at openjdk.java.net > >>> serviceability-dev at openjdk.java.net > >>> Subject: Re: Protocol version of Attach API > >>> > >>> Sorry I'm going to pick up on the rollback and re-do option here as I > >>> just had a closer look at jmap. Given jmap -dump already has more > >>> options than -histo does, why was any change to the "maximum number of > >>> args" needed in the first place ??? > >>> > >>> David > >>> > >>> On 28/02/2019 2:43 pm, David Holmes wrote: > >>>> Hi everyone, > >>>> > >>>> I'm not sure we're converging on a suitable solution here, but to > >>>> address the issues flagged by Lin below ... > >>>> > >>>> On 28/02/2019 12:39 pm, ?? wrote: > >>>>> Hi Suenaga, > >>>>> > >>>>> Thanks for your expaination about the arg_length_max, I > >>>>> generally agree with you that it is better to consider using dynamic > >>>>> memory, and that would be handled carefully to aviod introduce > >>>>> compatibility issue, plus it would be a big change. So let?s see > >>>>> what others suggest. > >>>>> > >>>>> Hi All, > >>>>> > >>>>> It seems for me that there are basically three problems forked by > >>>>> this > >>>>> thread? > >>>>> > >>>>> ?Compatibility issue with old jcmd alike tools with attachListener?s > >>>>> change. > >>>> > >>>> This is issue: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8219721 > >>>> > >>>>> ?Only 3 arguments limited to passed by socket to attachListener for > >>>>> Windows, which cause 8215622 work abnormally on Windows. > >>>> > >>>> I have filed a new bug for this: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8219895 > >>>> > >>>>> ?The arg_length_max may not be enough for handling filename. > >>>> > >>>> I have filed a new bug for this: > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8219896 > >>>> > >>>> though it seems very related to this issue. > >>>> > >>>>> So I suggest we keep the first problem discussed in this thread, and > >>>>> create separate thread for the others. Do you agree? > >>>> > >>>> There is some overlap but yes this can be broken down somewhat - > >>>> though dealing with the variable length "packet" is going to have to > >>>> consider that what is received is in fact much larger than the > >>>> purported maximum packet size if these long paths are expected and > >> accepted. > >>>> > >>>> FWIW I don't see crashes or anything drastic if the arguments are too > >>>> long - the operations just fail (in somewhat obscure ways sometimes). > >>>> > >>>>> > >>>>> For me, I will refine my patch to use timeout as a fix for the first > >>>>> one, and update it in this thread. And I will try to fix the second > >>>>> one for Windows, and create a separate thread for discussing. And if > >>>>> possible, I can help to fix the third one. > >>>>> > >>>>> What?s your opinion? > >>>> > >>>> That sounds fine ... > >>>> > >>>> Or you could choose to rollback JDK-8215622 and see how to solve that > >>>> without increasing the arg count. Given this usage: > >>>> > >>>> jmap -histo:live,file=foo.txt > >>>> > >>>> I'm not sure why this is sent to the VM as multiple args rather than > >>>> as a single composite arg that can then be parsed again by the actual > >>>> "jmap" logic. There would be some double-up perhaps if the front-end > >>>> tool wants to perform the command-line validation, but it would be > >>>> easy enough I think to do that checking then send the original composite > >> arg. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>> > >>>>> BRs, > >>>>> > >>>>> Lin > >>>>> > >>>>> *From:*Yasumasa Suenaga > >>>>> *Sent:* Thursday, February 28, 2019 8:39 AM > >>>>> *To:* ?? > >>>>> *Cc:* David Holmes ; > >>>>> serviceability-dev at openjdk.java.net > >>>>> serviceability-dev at openjdk.java.net > >>>>> > >>>>> *Subject:* Re: Protocol version of Attach API > >>>>> > >>>>> 2019?2?28?(?) 0:04 ?? >> >: > >>>>> > >>>>> Dear Suenaga, > >>>>> Thanks for your reviewing. I will try to refine the patch. > >>>>> For the argument length you mentioned, do you mean the > >>>>> "arg_length_max" should be large enough to accept the max filename > >>>>> length? > >>>>> > >>>>> Yes, but it is not enough. > >>>>> > >>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. > >>>>> > >>>>> IMHO, all the handling of the argument length is at receiver > >>>>> side in the attachListener, such as > >>>>> > >>>>> > >> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/linux/att > >> achListener_linux.cpp#l322, > >>>>> for me it means that the VM side limits the argments length less > >>>>> than arg_length_max, otherwise it will return NULL, which cause the > >>>>> sender side (tools like jcmd and jmap) exits with error message. so > >>>>> I think there may be no need to limit the argument size in tool side. > >>>>> > >>>>> IMHO all programs which use filesystem should support any locations > >>>>> on it. > >>>>> > >>>>> So I think we should use dynamic memory (or GrowableArray) for it if > >>>>> we do not change client side for compatibility. > >>>>> > >>>>> And from my experiment with jmap, the arguments send to > >>>>> sockets are not arg0 only. as you can see in > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh > >>>>> are/classes/sun/tools/jmap/JMap.java#l193 > >>>>> > >>>>> and > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh > >>>>> are/classes/sun/tools/jmap/JMap.java#l133, > >>>>> > >>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both of > >>>>> them can be NULL. so 00000 can be > >>>>> 0000, and file can be null. so 00 may not > >>>>> indicate it reach the end. > >>>>> > >>>>> We should consider for other tools - jstack and jinfo. > >>>>> > >>>>> (jstack is ok because it will not have long arguments) > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> BRs, > >>>>> Lin > >>>>> ________________________________________ > >>>>> From: Yasumasa Suenaga >>>>> > > >>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM > >>>>> To: ?? > >>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net > >>>>> > >>>>> Subject: Re: Protocol version of Attach API > >>>>> > >>>>> Hi Lin, > >>>>> > >>>>> I think we need to research more about this. > >>>>> IMHO we need to match length of arguments between > >>>>> server (AttachListener) and client (serviceability tools) at least. > >>>>> (please see previous email from me). > >>>>> > >>>>> I have some comments for your change: > >>>>> > >>>>> On 2019/02/27 18:22, ?? wrote: > >>>>> > Dear All, > >>>>> > Here I have figured out one solution based on timeout. would > >>>>> you like help to see whether this is OK? > >>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb > >>>>> 26 14:57:23 2019 +0530 > >>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed Feb > >>>>> 27 17:21:48 2019 +0800 > >>>>> > @@ -263,9 +263,29 @@ > >>>>> > int off = 0; > >>>>> > int left = max_len; > >>>>> > > >>>>> > + memset(buf, 0, max_len); > >>>>> > + // set timeout for read > >>>>> > + struct timeval timeout; > >>>>> > + timeout.tv_sec = 3; > >>>>> > + timeout.tv_usec = 0; > >>>>> > >>>>> I think timeout value should be configurable. > >>>>> For example, we can introduce new flag in globals.hpp . > >>>>> > >>>>> > >>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct > >>>>> timeval*)&timeout, sizeof(timeout))) { > >>>>> > + log_debug(attach)("Failed to set socket option SO_RCVTIMEO: > >>>>> %s\n", strerror(errorno)); > >>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: > >>>>> %s!!!\n", strerror(errno)); > >>>>> > >>>>> You should not use printf(), and do you need to pass '\n' to > >>>>> log_debug()? > >>>>> > >>>>> > >>>>> > + } > >>>>> > do { > >>>>> > int n; > >>>>> > - RESTARTABLE(read(s, buf+off, left), n); > >>>>> > + log_debug(attach)("start reading data from socket....\n"); > >>>>> > + n = read(s, buf+off, left); > >>>>> > >>>>> You should use RESTARTABLE macro. > >>>>> read(2) might be interrupted by signal. > >>>>> > >>>>> > >>>>> > + if (n < 0) { > >>>>> > + if (errno == EWOULDBLOCK) { > >>>>> > >>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. > >>>>> So you should check both errno. > >>>>> > >>>>> > >>>>> > + for (int i = str_count; i < expected_str_count; i++) { > >>>>> > + //timeout, fill reminded arguments with \0; > >>>>> > + buf[off+i] = '\0'; > >>>>> > + str_count++; > >>>>> > + } > >>>>> > >>>>> You set zero to buf[] in above. > >>>>> So you can remove this loop, and set str_count to expected_str_count > >>>>> without manipulating buf[]. > >>>>> > >>>>> In addition, I prefer to add log_debug() at this > >>>>> to record NULL arguments are added. > >>>>> > >>>>> > >>>>> > + break;; > >>>>> > + } > >>>>> > + } > >>>>> > assert(n <= left, "buffer was too small, impossible!"); > >>>>> > buf[max_len - 1] = '\0'; > >>>>> > if (n == -1) { > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> > Thanks. > >>>>> > Lin > >>>>> > > >>>>> > ________________________________________ > >>>>> > From: Yasumasa Suenaga >>>>> > > >>>>> > Sent: Wednesday, February 27, 2019 15:15 > >>>>> > To: David Holmes; ?? > >>>>> > Cc: serviceability-dev at openjdk.java.net > >>>>> > >>>>> > Subject: Re: Protocol version of Attach API > >>>>> > > >>>>> > On 2019/02/27 15:59, David Holmes wrote: > >>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: > >>>>> >>> Hi, > >>>>> >>> > >>>>> >>> Buffer size for receiving packets from client is > >>>>> determined at [1]. > >>>>> >> > >>>>> >> Maximum buffer size, yes. > >>>>> >> > >>>>> >>> It defines length of command name and of argument. > >>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining > >>>>> bytes and > >>>>> >>> might be able to assume all arguments are passed with > >>>>> empty string. > >>>>> >> > >>>>> >> Not sure what you mean. > >>>>> >> > >>>>> >> // The buffer is expected to be formatted as follows: > >>>>> >> // 00000 > >>>>> >> > >>>>> >> so we can expect to read at least two things - the ver and cmd. > >>>>> If we encounter 00 we can infer we reached the end. But we may not > >>>>> have read the full data into the buffer, so can't tell if another > >>>>> call to read() is needed yet - you only know after you've read > >>>>> the 00. > >>>>> >> > >>>>> >>> BTW length of arguments is defined to 1024 in [2]. > >>>>> >>> jcmd and jmap might pas file path - it might be JVM_MAXPATHLEN > >>>>> (4097 bytes). > >>>>> >>> Buffer size which is used in AttachListener seems not to > >>>>> be enough. > >>>>> >> > >>>>> >> One has to assume/hope that the code sending the data is working > >>>>> to the same protocol rules as the receiver! Otherwise this is just > >>>>> completely broken. > >>>>> > > >>>>> > On Linux, client (VirtualMachineImpl) seems not to check length > >>>>> of arguments: > >>>>> > > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.attach/ > >>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 > >>>>> > >>>>> > > >>>>> > In case of jcmd, all options are passed to arg #1. It seems not > >>>>> to check the length: > >>>>> > > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh > >>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 > >>>>> > >>>>> > > >>>>> > > >>>>> > I guess other tools (jstack, jmap, etc) which connect to > >>>>> AttachListener are same. > >>>>> > So we can fix both Attach API and AttachListener (it will be big > >>>>> change!), > >>>>> > but I concern we can keep protocol version... > >>>>> > > >>>>> > > >>>>> > Thanks, > >>>>> > > >>>>> > Yasumasa > >>>>> > > >>>>> > > >>>>> >> David > >>>>> >> ----- > >>>>> >> > >>>>> >>> We might have to change more. > >>>>> >>> > >>>>> >>> > >>>>> >>> Thanks, > >>>>> >>> > >>>>> >>> Yasumasa > >>>>> >>> > >>>>> >>> > >>>>> >>> [1] > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/ > >>>>> linux/attachListener_linux.cpp#l254 > >>>>> > >>>>> >>> [2] > >>>>> > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/sha > >>>>> re/services/attachListener.hpp#l106 > >>>>> > >>>>> >>> > >>>>> >>> > >>>>> >>> On 2019/02/27 15:00, ?? wrote: > >>>>> >>>> Another solution I can figure out is try to add timeout for > >>>>> socket read. I will also investigate whether is works. > >>>>> >>>> > >>>>> >>>> Cheers, > >>>>> >>>> Lin > >>>>> >>>> > >>>>> >>>> > >>>>> >>>>> -----Original Message----- > >>>>> >>>>> From: ?? > >>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM > >>>>> >>>>> To: 'David Holmes' >>>>> >; Yasumasa Suenaga > >>>>> >>>>> > > >>>>> >>>>> Cc: serviceability-dev at openjdk.java.net > >>>>> > >>>>> >>>>> Subject: RE: Protocol version of Attach API > >>>>> >>>>> > >>>>> >>>>> Dear David, Yasumasa, > >>>>> >>>>> I think it is hard to know how long the buffer is > >>>>> passed from socket > >>>>> >>>>> without changing the info of the message from the > >>>>> receiver side. > >>>>> >>>>> So how about when str_count reach to 3, we test it > >>>>> with non_blocking > >>>>> >>>>> read? > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> Cheers, > >>>>> >>>>> Lin > >>>>> >>>>>> -----Original Message----- > >>>>> >>>>>> From: David Holmes >>>>> > > >>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM > >>>>> >>>>>> To: Yasumasa Suenaga >>>>> >; ?? >>>>> > > >>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net > >>>>> > >>>>> >>>>>> Subject: Re: Protocol version of Attach API > >>>>> >>>>>> > >>>>> >>>>>> Hi Yasumasa, > >>>>> >>>>>> > >>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: > >>>>> >>>>>>> Hi Lin, > >>>>> >>>>>>> > >>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. > >>>>> >>>>>>> > >>>>> >>>>>>> AttachListener receives raw command. > >>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see > >>>>> >>>>>>> HotSpotVirtualMachine and extended classes. > >>>>> >>>>>>> > >>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive message > >>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it well). > >>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not reach > >>>>> to maximum. > >>>>> >>>>>> > >>>>> >>>>>> I don't see how this approach can work. You have to know > >> how > >>>>> many > >>>>> >>>>>> arguments are coming in the "packet", but that information > >>>>> is not > >>>>> >>>>>> available in the current Linux implementation.Without it you > >>>>> can't > >>>>> >>>>>> know when to stop calling read(). > >>>>> >>>>>> > >>>>> >>>>>> The protocol would need to be changed to send the "packet" > >>>>> size, but > >>>>> >>>>>> that's not compatible with older JDKs. > >>>>> >>>>>> > >>>>> >>>>>> Otherwise I think we have no choice but to use a > >>>>> non-blocking read ... > >>>>> >>>>>> though I'm still unsure if you can know for certain > >>>>> that you've > >>>>> >>>>>> reached the end of the "packet" ... > >>>>> >>>>>> > >>>>> >>>>>> Thanks, > >>>>> >>>>>> David > >>>>> >>>>>> > >>>>> >>>>>>> > >>>>> >>>>>>> Thanks, > >>>>> >>>>>>> > >>>>> >>>>>>> Yasumasa > >>>>> >>>>>>> > >>>>> >>>>>>> > >>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com > >>>>> wrote: > >>>>> >>>>>>>> Dear Yasumasa, > >>>>> >>>>>>>> The fix you mentioned seems not work as expected. > >>>>> >>>>>>>> I have done an experiment that use jdk1.8's "jcmd > >>>>> help" to > >>>>> >>>>>>>> attach to latest jdk. > >>>>> >>>>>>>> it seem the whole "jcmd help" buffer is not > >>>>> >>>>>>>> read completely at one time. in my case it is "jcmd", > >>>>> "", > >>>>> >>>>>>>> "help", and then block at while(). > >>>>> >>>>>>>> After applied your change, it seems only the "jcmd" is > >>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. > >>>>> >>>>>>>> > >>>>> >>>>>>>> BRs, > >>>>> >>>>>>>> Lin > >>>>> >>>>>>>> > >>>>> From david.holmes at oracle.com Fri Mar 1 04:22:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Mar 2019 14:22:14 +1000 Subject: Protocol version of Attach API In-Reply-To: References: <04aadf26-d2c9-6f65-9815-06ad36c53219@gmail.com> <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> Message-ID: On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: > Hi, > > I agree with David. I think we should backout 8215622. Note that I conceded that if Lin's proposal for changing the 4 back to 3 fixed everything, then I'm okay with making that fix rather than a full backout re-do. I'm not at all convinced we need change the number of args at the protocol level, regardless of the number of apparent "args" the command has. Cheers, David > We should re-do 8215622 completely for all platforms (includes > Windows) and support receiving requests from earlier serviceability > tools. > Problems about arguments of AttachListener should be worked as another issues. > > > Thanks, > > Yasumasa > > > 2019?3?1?(?) 12:39 ?? : >> >> Hi David, >> My understanding about those "arg" is that they are trying to make limitation of the overall message length and make it convince to communicate with sockets. >> I will do more test try to see whether changing back to 3 makes everything fine, and then prepare a webrev. >> Thanks. >> >> Lin >> ________________________________________ >> From: David Holmes >> Sent: Thursday, February 28, 2019 7:55:01 PM >> To: ??; Yasumasa Suenaga >> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> Subject: Re: Protocol version of Attach API >> >> Hi Lin, >> >> On 28/02/2019 7:30 pm, ?? wrote: >>> Hi David, >>> I am a little confused, do you think it is proper to made the patch as a fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't need to backout and REDO? >> >> Generally I'd prefer to do the backout and then apply the revised fix as >> it will make the changes easier to track. >> >> However, if you are saying that everything works fine just by changing >> the 4 back to 3 everywhere, then that does seem a very simple fix to >> apply directly. >> >> I admit that if that does work then I really don't understand what these >> "arg" values actually means. :( Though it would explain why windows >> appears to work fine even though it was left at 3. >> >> Thanks, >> David >> >>> Thanks, >>> LIn >>> ________________________________________ >>> From: ?? >>> Sent: Thursday, February 28, 2019 4:50:12 PM >>> To: David Holmes; Yasumasa Suenaga >>> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >>> Subject: Re: Protocol version of Attach API >>> >>> Dear All, >>> I have tried simply recover the max argument count makes jmap -histo works and also makes the compatibility works fine. >>> Following are the changes I made: >>> >>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp >>> --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 16:48:19 2019 +0800 >>> @@ -106,7 +106,7 @@ >>> enum { >>> name_length_max = 16, // maximum length of name >>> arg_length_max = 1024, // maximum length of argument >>> - arg_count_max = 4 // maximum number of arguments >>> + arg_count_max = 3 // maximum number of arguments >>> }; >>> >>> // name of special operation that can be enqueued when all >>> diff -r 07dd34f487d4 src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 >>> @@ -138,7 +138,7 @@ >>> * Execute the given command in the target VM. >>> */ >>> InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { >>> - assert args.length <= 4; // includes null >>> + assert args.length <= 3; // includes null >>> >>> // did we detach? >>> synchronized (this) { >>> @@ -166,7 +166,7 @@ >>> writeString(s, PROTOCOL_VERSION); >>> writeString(s, cmd); >>> >>> - for (int i = 0; i < 4; i++) { >>> + for (int i = 0; i < 3; i++) { >>> if (i < args.length && args[i] != null) { >>> writeString(s, (String)args[i]); >>> } else { >>> diff -r 07dd34f487d4 src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 >>> @@ -143,7 +143,7 @@ >>> * Execute the given command in the target VM. >>> */ >>> InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { >>> - assert args.length <= 4; // includes null >>> + assert args.length <= 3; // includes null >>> >>> // did we detach? >>> synchronized (this) { >>> diff -r 07dd34f487d4 src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 >>> @@ -139,7 +139,7 @@ >>> * Execute the given command in the target VM. >>> */ >>> InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { >>> - assert args.length <= 4; // includes null >>> + assert args.length <= 3; // includes null >>> >>> // did we detach? >>> synchronized (this) { >>> diff -r 07dd34f487d4 src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 >>> @@ -126,7 +126,7 @@ >>> * Execute the given command in the target VM. >>> */ >>> InputStream execute(String cmd, Object ... args) throws AgentLoadException, IOException { >>> - assert args.length <= 4; // includes null >>> + assert args.length <= 3; // includes null >>> >>> // first check that we are still attached >>> int door; >>> diff -r 07dd34f487d4 src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>> --- a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 02:47:39 2019 +0100 >>> +++ b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java Thu Feb 28 16:48:19 2019 +0800 >>> @@ -77,7 +77,7 @@ >>> InputStream execute(String cmd, Object ... args) >>> throws AgentLoadException, IOException >>> { >>> - assert args.length <= 4; // includes null >>> + assert args.length <= 3; // includes null >>> >>> // create a pipe using a random name >>> Random rnd = new Random(); >>> >>> >>> >>> Thanks, >>> Lin >>> ________________________________________ >>> From: ?? >>> Sent: Thursday, February 28, 2019 3:24:52 PM >>> To: David Holmes; Yasumasa Suenaga >>> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >>> Subject: RE: Protocol version of Attach API >>> >>> Hi David, >>> Since I don't have the access to JBS, may I ask your help to ceate sub-task? Thanks. >>> >>> BRs, >>> Lin >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Thursday, February 28, 2019 3:16 PM >>>> To: ?? ; Yasumasa Suenaga >>>> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >>>> >>>> Subject: Re: Protocol version of Attach API >>>> >>>> Hi Lin, >>>> >>>> On 28/02/2019 4:49 pm, ?? wrote: >>>>> Hi David, >>>>> Your are right and thanks for pointing it out. when I worte that patch, I >>>> was considering implement -filename and -incremental together. and I must >>>> be too stupid to forget recover it when I divided the patch into two. >>>>> And it seems a good solution is to refine the original patch of jmap histo, >>>> and try to composite all args as one when passing it to socket and let >>>> attachlistener to handle the analyze. >>>>> I will try that. >>>>> One more, do I need to consider changing the jmap -dump also? >>>> >>>> I'm assuming -dump already works fine, so I'm just expecting to see -histo >>>> handle the file in a similar manner. >>>> >>>> If you find this works I suggest creating a sub-task of 8215622 to first backout >>>> the original changes (hg backout), and a second sub-task to REDO with the >>>> new implementation. Each will need reviewing separately in their own RFR >>>> thread. >>>> >>>> Thanks, >>>> David >>>> >>>>> BRs, >>>>> Lin >>>>> ________________________________________ >>>>> From: David Holmes >>>>> Sent: Thursday, February 28, 2019 12:59:28 PM >>>>> To: ??; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Sorry I'm going to pick up on the rollback and re-do option here as I >>>>> just had a closer look at jmap. Given jmap -dump already has more >>>>> options than -histo does, why was any change to the "maximum number of >>>>> args" needed in the first place ??? >>>>> >>>>> David >>>>> >>>>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>>>> Hi everyone, >>>>>> >>>>>> I'm not sure we're converging on a suitable solution here, but to >>>>>> address the issues flagged by Lin below ... >>>>>> >>>>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>>>> Hi Suenaga, >>>>>>> >>>>>>> Thanks for your expaination about the arg_length_max, I >>>>>>> generally agree with you that it is better to consider using dynamic >>>>>>> memory, and that would be handled carefully to aviod introduce >>>>>>> compatibility issue, plus it would be a big change. So let?s see >>>>>>> what others suggest. >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> It seems for me that there are basically three problems forked by >>>>>>> this >>>>>>> thread? >>>>>>> >>>>>>> ?Compatibility issue with old jcmd alike tools with attachListener?s >>>>>>> change. >>>>>> >>>>>> This is issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>>>> >>>>>>> ?Only 3 arguments limited to passed by socket to attachListener for >>>>>>> Windows, which cause 8215622 work abnormally on Windows. >>>>>> >>>>>> I have filed a new bug for this: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>>>> >>>>>>> ?The arg_length_max may not be enough for handling filename. >>>>>> >>>>>> I have filed a new bug for this: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>>>> >>>>>> though it seems very related to this issue. >>>>>> >>>>>>> So I suggest we keep the first problem discussed in this thread, and >>>>>>> create separate thread for the others. Do you agree? >>>>>> >>>>>> There is some overlap but yes this can be broken down somewhat - >>>>>> though dealing with the variable length "packet" is going to have to >>>>>> consider that what is received is in fact much larger than the >>>>>> purported maximum packet size if these long paths are expected and >>>> accepted. >>>>>> >>>>>> FWIW I don't see crashes or anything drastic if the arguments are too >>>>>> long - the operations just fail (in somewhat obscure ways sometimes). >>>>>> >>>>>>> >>>>>>> For me, I will refine my patch to use timeout as a fix for the first >>>>>>> one, and update it in this thread. And I will try to fix the second >>>>>>> one for Windows, and create a separate thread for discussing. And if >>>>>>> possible, I can help to fix the third one. >>>>>>> >>>>>>> What?s your opinion? >>>>>> >>>>>> That sounds fine ... >>>>>> >>>>>> Or you could choose to rollback JDK-8215622 and see how to solve that >>>>>> without increasing the arg count. Given this usage: >>>>>> >>>>>> jmap -histo:live,file=foo.txt >>>>>> >>>>>> I'm not sure why this is sent to the VM as multiple args rather than >>>>>> as a single composite arg that can then be parsed again by the actual >>>>>> "jmap" logic. There would be some double-up perhaps if the front-end >>>>>> tool wants to perform the command-line validation, but it would be >>>>>> easy enough I think to do that checking then send the original composite >>>> arg. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> BRs, >>>>>>> >>>>>>> Lin >>>>>>> >>>>>>> *From:*Yasumasa Suenaga >>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>>>> *To:* ?? >>>>>>> *Cc:* David Holmes ; >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> *Subject:* Re: Protocol version of Attach API >>>>>>> >>>>>>> 2019?2?28?(?) 0:04 ?? >>> >: >>>>>>> >>>>>>> Dear Suenaga, >>>>>>> Thanks for your reviewing. I will try to refine the patch. >>>>>>> For the argument length you mentioned, do you mean the >>>>>>> "arg_length_max" should be large enough to accept the max filename >>>>>>> length? >>>>>>> >>>>>>> Yes, but it is not enough. >>>>>>> >>>>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. >>>>>>> >>>>>>> IMHO, all the handling of the argument length is at receiver >>>>>>> side in the attachListener, such as >>>>>>> >>>>>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/linux/att >>>> achListener_linux.cpp#l322, >>>>>>> for me it means that the VM side limits the argments length less >>>>>>> than arg_length_max, otherwise it will return NULL, which cause the >>>>>>> sender side (tools like jcmd and jmap) exits with error message. so >>>>>>> I think there may be no need to limit the argument size in tool side. >>>>>>> >>>>>>> IMHO all programs which use filesystem should support any locations >>>>>>> on it. >>>>>>> >>>>>>> So I think we should use dynamic memory (or GrowableArray) for it if >>>>>>> we do not change client side for compatibility. >>>>>>> >>>>>>> And from my experiment with jmap, the arguments send to >>>>>>> sockets are not arg0 only. as you can see in >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>>>> >>>>>>> and >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>>>> are/classes/sun/tools/jmap/JMap.java#l133, >>>>>>> >>>>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both of >>>>>>> them can be NULL. so 00000 can be >>>>>>> 0000, and file can be null. so 00 may not >>>>>>> indicate it reach the end. >>>>>>> >>>>>>> We should consider for other tools - jstack and jinfo. >>>>>>> >>>>>>> (jstack is ok because it will not have long arguments) >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> BRs, >>>>>>> Lin >>>>>>> ________________________________________ >>>>>>> From: Yasumasa Suenaga >>>>>> > >>>>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>>>> To: ?? >>>>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>>> Hi Lin, >>>>>>> >>>>>>> I think we need to research more about this. >>>>>>> IMHO we need to match length of arguments between >>>>>>> server (AttachListener) and client (serviceability tools) at least. >>>>>>> (please see previous email from me). >>>>>>> >>>>>>> I have some comments for your change: >>>>>>> >>>>>>> On 2019/02/27 18:22, ?? wrote: >>>>>>> > Dear All, >>>>>>> > Here I have figured out one solution based on timeout. would >>>>>>> you like help to see whether this is OK? >>>>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb >>>>>>> 26 14:57:23 2019 +0530 >>>>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed Feb >>>>>>> 27 17:21:48 2019 +0800 >>>>>>> > @@ -263,9 +263,29 @@ >>>>>>> > int off = 0; >>>>>>> > int left = max_len; >>>>>>> > >>>>>>> > + memset(buf, 0, max_len); >>>>>>> > + // set timeout for read >>>>>>> > + struct timeval timeout; >>>>>>> > + timeout.tv_sec = 3; >>>>>>> > + timeout.tv_usec = 0; >>>>>>> >>>>>>> I think timeout value should be configurable. >>>>>>> For example, we can introduce new flag in globals.hpp . >>>>>>> >>>>>>> >>>>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>>>> timeval*)&timeout, sizeof(timeout))) { >>>>>>> > + log_debug(attach)("Failed to set socket option SO_RCVTIMEO: >>>>>>> %s\n", strerror(errorno)); >>>>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: >>>>>>> %s!!!\n", strerror(errno)); >>>>>>> >>>>>>> You should not use printf(), and do you need to pass '\n' to >>>>>>> log_debug()? >>>>>>> >>>>>>> >>>>>>> > + } >>>>>>> > do { >>>>>>> > int n; >>>>>>> > - RESTARTABLE(read(s, buf+off, left), n); >>>>>>> > + log_debug(attach)("start reading data from socket....\n"); >>>>>>> > + n = read(s, buf+off, left); >>>>>>> >>>>>>> You should use RESTARTABLE macro. >>>>>>> read(2) might be interrupted by signal. >>>>>>> >>>>>>> >>>>>>> > + if (n < 0) { >>>>>>> > + if (errno == EWOULDBLOCK) { >>>>>>> >>>>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. >>>>>>> So you should check both errno. >>>>>>> >>>>>>> >>>>>>> > + for (int i = str_count; i < expected_str_count; i++) { >>>>>>> > + //timeout, fill reminded arguments with \0; >>>>>>> > + buf[off+i] = '\0'; >>>>>>> > + str_count++; >>>>>>> > + } >>>>>>> >>>>>>> You set zero to buf[] in above. >>>>>>> So you can remove this loop, and set str_count to expected_str_count >>>>>>> without manipulating buf[]. >>>>>>> >>>>>>> In addition, I prefer to add log_debug() at this >>>>>>> to record NULL arguments are added. >>>>>>> >>>>>>> >>>>>>> > + break;; >>>>>>> > + } >>>>>>> > + } >>>>>>> > assert(n <= left, "buffer was too small, impossible!"); >>>>>>> > buf[max_len - 1] = '\0'; >>>>>>> > if (n == -1) { >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> > Thanks. >>>>>>> > Lin >>>>>>> > >>>>>>> > ________________________________________ >>>>>>> > From: Yasumasa Suenaga >>>>>> > >>>>>>> > Sent: Wednesday, February 27, 2019 15:15 >>>>>>> > To: David Holmes; ?? >>>>>>> > Cc: serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> > Subject: Re: Protocol version of Attach API >>>>>>> > >>>>>>> > On 2019/02/27 15:59, David Holmes wrote: >>>>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>>>> >>> Hi, >>>>>>> >>> >>>>>>> >>> Buffer size for receiving packets from client is >>>>>>> determined at [1]. >>>>>>> >> >>>>>>> >> Maximum buffer size, yes. >>>>>>> >> >>>>>>> >>> It defines length of command name and of argument. >>>>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining >>>>>>> bytes and >>>>>>> >>> might be able to assume all arguments are passed with >>>>>>> empty string. >>>>>>> >> >>>>>>> >> Not sure what you mean. >>>>>>> >> >>>>>>> >> // The buffer is expected to be formatted as follows: >>>>>>> >> // 00000 >>>>>>> >> >>>>>>> >> so we can expect to read at least two things - the ver and cmd. >>>>>>> If we encounter 00 we can infer we reached the end. But we may not >>>>>>> have read the full data into the buffer, so can't tell if another >>>>>>> call to read() is needed yet - you only know after you've read >>>>>>> the 00. >>>>>>> >> >>>>>>> >>> BTW length of arguments is defined to 1024 in [2]. >>>>>>> >>> jcmd and jmap might pas file path - it might be JVM_MAXPATHLEN >>>>>>> (4097 bytes). >>>>>>> >>> Buffer size which is used in AttachListener seems not to >>>>>>> be enough. >>>>>>> >> >>>>>>> >> One has to assume/hope that the code sending the data is working >>>>>>> to the same protocol rules as the receiver! Otherwise this is just >>>>>>> completely broken. >>>>>>> > >>>>>>> > On Linux, client (VirtualMachineImpl) seems not to check length >>>>>>> of arguments: >>>>>>> > >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.attach/ >>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>>>> >>>>>>> > >>>>>>> > In case of jcmd, all options are passed to arg #1. It seems not >>>>>>> to check the length: >>>>>>> > >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcmd/sh >>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>>>> >>>>>>> > >>>>>>> > >>>>>>> > I guess other tools (jstack, jmap, etc) which connect to >>>>>>> AttachListener are same. >>>>>>> > So we can fix both Attach API and AttachListener (it will be big >>>>>>> change!), >>>>>>> > but I concern we can keep protocol version... >>>>>>> > >>>>>>> > >>>>>>> > Thanks, >>>>>>> > >>>>>>> > Yasumasa >>>>>>> > >>>>>>> > >>>>>>> >> David >>>>>>> >> ----- >>>>>>> >> >>>>>>> >>> We might have to change more. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> Thanks, >>>>>>> >>> >>>>>>> >>> Yasumasa >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> [1] >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os/ >>>>>>> linux/attachListener_linux.cpp#l254 >>>>>>> >>>>>>> >>> [2] >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/sha >>>>>>> re/services/attachListener.hpp#l106 >>>>>>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On 2019/02/27 15:00, ?? wrote: >>>>>>> >>>> Another solution I can figure out is try to add timeout for >>>>>>> socket read. I will also investigate whether is works. >>>>>>> >>>> >>>>>>> >>>> Cheers, >>>>>>> >>>> Lin >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>>> -----Original Message----- >>>>>>> >>>>> From: ?? >>>>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>>>> >>>>> To: 'David Holmes' >>>>>> >; Yasumasa Suenaga >>>>>>> >>>>> > >>>>>>> >>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> >>>>> Subject: RE: Protocol version of Attach API >>>>>>> >>>>> >>>>>>> >>>>> Dear David, Yasumasa, >>>>>>> >>>>> I think it is hard to know how long the buffer is >>>>>>> passed from socket >>>>>>> >>>>> without changing the info of the message from the >>>>>>> receiver side. >>>>>>> >>>>> So how about when str_count reach to 3, we test it >>>>>>> with non_blocking >>>>>>> >>>>> read? >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> Cheers, >>>>>>> >>>>> Lin >>>>>>> >>>>>> -----Original Message----- >>>>>>> >>>>>> From: David Holmes >>>>>> > >>>>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>>>> >>>>>> To: Yasumasa Suenaga >>>>>> >; ?? >>>>>> > >>>>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>> >>>>>>> >>>>>> Hi Yasumasa, >>>>>>> >>>>>> >>>>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi Lin, >>>>>>> >>>>>>> >>>>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> AttachListener receives raw command. >>>>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see >>>>>>> >>>>>>> HotSpotVirtualMachine and extended classes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive message >>>>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it well). >>>>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not reach >>>>>>> to maximum. >>>>>>> >>>>>> >>>>>>> >>>>>> I don't see how this approach can work. You have to know >>>> how >>>>>>> many >>>>>>> >>>>>> arguments are coming in the "packet", but that information >>>>>>> is not >>>>>>> >>>>>> available in the current Linux implementation.Without it you >>>>>>> can't >>>>>>> >>>>>> know when to stop calling read(). >>>>>>> >>>>>> >>>>>>> >>>>>> The protocol would need to be changed to send the "packet" >>>>>>> size, but >>>>>>> >>>>>> that's not compatible with older JDKs. >>>>>>> >>>>>> >>>>>>> >>>>>> Otherwise I think we have no choice but to use a >>>>>>> non-blocking read ... >>>>>>> >>>>>> though I'm still unsure if you can know for certain >>>>>>> that you've >>>>>>> >>>>>> reached the end of the "packet" ... >>>>>>> >>>>>> >>>>>>> >>>>>> Thanks, >>>>>>> >>>>>> David >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Yasumasa, >>>>>>> >>>>>>>> The fix you mentioned seems not work as expected. >>>>>>> >>>>>>>> I have done an experiment that use jdk1.8's "jcmd >>>>>>> help" to >>>>>>> >>>>>>>> attach to latest jdk. >>>>>>> >>>>>>>> it seem the whole "jcmd help" buffer is not >>>>>>> >>>>>>>> read completely at one time. in my case it is "jcmd", >>>>>>> "", >>>>>>> >>>>>>>> "help", and then block at while(). >>>>>>> >>>>>>>> After applied your change, it seems only the "jcmd" is >>>>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> BRs, >>>>>>> >>>>>>>> Lin >>>>>>> >>>>>>>> >>>>>>> From dmitry.chuyko at bell-sw.com Fri Mar 1 07:12:51 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 1 Mar 2019 10:12:51 +0300 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> Message-ID: <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> On 3/1/19 6:36 AM, Chris Plummer wrote: > On 2/28/19 5:07 PM, David Holmes wrote: >> Hi Dmitry, >> >> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>> Hello, >>> >>> Please review a small fix for GCC 8.x warning in log_messages.c. >>> Buffer sizes for parts of timestamp string can be adjusted to not >>> exceed maximum buffer size when combined, while being able to hold >>> necessary information. >>> >>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>> Dev-submit job started. >> >> This looks good. >> >> One query: >> >> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >> >> Is this needed so that the size of the buffer is known by gcc inside >> get_time_stamp? (Generally I prefer to see explicitly when an array >> is being stack allocated, not have it hidden behind a typedef.) > This also caught my attention and then got me thinking on what basis > is gcc producing the warning in the first place. The warning is: > > ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: error: > '%.3d' directive output may be truncated writing between 3 and 11 > bytes into a region of size between 0 and 80 [-Werror=format-truncation=] > ??????????????????? "%s.%.3d %s", timestamp_prefix, > ??????????????????????? ^~~~ > > I think it deduced this by seeing that the call to get_time_stamp() is > passing in a char[80] for the tbuf argument. It then also sees that > the argument for the first %s is also a char[80] array, so is pointing > out that this first %s might fill (or nearly fill) tbuf, not leaving > room for the %.3d argument. If this is the case, there is no need for > the timestamp_buffer typedef. The real fix was making > timestamp_date_time and timestamp_timezone smaller so gcc doesn't > think they can overflow tbuf. > > Chris Current signature of helper function is get_time_stamp(char *tbuf, size_t ltbuf). If we drop typedef change, this function either logically needs ltbuf parameter or it internally assumes it to be somewhat (TIMESTAMP_SIZE+1). In first case we in general should care about arbitrary ltbuf size. Like 5 or 2. In second case there are no static checks/hints that we don't pass tbuf of diferent size. So I preferred to have this information in the function signature and to use known lengths of parts: get_time_stamp(timestamp_buffer tbuf). -Dmitry > > >> >> Thanks, >> David >> >> >>> -Dmitry >>> > > From zanglin5 at jd.com Fri Mar 1 09:22:47 2019 From: zanglin5 at jd.com (=?ks_c_5601-1987?B?7fXX+w==?=) Date: Fri, 1 Mar 2019 09:22:47 +0000 Subject: Protocol version of Attach API In-Reply-To: References: <04aadf26-d2c9-6f65-9815-06ad36c53219@gmail.com> <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> Message-ID: Dear All, I have upload a webrev at http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.00/ (just found there is a jank file "abc", I will omit it in next webrev, but let's review other changes first for time saving.) And here are my comments and questions: * With this patch , I have tested with jdk8/jdk11's jcmd/jmap, all works as expected * And passed tier1 test on my linux box * Besides change from 4 to 3 , I also found one compatibility issue of using old "jmap" like "jmap -histo:live", caused by the sequence of arguments for inspectheap. And I have include the fix in the webrev. What I am concerned is that is this trivial enough to avoid revert and redo. IMO, if you think it shoud be revert 8215622 with this change, please let me know. Thanks for all of your help and suggestions. BRs, Lin > -----Original Message----- > From: David Holmes > Sent: Friday, March 1, 2019 12:22 PM > To: Yasumasa Suenaga ; ?? > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > > Subject: Re: Protocol version of Attach API > > On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: > > Hi, > > > > I agree with David. I think we should backout 8215622. > > Note that I conceded that if Lin's proposal for changing the 4 back to 3 fixed > everything, then I'm okay with making that fix rather than a full backout re- > do. > > I'm not at all convinced we need change the number of args at the protocol > level, regardless of the number of apparent "args" the command has. > > Cheers, > David > > > We should re-do 8215622 completely for all platforms (includes > > Windows) and support receiving requests from earlier serviceability > > tools. > > Problems about arguments of AttachListener should be worked as another > issues. > > > > > > Thanks, > > > > Yasumasa > > > > > > 2019?3?1?(?) 12:39 ?? : > >> > >> Hi David, > >> My understanding about those "arg" is that they are trying to make > limitation of the overall message length and make it convince to communicate > with sockets. > >> I will do more test try to see whether changing back to 3 makes > everything fine, and then prepare a webrev. > >> Thanks. > >> > >> Lin > >> ________________________________________ > >> From: David Holmes > >> Sent: Thursday, February 28, 2019 7:55:01 PM > >> To: ??; Yasumasa Suenaga > >> Cc: serviceability-dev at openjdk.java.net > >> serviceability-dev at openjdk.java.net > >> Subject: Re: Protocol version of Attach API > >> > >> Hi Lin, > >> > >> On 28/02/2019 7:30 pm, ?? wrote: > >>> Hi David, > >>> I am a little confused, do you think it is proper to made the patch as a > fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't > need to backout and REDO? > >> > >> Generally I'd prefer to do the backout and then apply the revised fix > >> as it will make the changes easier to track. > >> > >> However, if you are saying that everything works fine just by > >> changing the 4 back to 3 everywhere, then that does seem a very > >> simple fix to apply directly. > >> > >> I admit that if that does work then I really don't understand what > >> these "arg" values actually means. :( Though it would explain why > >> windows appears to work fine even though it was left at 3. > >> > >> Thanks, > >> David > >> > >>> Thanks, > >>> LIn > >>> ________________________________________ > >>> From: ?? > >>> Sent: Thursday, February 28, 2019 4:50:12 PM > >>> To: David Holmes; Yasumasa Suenaga > >>> Cc: serviceability-dev at openjdk.java.net > >>> serviceability-dev at openjdk.java.net > >>> Subject: Re: Protocol version of Attach API > >>> > >>> Dear All, > >>> I have tried simply recover the max argument count makes jmap - > histo works and also makes the compatibility works fine. > >>> Following are the changes I made: > >>> > >>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp > >>> --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 > 02:47:39 2019 +0100 > >>> +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 > 16:48:19 2019 +0800 > >>> @@ -106,7 +106,7 @@ > >>> enum { > >>> name_length_max = 16, // maximum length of name > >>> arg_length_max = 1024, // maximum length of argument > >>> - arg_count_max = 4 // maximum number of arguments > >>> + arg_count_max = 3 // maximum number of arguments > >>> }; > >>> > >>> // name of special operation that can be enqueued when all diff > >>> -r 07dd34f487d4 > src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 02:47:39 2019 +0100 > >>> +++ > b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu > Feb 28 16:48:19 2019 +0800 > >>> @@ -138,7 +138,7 @@ > >>> * Execute the given command in the target VM. > >>> */ > >>> InputStream execute(String cmd, Object ... args) throws > AgentLoadException, IOException { > >>> - assert args.length <= 4; // includes null > >>> + assert args.length <= 3; // includes null > >>> > >>> // did we detach? > >>> synchronized (this) { > >>> @@ -166,7 +166,7 @@ > >>> writeString(s, PROTOCOL_VERSION); > >>> writeString(s, cmd); > >>> > >>> - for (int i = 0; i < 4; i++) { > >>> + for (int i = 0; i < 3; i++) { > >>> if (i < args.length && args[i] != null) { > >>> writeString(s, (String)args[i]); > >>> } else { > >>> diff -r 07dd34f487d4 > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 02:47:39 2019 +0100 > >>> +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 16:48:19 2019 +0800 > >>> @@ -143,7 +143,7 @@ > >>> * Execute the given command in the target VM. > >>> */ > >>> InputStream execute(String cmd, Object ... args) throws > AgentLoadException, IOException { > >>> - assert args.length <= 4; // includes null > >>> + assert args.length <= 3; // includes null > >>> > >>> // did we detach? > >>> synchronized (this) { > >>> diff -r 07dd34f487d4 > src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 02:47:39 2019 +0100 > >>> +++ > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 16:48:19 2019 +0800 > >>> @@ -139,7 +139,7 @@ > >>> * Execute the given command in the target VM. > >>> */ > >>> InputStream execute(String cmd, Object ... args) throws > AgentLoadException, IOException { > >>> - assert args.length <= 4; // includes null > >>> + assert args.length <= 3; // includes null > >>> > >>> // did we detach? > >>> synchronized (this) { > >>> diff -r 07dd34f487d4 > src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- > a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 02:47:39 2019 +0100 > >>> +++ > b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 16:48:19 2019 +0800 > >>> @@ -126,7 +126,7 @@ > >>> * Execute the given command in the target VM. > >>> */ > >>> InputStream execute(String cmd, Object ... args) throws > AgentLoadException, IOException { > >>> - assert args.length <= 4; // includes null > >>> + assert args.length <= 3; // includes null > >>> > >>> // first check that we are still attached > >>> int door; > >>> diff -r 07dd34f487d4 > src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java > >>> --- > a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 02:47:39 2019 +0100 > >>> +++ > b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java > Thu Feb 28 16:48:19 2019 +0800 > >>> @@ -77,7 +77,7 @@ > >>> InputStream execute(String cmd, Object ... args) > >>> throws AgentLoadException, IOException > >>> { > >>> - assert args.length <= 4; // includes null > >>> + assert args.length <= 3; // includes null > >>> > >>> // create a pipe using a random name > >>> Random rnd = new Random(); > >>> > >>> > >>> > >>> Thanks, > >>> Lin > >>> ________________________________________ > >>> From: ?? > >>> Sent: Thursday, February 28, 2019 3:24:52 PM > >>> To: David Holmes; Yasumasa Suenaga > >>> Cc: serviceability-dev at openjdk.java.net > >>> serviceability-dev at openjdk.java.net > >>> Subject: RE: Protocol version of Attach API > >>> > >>> Hi David, > >>> Since I don't have the access to JBS, may I ask your help to ceate sub- > task? Thanks. > >>> > >>> BRs, > >>> Lin > >>> > >>>> -----Original Message----- > >>>> From: David Holmes > >>>> Sent: Thursday, February 28, 2019 3:16 PM > >>>> To: ?? ; Yasumasa Suenaga > > >>>> Cc: serviceability-dev at openjdk.java.net > >>>> serviceability-dev at openjdk.java.net > >>>> > >>>> Subject: Re: Protocol version of Attach API > >>>> > >>>> Hi Lin, > >>>> > >>>> On 28/02/2019 4:49 pm, ?? wrote: > >>>>> Hi David, > >>>>> Your are right and thanks for pointing it out. when I worte > >>>>> that patch, I > >>>> was considering implement -filename and -incremental together. and > >>>> I must be too stupid to forget recover it when I divided the patch into > two. > >>>>> And it seems a good solution is to refine the original > >>>>> patch of jmap histo, > >>>> and try to composite all args as one when passing it to socket and > >>>> let attachlistener to handle the analyze. > >>>>> I will try that. > >>>>> One more, do I need to consider changing the jmap -dump also? > >>>> > >>>> I'm assuming -dump already works fine, so I'm just expecting to see > >>>> -histo handle the file in a similar manner. > >>>> > >>>> If you find this works I suggest creating a sub-task of 8215622 to > >>>> first backout the original changes (hg backout), and a second > >>>> sub-task to REDO with the new implementation. Each will need > >>>> reviewing separately in their own RFR thread. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> BRs, > >>>>> Lin > >>>>> ________________________________________ > >>>>> From: David Holmes > >>>>> Sent: Thursday, February 28, 2019 12:59:28 PM > >>>>> To: ??; Yasumasa Suenaga > >>>>> Cc: serviceability-dev at openjdk.java.net > >>>>> serviceability-dev at openjdk.java.net > >>>>> Subject: Re: Protocol version of Attach API > >>>>> > >>>>> Sorry I'm going to pick up on the rollback and re-do option here > >>>>> as I just had a closer look at jmap. Given jmap -dump already has > >>>>> more options than -histo does, why was any change to the "maximum > >>>>> number of args" needed in the first place ??? > >>>>> > >>>>> David > >>>>> > >>>>> On 28/02/2019 2:43 pm, David Holmes wrote: > >>>>>> Hi everyone, > >>>>>> > >>>>>> I'm not sure we're converging on a suitable solution here, but to > >>>>>> address the issues flagged by Lin below ... > >>>>>> > >>>>>> On 28/02/2019 12:39 pm, ?? wrote: > >>>>>>> Hi Suenaga, > >>>>>>> > >>>>>>> Thanks for your expaination about the arg_length_max, > >>>>>>> I generally agree with you that it is better to consider using > >>>>>>> dynamic memory, and that would be handled carefully to aviod > >>>>>>> introduce compatibility issue, plus it would be a big change. So > >>>>>>> let?s see what others suggest. > >>>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> It seems for me that there are basically three problems forked > >>>>>>> by this > >>>>>>> thread? > >>>>>>> > >>>>>>> ?Compatibility issue with old jcmd alike tools with > >>>>>>> attachListener?s change. > >>>>>> > >>>>>> This is issue: > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 > >>>>>> > >>>>>>> ?Only 3 arguments limited to passed by socket to attachListener > >>>>>>> for Windows, which cause 8215622 work abnormally on Windows. > >>>>>> > >>>>>> I have filed a new bug for this: > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 > >>>>>> > >>>>>>> ?The arg_length_max may not be enough for handling filename. > >>>>>> > >>>>>> I have filed a new bug for this: > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 > >>>>>> > >>>>>> though it seems very related to this issue. > >>>>>> > >>>>>>> So I suggest we keep the first problem discussed in this thread, > >>>>>>> and create separate thread for the others. Do you agree? > >>>>>> > >>>>>> There is some overlap but yes this can be broken down somewhat - > >>>>>> though dealing with the variable length "packet" is going to have > >>>>>> to consider that what is received is in fact much larger than the > >>>>>> purported maximum packet size if these long paths are expected > >>>>>> and > >>>> accepted. > >>>>>> > >>>>>> FWIW I don't see crashes or anything drastic if the arguments are > >>>>>> too long - the operations just fail (in somewhat obscure ways > sometimes). > >>>>>> > >>>>>>> > >>>>>>> For me, I will refine my patch to use timeout as a fix for the > >>>>>>> first one, and update it in this thread. And I will try to fix > >>>>>>> the second one for Windows, and create a separate thread for > >>>>>>> discussing. And if possible, I can help to fix the third one. > >>>>>>> > >>>>>>> What?s your opinion? > >>>>>> > >>>>>> That sounds fine ... > >>>>>> > >>>>>> Or you could choose to rollback JDK-8215622 and see how to solve > >>>>>> that without increasing the arg count. Given this usage: > >>>>>> > >>>>>> jmap -histo:live,file=foo.txt > >>>>>> > >>>>>> I'm not sure why this is sent to the VM as multiple args rather > >>>>>> than as a single composite arg that can then be parsed again by > >>>>>> the actual "jmap" logic. There would be some double-up perhaps if > >>>>>> the front-end tool wants to perform the command-line validation, > >>>>>> but it would be easy enough I think to do that checking then send > >>>>>> the original composite > >>>> arg. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>>> BRs, > >>>>>>> > >>>>>>> Lin > >>>>>>> > >>>>>>> *From:*Yasumasa Suenaga > >>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM > >>>>>>> *To:* ?? > >>>>>>> *Cc:* David Holmes ; > >>>>>>> serviceability-dev at openjdk.java.net > >>>>>>> serviceability-dev at openjdk.java.net > >>>>>>> > >>>>>>> *Subject:* Re: Protocol version of Attach API > >>>>>>> > >>>>>>> 2019?2?28?(?) 0:04 ?? >>>> >: > >>>>>>> > >>>>>>> Dear Suenaga, > >>>>>>> Thanks for your reviewing. I will try to refine the patch. > >>>>>>> For the argument length you mentioned, do you mean the > >>>>>>> "arg_length_max" should be large enough to accept the max > filename > >>>>>>> length? > >>>>>>> > >>>>>>> Yes, but it is not enough. > >>>>>>> > >>>>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. > >>>>>>> > >>>>>>> IMHO, all the handling of the argument length is at receiver > >>>>>>> side in the attachListener, such as > >>>>>>> > >>>>>>> > >>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os > >>>> /linux/att > >>>> achListener_linux.cpp#l322, > >>>>>>> for me it means that the VM side limits the argments length less > >>>>>>> than arg_length_max, otherwise it will return NULL, which cause > the > >>>>>>> sender side (tools like jcmd and jmap) exits with error message. > so > >>>>>>> I think there may be no need to limit the argument size in tool > side. > >>>>>>> > >>>>>>> IMHO all programs which use filesystem should support any > >>>>>>> locations on it. > >>>>>>> > >>>>>>> So I think we should use dynamic memory (or GrowableArray) for > >>>>>>> it if we do not change client side for compatibility. > >>>>>>> > >>>>>>> And from my experiment with jmap, the arguments send to > >>>>>>> sockets are not arg0 only. as you can see in > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm > >>>>>>> d/sh > >>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 > >>>>>>> > >>>>>>> and > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm > >>>>>>> d/sh are/classes/sun/tools/jmap/JMap.java#l133, > >>>>>>> > >>>>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both > of > >>>>>>> them can be NULL. so 00000 can be > >>>>>>> 0000, and file can be null. so 00 > may not > >>>>>>> indicate it reach the end. > >>>>>>> > >>>>>>> We should consider for other tools - jstack and jinfo. > >>>>>>> > >>>>>>> (jstack is ok because it will not have long arguments) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> BRs, > >>>>>>> Lin > >>>>>>> ________________________________________ > >>>>>>> From: Yasumasa Suenaga >>>>>>> > > >>>>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM > >>>>>>> To: ?? > >>>>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net > >>>>>>> > >>>>>>> Subject: Re: Protocol version of Attach API > >>>>>>> > >>>>>>> Hi Lin, > >>>>>>> > >>>>>>> I think we need to research more about this. > >>>>>>> IMHO we need to match length of arguments between > >>>>>>> server (AttachListener) and client (serviceability tools) at least. > >>>>>>> (please see previous email from me). > >>>>>>> > >>>>>>> I have some comments for your change: > >>>>>>> > >>>>>>> On 2019/02/27 18:22, ?? wrote: > >>>>>>> > Dear All, > >>>>>>> > Here I have figured out one solution based on timeout. > would > >>>>>>> you like help to see whether this is OK? > >>>>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb > >>>>>>> 26 14:57:23 2019 +0530 > >>>>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed > Feb > >>>>>>> 27 17:21:48 2019 +0800 > >>>>>>> > @@ -263,9 +263,29 @@ > >>>>>>> > int off = 0; > >>>>>>> > int left = max_len; > >>>>>>> > > >>>>>>> > + memset(buf, 0, max_len); > >>>>>>> > + // set timeout for read > >>>>>>> > + struct timeval timeout; > >>>>>>> > + timeout.tv_sec = 3; > >>>>>>> > + timeout.tv_usec = 0; > >>>>>>> > >>>>>>> I think timeout value should be configurable. > >>>>>>> For example, we can introduce new flag in globals.hpp . > >>>>>>> > >>>>>>> > >>>>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct > >>>>>>> timeval*)&timeout, sizeof(timeout))) { > >>>>>>> > + log_debug(attach)("Failed to set socket option > SO_RCVTIMEO: > >>>>>>> %s\n", strerror(errorno)); > >>>>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: > >>>>>>> %s!!!\n", strerror(errno)); > >>>>>>> > >>>>>>> You should not use printf(), and do you need to pass '\n' to > >>>>>>> log_debug()? > >>>>>>> > >>>>>>> > >>>>>>> > + } > >>>>>>> > do { > >>>>>>> > int n; > >>>>>>> > - RESTARTABLE(read(s, buf+off, left), n); > >>>>>>> > + log_debug(attach)("start reading data from socket....\n"); > >>>>>>> > + n = read(s, buf+off, left); > >>>>>>> > >>>>>>> You should use RESTARTABLE macro. > >>>>>>> read(2) might be interrupted by signal. > >>>>>>> > >>>>>>> > >>>>>>> > + if (n < 0) { > >>>>>>> > + if (errno == EWOULDBLOCK) { > >>>>>>> > >>>>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. > >>>>>>> So you should check both errno. > >>>>>>> > >>>>>>> > >>>>>>> > + for (int i = str_count; i < expected_str_count; i++) { > >>>>>>> > + //timeout, fill reminded arguments with \0; > >>>>>>> > + buf[off+i] = '\0'; > >>>>>>> > + str_count++; > >>>>>>> > + } > >>>>>>> > >>>>>>> You set zero to buf[] in above. > >>>>>>> So you can remove this loop, and set str_count to > expected_str_count > >>>>>>> without manipulating buf[]. > >>>>>>> > >>>>>>> In addition, I prefer to add log_debug() at this > >>>>>>> to record NULL arguments are added. > >>>>>>> > >>>>>>> > >>>>>>> > + break;; > >>>>>>> > + } > >>>>>>> > + } > >>>>>>> > assert(n <= left, "buffer was too small, impossible!"); > >>>>>>> > buf[max_len - 1] = '\0'; > >>>>>>> > if (n == -1) { > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> > Thanks. > >>>>>>> > Lin > >>>>>>> > > >>>>>>> > ________________________________________ > >>>>>>> > From: Yasumasa Suenaga >>>>>>> > > >>>>>>> > Sent: Wednesday, February 27, 2019 15:15 > >>>>>>> > To: David Holmes; ?? > >>>>>>> > Cc: serviceability-dev at openjdk.java.net > >>>>>>> > >>>>>>> > Subject: Re: Protocol version of Attach API > >>>>>>> > > >>>>>>> > On 2019/02/27 15:59, David Holmes wrote: > >>>>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: > >>>>>>> >>> Hi, > >>>>>>> >>> > >>>>>>> >>> Buffer size for receiving packets from client is > >>>>>>> determined at [1]. > >>>>>>> >> > >>>>>>> >> Maximum buffer size, yes. > >>>>>>> >> > >>>>>>> >>> It defines length of command name and of argument. > >>>>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining > >>>>>>> bytes and > >>>>>>> >>> might be able to assume all arguments are passed > >>>>>>> with empty string. > >>>>>>> >> > >>>>>>> >> Not sure what you mean. > >>>>>>> >> > >>>>>>> >> // The buffer is expected to be formatted as follows: > >>>>>>> >> // 00000 > >>>>>>> >> > >>>>>>> >> so we can expect to read at least two things - the ver and > cmd. > >>>>>>> If we encounter 00 we can infer we reached the end. But we may > not > >>>>>>> have read the full data into the buffer, so can't tell if another > >>>>>>> call to read() is needed yet - you only know after you've > >>>>>>> read the 00. > >>>>>>> >> > >>>>>>> >>> BTW length of arguments is defined to 1024 in [2]. > >>>>>>> >>> jcmd and jmap might pas file path - it might be > JVM_MAXPATHLEN > >>>>>>> (4097 bytes). > >>>>>>> >>> Buffer size which is used in AttachListener seems > >>>>>>> not to be enough. > >>>>>>> >> > >>>>>>> >> One has to assume/hope that the code sending the data is > working > >>>>>>> to the same protocol rules as the receiver! Otherwise this is just > >>>>>>> completely broken. > >>>>>>> > > >>>>>>> > On Linux, client (VirtualMachineImpl) seems not to check > length > >>>>>>> of arguments: > >>>>>>> > > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.att > >>>>>>> ach/ > >>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 > >>>>>>> > >>>>>>> > > >>>>>>> > In case of jcmd, all options are passed to arg #1. It seems not > >>>>>>> to check the length: > >>>>>>> > > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm > >>>>>>> d/sh > >>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 > >>>>>>> > >>>>>>> > > >>>>>>> > > >>>>>>> > I guess other tools (jstack, jmap, etc) which connect to > >>>>>>> AttachListener are same. > >>>>>>> > So we can fix both Attach API and AttachListener (it will be big > >>>>>>> change!), > >>>>>>> > but I concern we can keep protocol version... > >>>>>>> > > >>>>>>> > > >>>>>>> > Thanks, > >>>>>>> > > >>>>>>> > Yasumasa > >>>>>>> > > >>>>>>> > > >>>>>>> >> David > >>>>>>> >> ----- > >>>>>>> >> > >>>>>>> >>> We might have to change more. > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> Thanks, > >>>>>>> >>> > >>>>>>> >>> Yasumasa > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> [1] > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot > >>>>>>> /os/ > >>>>>>> linux/attachListener_linux.cpp#l254 > >>>>>>> > >>>>>>> >>> [2] > >>>>>>> > >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot > >>>>>>> /sha > >>>>>>> re/services/attachListener.hpp#l106 > >>>>>>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> On 2019/02/27 15:00, ?? wrote: > >>>>>>> >>>> Another solution I can figure out is try to add timeout for > >>>>>>> socket read. I will also investigate whether is works. > >>>>>>> >>>> > >>>>>>> >>>> Cheers, > >>>>>>> >>>> Lin > >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>>> -----Original Message----- > >>>>>>> >>>>> From: ?? > >>>>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM > >>>>>>> >>>>> To: 'David Holmes' >>>>>>> >; Yasumasa Suenaga > >>>>>>> >>>>> > > >>>>>>> >>>>> Cc: serviceability-dev at openjdk.java.net > >>>>>>> > >>>>>>> >>>>> Subject: RE: Protocol version of Attach API > >>>>>>> >>>>> > >>>>>>> >>>>> Dear David, Yasumasa, > >>>>>>> >>>>> I think it is hard to know how long the buffer is > >>>>>>> passed from socket > >>>>>>> >>>>> without changing the info of the message from the > >>>>>>> receiver side. > >>>>>>> >>>>> So how about when str_count reach to 3, we test it > >>>>>>> with non_blocking > >>>>>>> >>>>> read? > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> Cheers, > >>>>>>> >>>>> Lin > >>>>>>> >>>>>> -----Original Message----- > >>>>>>> >>>>>> From: David Holmes >>>>>>> > > >>>>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM > >>>>>>> >>>>>> To: Yasumasa Suenaga >>>>>>> >; ?? >>>>>>> > > >>>>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net > >>>>>>> > >>>>>>> >>>>>> Subject: Re: Protocol version of Attach API > >>>>>>> >>>>>> > >>>>>>> >>>>>> Hi Yasumasa, > >>>>>>> >>>>>> > >>>>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: > >>>>>>> >>>>>>> Hi Lin, > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> AttachListener receives raw command. > >>>>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see > >>>>>>> >>>>>>> HotSpotVirtualMachine and extended classes. > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive > message > >>>>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it > well). > >>>>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not > reach > >>>>>>> to maximum. > >>>>>>> >>>>>> > >>>>>>> >>>>>> I don't see how this approach can work. You have > >>>>>>> to know > >>>> how > >>>>>>> many > >>>>>>> >>>>>> arguments are coming in the "packet", but that > information > >>>>>>> is not > >>>>>>> >>>>>> available in the current Linux implementation.Without it > you > >>>>>>> can't > >>>>>>> >>>>>> know when to stop calling read(). > >>>>>>> >>>>>> > >>>>>>> >>>>>> The protocol would need to be changed to send the > "packet" > >>>>>>> size, but > >>>>>>> >>>>>> that's not compatible with older JDKs. > >>>>>>> >>>>>> > >>>>>>> >>>>>> Otherwise I think we have no choice but to use a > >>>>>>> non-blocking read ... > >>>>>>> >>>>>> though I'm still unsure if you can know for > >>>>>>> certain that you've > >>>>>>> >>>>>> reached the end of the "packet" ... > >>>>>>> >>>>>> > >>>>>>> >>>>>> Thanks, > >>>>>>> >>>>>> David > >>>>>>> >>>>>> > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> Thanks, > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> Yasumasa > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> > >>>>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com > >>>>>>> wrote: > >>>>>>> >>>>>>>> Dear Yasumasa, > >>>>>>> >>>>>>>> The fix you mentioned seems not work as > expected. > >>>>>>> >>>>>>>> I have done an experiment that use jdk1.8's "jcmd > >>>>>>> help" to > >>>>>>> >>>>>>>> attach to latest jdk. > >>>>>>> >>>>>>>> it seem the whole "jcmd help" buffer is not > >>>>>>> >>>>>>>> read completely at one time. in my case it is "jcmd", > >>>>>>> "", > >>>>>>> >>>>>>>> "help", and then block at while(). > >>>>>>> >>>>>>>> After applied your change, it seems only the "jcmd" > is > >>>>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. > >>>>>>> >>>>>>>> > >>>>>>> >>>>>>>> BRs, > >>>>>>> >>>>>>>> Lin > >>>>>>> >>>>>>>> > >>>>>>> From gary.adams at oracle.com Fri Mar 1 12:15:51 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 01 Mar 2019 07:15:51 -0500 Subject: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing In-Reply-To: <4956c393-fe9e-1d76-5b03-e0a69cc00750@oracle.com> References: <5C6D78F6.6070409@oracle.com> <41cf1b33-1e43-0ee1-e1d9-a07d03a815cb@oracle.com> <693f8837-0498-6a01-5a56-1f2e0bb4e7c3@oracle.com> <89c99e78-cc56-845e-fe23-86b4c927b0d2@oracle.com> <5C7052ED.7020706@oracle.com> <5a1da25a-c4e4-f61b-a483-bfc2be2c3c4c@oracle.com> <41c12dcc-1c1b-5d59-6cc3-9869de85f357@oracle.com> <4956c393-fe9e-1d76-5b03-e0a69cc00750@oracle.com> Message-ID: <5C792276.3070502@oracle.com> I will move the logging statement up. Leaving the "docontinue" in the synchronized block will guarantee the debugger suspends the debuggee main thread without any chance of interference with logging commands. I'm sure this test was left with verbose logging enabled in the hopes of catching more details about the failing sequence of events. In this case it was the excessive logging that was causing the test to hang. Now that the test can run reliably, I think we should turn off the verbose logging. On 2/28/19, 4:44 PM, Alex Menkov wrote: > Hi Gary, > > Now "mainThread is out of: synchronized (lockingObject) {" record is > logged at the end of the scenario and that makes it useless. > > I think it would be better to call > pipe.println("docontinue") after logging of this message: > > log1("mainThread is out of: synchronized (lockingObject) {"); > + pipe.println("docontinue"); > + // wait until the scenario is completed to avoid deadlocks on logging > + synchronized (Threadissuspended002a.waitnotifyObj) { > + Threadissuspended002a.waitnotifyObj.wait(); > + } > > --alex > > On 02/27/2019 02:29, gary.adams at oracle.com wrote: >> Revised webrev : http://cr.openjdk.java.net/~gadams/4903717/webrev.02/ >> >> To prevent the main thread from holding the logging lock when >> the debugger suspends the debuggee, an explicit wait/notify is used >> so the test thread can safely issue log messages while the main thread >> remains suspended. >> >> Testing is in progress. >> >> On 2/26/19 3:49 PM, gary.adams at oracle.com wrote: >>> New fix will be coming tomorrow... >>> >>> I dumped the main and thread2 stacks at the >>> point of the timeout and found they were >>> both contending for the java.io.PrintStream >>> writeln() synchronization block. >>> >>> While writing log messages main thread held the >>> lock and was suspended and thread2 was blocked >>> trying to report it's progress. So thread2 never reaches the >>> breakpoint. >>> >>> java.nio.Buffer:292 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.CharBuffer:1260 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.CharBuffer:265 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.Buffer:223 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.CharBuffer:284 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.HeapCharBuffer:77 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.nio.CharBuffer:396 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> sun.nio.cs.StreamEncoder:280 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> sun.nio.cs.StreamEncoder:125 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.io.OutputStreamWriter:211 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> java.io.BufferedWriter:120 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> *java.io.PrintStream:653 in thread instance of >>> java.lang.Thread(name='main', id=1)* >>> java.io.PrintStream:958 in thread instance of >>> java.lang.Thread(name='main', id=1) >>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:49 in thread >>> instance of java.lang.Thread(name='main', id=1) >>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:124 in thread >>> instance of java.lang.Thread(name='main', id=1) >>> >>> >>> *java.io.PrintStream:650 in thread instance of >>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>> id=589)* >>> java.io.PrintStream:958 in thread instance of >>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>> id=589) >>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:53 in thread >>> instance of >>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>> id=589) >>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a:203 in >>> thread instance of >>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>> id=589) >>> >>> On 2/22/19 11:21 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Gary, >>>> >>>> Thank you for cosmetic changes. >>>> >>>> One thing to notice there is no guard against spurious wakeup for >>>> this: >>>> 108 Threadissuspended002a.waitnotifyObj.wait(); >>>> >>>> But I doubt it causes these timeouts as they are very well >>>> reproducible. >>>> >>>> This time I looked more to the debugger side. >>>> The code is poorly structured, it is hard to understand what it is >>>> doing. >>>> >>>> > - resumed main thread after breakpoint enabled and thread2 >>>> double resume >>>> >>>> Could you, please, explain more how does this help and why timeouts >>>> are intermittent? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/22/19 11:52 AM, Gary Adams wrote: >>>>> After 1000 successful testruns, it seems like a reasonable >>>>> solution is >>>>> to resume the main thread to resolve any locks holding back the >>>>> thread2 reaching the desired breakpoint. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~gadams/4903717/webrev.01/ >>>>> >>>>> Changes in this iteration: >>>>> - cosmetic changes >>>>> - spaces around operators >>>>> - removed extra spaces around parens >>>>> - removed extra blank lines >>>>> - fixed typo in ERRROR >>>>> - fixed curl braces indenting >>>>> - resumed main thread after breakpoint enabled and thread2 >>>>> double resume >>>>> >>>>> >>>>> On 2/22/19, 6:19 AM, gary.adams at oracle.com wrote: >>>>>> I'll make a pass over the code for cosmetic fixes after the test >>>>>> is working correctly. >>>>>> >>>>>> I think the purpose of the lockingObject is to ensure the debugger >>>>>> has time to enable the breakpoint and perform the double resume >>>>>> before debuggee thread2 is released to run to the expected >>>>>> breakpoint. >>>>>> >>>>>> I'm assuming the timeout and break point location are correct, >>>>>> because >>>>>> the test passes most of the time. I'll dump the values to make sure. >>>>>> >>>>>> I'll also try to capture a thread dump at the time of the timeout, >>>>>> to see if the debuggee is hung somewhere unexpected. >>>>>> >>>>>> The test leaves the main thread suspended while thread2 is >>>>>> is resumed. I'll see if resuming the main thread unblocks thread2. >>>>>> >>>>>> ... >>>>>> >>>>>> On 2/21/19 10:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> I do not see any cause of this timeout yet. >>>>>>> However, the synchronization on the lockingObject looks >>>>>>> completely wasteful. >>>>>>> Moreover, it adds unreasonable complexity and makes the test >>>>>>> harder to understand. >>>>>>> >>>>>>> So, I'd suggested to do a small cleanup that includes: >>>>>>> - removing the lockingObject field and sync around it >>>>>>> - fix wrong indents in the fragment: >>>>>>> 161 synchronized (waitnotifyObj) { >>>>>>> 162 log("entered into block: synchronized >>>>>>> (waitnotifyObj)"); >>>>>>> 163 waitnotifyObj.notify(); } >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 2/21/19 10:57, gary.adams at oracle.com wrote: >>>>>>>> The commented out "docontinue" was done to match the style >>>>>>>> used in the other tests. I'll remove it for this test. >>>>>>>> >>>>>>>> In any event, the test still is failing 8 / 500 testruns on >>>>>>>> macosx and windows debug builds. >>>>>>>> >>>>>>>> The change is not sufficient. >>>>>>>> >>>>>>>> Here's a recent failure. You can see in the log that the >>>>>>>> debugger did >>>>>>>> wait until the new "docontinue" arrives outside the lockingObject >>>>>>>> synchronized block. >>>>>>>> >>>>>>>> It appears with the main thread suspended and the thread2 >>>>>>>> double resumed, >>>>>>>> it still does not continue executing up to the breakpoint in >>>>>>>> thread2. >>>>>>>> After the eventQueue.remove(timeout), when the vm is resumed >>>>>>>> you can see the debuggee messages expected leading up to the >>>>>>>> breakpoint. >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> --> debugger: suspending VM with vm.suspend(); >>>>>>>> *debugee.stderr> **> mainThread: mainThread is out of: >>>>>>>> synchronized (lockingObject) {* >>>>>>>> --> debugger: thread2.suspendCount() == 2 >>>>>>>> --> debugger: : thread2.isSuspended() >>>>>>>> --> debugger: mainThread.suspendCount() == 1 >>>>>>>> --> debugger: : mainThread.isSuspended() >>>>>>>> --> debugger: double resuming thread2 with thread2.resume(); >>>>>>>> --> debugger: thread2.suspendCount() == 1 >>>>>>>> --> debugger: : thread2.isSuspended() >>>>>>>> --> debugger: enabling breakpRequest1 >>>>>>>> --> debugger: thread2.suspendCount() == 0 >>>>>>>> --> debugger: : !thread2.isAtBreakpoint() before call to >>>>>>>> breakpoint() >>>>>>>> --> debugger: waiting for BreakpointEvent >>>>>>>> *--> debugger: new: eventSet = eventQueue.remove();* >>>>>>>> # ERROR: ##> debugger: ERROR: timeout for waiting for a >>>>>>>> BreakpintEvent >>>>>>>> The following stacktrace is for failure analysis. >>>>>>>> nsk.share.TestFailure: ##> debugger: ERROR: timeout for >>>>>>>> waiting for a BreakpintEvent >>>>>>>> at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428) >>>>>>>> at nsk.share.Log.complain(Log.java:399) >>>>>>>> at >>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.log3(issuspended002.java:104) >>>>>>>> at >>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.breakpoint(issuspended002.java:555) >>>>>>>> at >>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.runThis(issuspended002.java:389) >>>>>>>> at >>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.run(issuspended002.java:90) >>>>>>>> at >>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.main(issuspended002.java:85) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >>>>>>>> at >>>>>>>> PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>> at >>>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >>>>>>>> at >>>>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >>>>>>>> at java.base/java.lang.Thread.run(Thread.java:835) >>>>>>>> *--> debugger: resuming both second and main thread >>>>>>>> debugee.stderr> **> mainThread: waiting for an instruction from >>>>>>>> the debugger ... --> debugger: the end of testing >>>>>>>> debugee.stderr> **> thread2: entered into block: synchronized >>>>>>>> (lockingObject) debugee.stderr> **> thread2: exited from block: >>>>>>>> synchronized (lockingObject) debugee.stderr> **> thread2: call >>>>>>>> to the method 'runt1' debugee.stderr> **> thread2: method >>>>>>>> 'runt1' enter* >>>>>>>> --> debugger: : returned string is 'checkend' >>>>>>>> debugee.stderr> **> mainThread: waiting for an instruction from >>>>>>>> the debugger ... >>>>>>>> >>>>>>>> >>>>>>>> On 2/20/19 5:15 PM, Alex Menkov wrote: >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> But could you please remove old "pipe.println("docontinue")" >>>>>>>>> statement instead of commenting it out (no new webrev is >>>>>>>>> required) >>>>>>>>> >>>>>>>>> --alex >>>>>>>>> >>>>>>>>> On 02/20/2019 09:58, Chris Plummer wrote: >>>>>>>>>> Looks good. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 2/20/19 7:57 AM, Gary Adams wrote: >>>>>>>>>>> The issuspended002 has been on the ProblemList since the >>>>>>>>>>> tests were moved to >>>>>>>>>>> the open repos. The proposed changeset applies the same fix >>>>>>>>>>> that was used in issuspended001. >>>>>>>>>>> >>>>>>>>>>> The current test fails when the debuggee replies with the >>>>>>>>>>> "docontinue" response, >>>>>>>>>>> while it is still holding a lock in a syncrhonized block. >>>>>>>>>>> When the debugger then >>>>>>>>>>> suspends the vm the debuggee test thread fails to proceed to >>>>>>>>>>> the expected breakpoint. >>>>>>>>>>> Testing in progress. >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-4903717 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/4903717/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From daniel.fuchs at oracle.com Fri Mar 1 15:08:44 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Mar 2019 15:08:44 +0000 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> Message-ID: <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> Hi Severin, On 28/02/2019 15:47, Severin Gehwolf wrote: > Yes, thanks for looking at this Daniel. That was my determination as > well. However, even if we do all of the above, and add a test config > with /etc/hosts mapping a non-loopback address to "localhost" it would > break other tests. E.g. this one: > java/net/InetAddress/GetLocalHostWithSM.java > > So I'd have to explore whether your suggestion with > InetAddress.getLocalHost() is viable. It seems promising. > > I'll keep you posted. Thanks for keeping the investigation going! For what it's worth this is what I have been experimenting with: http://cr.openjdk.java.net/~dfuchs/experiment-8219585/experiment.00/ It's only a POC and obviously need more cleaning. Maybe some of the arbitrary timeouts in the test could be scaled in accordance to timeout-factor (I think there's an adjustTimeout(long) function somewhere in the test libs that does that). I ran it 50 times in our test system - and it passed on all platforms, so there's yet hope :-) hope this helps, -- daniel From sgehwolf at redhat.com Fri Mar 1 15:49:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 01 Mar 2019 16:49:52 +0100 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> Message-ID: <8b47d43d02cb02f89d4af83148b2d54a1d33a2da.camel@redhat.com> On Fri, 2019-03-01 at 15:08 +0000, Daniel Fuchs wrote: > I ran it 50 times in our test system - and it passed on all platforms, > so there's yet hope :-) Thanks for this! I take it, it actually runs the test on some of those test systems (no trivial pass)? Cheers, Severin From daniel.fuchs at oracle.com Fri Mar 1 16:13:18 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Mar 2019 16:13:18 +0000 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <8b47d43d02cb02f89d4af83148b2d54a1d33a2da.camel@redhat.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <8b47d43d02cb02f89d4af83148b2d54a1d33a2da.camel@redhat.com> Message-ID: <3403f08d-56a8-fbdf-b116-689972dd28e5@oracle.com> Hi Severin, On 01/03/2019 15:49, Severin Gehwolf wrote: > On Fri, 2019-03-01 at 15:08 +0000, Daniel Fuchs wrote: >> I ran it 50 times in our test system - and it passed on all platforms, >> so there's yet hope :-) > > Thanks for this! I take it, it actually runs the test on some of those > test systems (no trivial pass)? Yes - AFAICT it ran on all systems - no trivial pass. Used to fail on windows before I changed the parent/child communication channel to use plain stdin instead of relying on signals. Note that I had to tweak the various timeouts to make it pass in a seemingly reliable way - so there's still the risk that it might start failing again in some esoteric configs... best regards, -- daniel > > Cheers, > Severin > From chris.plummer at oracle.com Fri Mar 1 19:07:02 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 1 Mar 2019 11:07:02 -0800 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> Message-ID: On 2/28/19 11:12 PM, Dmitry Chuyko wrote: > On 3/1/19 6:36 AM, Chris Plummer wrote: >> On 2/28/19 5:07 PM, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>>> Hello, >>>> >>>> Please review a small fix for GCC 8.x warning in log_messages.c. >>>> Buffer sizes for parts of timestamp string can be adjusted to not >>>> exceed maximum buffer size when combined, while being able to hold >>>> necessary information. >>>> >>>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>>> Dev-submit job started. >>> >>> This looks good. >>> >>> One query: >>> >>> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >>> >>> Is this needed so that the size of the buffer is known by gcc inside >>> get_time_stamp? (Generally I prefer to see explicitly when an array >>> is being stack allocated, not have it hidden behind a typedef.) >> This also caught my attention and then got me thinking on what basis >> is gcc producing the warning in the first place. The warning is: >> >> ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: error: >> '%.3d' directive output may be truncated writing between 3 and 11 >> bytes into a region of size between 0 and 80 >> [-Werror=format-truncation=] >> ??????????????????? "%s.%.3d %s", timestamp_prefix, >> ??????????????????????? ^~~~ >> >> I think it deduced this by seeing that the call to get_time_stamp() >> is passing in a char[80] for the tbuf argument. It then also sees >> that the argument for the first %s is also a char[80] array, so is >> pointing out that this first %s might fill (or nearly fill) tbuf, not >> leaving room for the %.3d argument. If this is the case, there is no >> need for the timestamp_buffer typedef. The real fix was making >> timestamp_date_time and timestamp_timezone smaller so gcc doesn't >> think they can overflow tbuf. >> >> Chris > > Current signature of helper function is get_time_stamp(char *tbuf, > size_t ltbuf). If we drop typedef change, this function either > logically needs ltbuf parameter or it internally assumes it to be > somewhat (TIMESTAMP_SIZE+1). Hi Dmitry, Ok, but that's unrelated to the compiler warning and not needed for the fix. Using a typedef hides the fact that we are dealing with a char* so makes the code less readable. I actually prefer the way it was with a char* and size_t arguments. My next preference would be: ???? get_time_stamp(char tbuf[MAXLEN_TIMESTAMP+1]) Although I think it's also a bit odd. I don't recall seeing array sizes in function prototypes before. thanks, Chris > In first case we in general should care about arbitrary ltbuf size. > Like 5 or 2. In second case there are no static checks/hints that we > don't pass tbuf of diferent size. So I preferred to have this > information in the function signature and to use known lengths of > parts: get_time_stamp(timestamp_buffer tbuf). > > -Dmitry > >> >> >>> >>> Thanks, >>> David >>> >>> >>>> -Dmitry >>>> >> >> From dmitry.chuyko at bell-sw.com Fri Mar 1 21:46:53 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Sat, 2 Mar 2019 00:46:53 +0300 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> Message-ID: Ok. typedef part removed according to review comments (not related to fix). Updated webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.01/ -Dmitry On 3/1/19 10:07 PM, Chris Plummer wrote: > On 2/28/19 11:12 PM, Dmitry Chuyko wrote: >> On 3/1/19 6:36 AM, Chris Plummer wrote: >>> On 2/28/19 5:07 PM, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>>>> Hello, >>>>> >>>>> Please review a small fix for GCC 8.x warning in log_messages.c. >>>>> Buffer sizes for parts of timestamp string can be adjusted to not >>>>> exceed maximum buffer size when combined, while being able to hold >>>>> necessary information. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>>>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>>>> Dev-submit job started. >>>> >>>> This looks good. >>>> >>>> One query: >>>> >>>> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >>>> >>>> Is this needed so that the size of the buffer is known by gcc >>>> inside get_time_stamp? (Generally I prefer to see explicitly when >>>> an array is being stack allocated, not have it hidden behind a >>>> typedef.) >>> This also caught my attention and then got me thinking on what basis >>> is gcc producing the warning in the first place. The warning is: >>> >>> ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: >>> error: '%.3d' directive output may be truncated writing between 3 >>> and 11 bytes into a region of size between 0 and 80 >>> [-Werror=format-truncation=] >>> ??????????????????? "%s.%.3d %s", timestamp_prefix, >>> ??????????????????????? ^~~~ >>> >>> I think it deduced this by seeing that the call to get_time_stamp() >>> is passing in a char[80] for the tbuf argument. It then also sees >>> that the argument for the first %s is also a char[80] array, so is >>> pointing out that this first %s might fill (or nearly fill) tbuf, >>> not leaving room for the %.3d argument. If this is the case, there >>> is no need for the timestamp_buffer typedef. The real fix was making >>> timestamp_date_time and timestamp_timezone smaller so gcc doesn't >>> think they can overflow tbuf. >>> >>> Chris >> >> Current signature of helper function is get_time_stamp(char *tbuf, >> size_t ltbuf). If we drop typedef change, this function either >> logically needs ltbuf parameter or it internally assumes it to be >> somewhat (TIMESTAMP_SIZE+1). > Hi Dmitry, > > Ok, but that's unrelated to the compiler warning and not needed for > the fix. Using a typedef hides the fact that we are dealing with a > char* so makes the code less readable. I actually prefer the way it > was with a char* and size_t arguments. My next preference would be: > > ???? get_time_stamp(char tbuf[MAXLEN_TIMESTAMP+1]) > > Although I think it's also a bit odd. I don't recall seeing array > sizes in function prototypes before. > > thanks, > > Chris > >> In first case we in general should care about arbitrary ltbuf size. >> Like 5 or 2. In second case there are no static checks/hints that we >> don't pass tbuf of diferent size. So I preferred to have this >> information in the function signature and to use known lengths of >> parts: get_time_stamp(timestamp_buffer tbuf). >> >> -Dmitry >> >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> -Dmitry >>>>> >>> >>> > > From david.holmes at oracle.com Fri Mar 1 22:56:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Mar 2019 08:56:00 +1000 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> Message-ID: Looks good. Thanks, David On 2/03/2019 7:46 am, Dmitry Chuyko wrote: > Ok. typedef part removed according to review comments (not related to fix). > > Updated webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.01/ > > -Dmitry > > On 3/1/19 10:07 PM, Chris Plummer wrote: >> On 2/28/19 11:12 PM, Dmitry Chuyko wrote: >>> On 3/1/19 6:36 AM, Chris Plummer wrote: >>>> On 2/28/19 5:07 PM, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a small fix for GCC 8.x warning in log_messages.c. >>>>>> Buffer sizes for parts of timestamp string can be adjusted to not >>>>>> exceed maximum buffer size when combined, while being able to hold >>>>>> necessary information. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>>>>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>>>>> Dev-submit job started. >>>>> >>>>> This looks good. >>>>> >>>>> One query: >>>>> >>>>> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >>>>> >>>>> Is this needed so that the size of the buffer is known by gcc >>>>> inside get_time_stamp? (Generally I prefer to see explicitly when >>>>> an array is being stack allocated, not have it hidden behind a >>>>> typedef.) >>>> This also caught my attention and then got me thinking on what basis >>>> is gcc producing the warning in the first place. The warning is: >>>> >>>> ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: >>>> error: '%.3d' directive output may be truncated writing between 3 >>>> and 11 bytes into a region of size between 0 and 80 >>>> [-Werror=format-truncation=] >>>> ??????????????????? "%s.%.3d %s", timestamp_prefix, >>>> ??????????????????????? ^~~~ >>>> >>>> I think it deduced this by seeing that the call to get_time_stamp() >>>> is passing in a char[80] for the tbuf argument. It then also sees >>>> that the argument for the first %s is also a char[80] array, so is >>>> pointing out that this first %s might fill (or nearly fill) tbuf, >>>> not leaving room for the %.3d argument. If this is the case, there >>>> is no need for the timestamp_buffer typedef. The real fix was making >>>> timestamp_date_time and timestamp_timezone smaller so gcc doesn't >>>> think they can overflow tbuf. >>>> >>>> Chris >>> >>> Current signature of helper function is get_time_stamp(char *tbuf, >>> size_t ltbuf). If we drop typedef change, this function either >>> logically needs ltbuf parameter or it internally assumes it to be >>> somewhat (TIMESTAMP_SIZE+1). >> Hi Dmitry, >> >> Ok, but that's unrelated to the compiler warning and not needed for >> the fix. Using a typedef hides the fact that we are dealing with a >> char* so makes the code less readable. I actually prefer the way it >> was with a char* and size_t arguments. My next preference would be: >> >> ???? get_time_stamp(char tbuf[MAXLEN_TIMESTAMP+1]) >> >> Although I think it's also a bit odd. I don't recall seeing array >> sizes in function prototypes before. >> >> thanks, >> >> Chris >> >>> In first case we in general should care about arbitrary ltbuf size. >>> Like 5 or 2. In second case there are no static checks/hints that we >>> don't pass tbuf of diferent size. So I preferred to have this >>> information in the function signature and to use known lengths of >>> parts: get_time_stamp(timestamp_buffer tbuf). >>> >>> -Dmitry >>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> -Dmitry >>>>>> >>>> >>>> >> >> From alexey.menkov at oracle.com Fri Mar 1 22:56:47 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 1 Mar 2019 14:56:47 -0800 Subject: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing In-Reply-To: <5C792276.3070502@oracle.com> References: <5C6D78F6.6070409@oracle.com> <41cf1b33-1e43-0ee1-e1d9-a07d03a815cb@oracle.com> <693f8837-0498-6a01-5a56-1f2e0bb4e7c3@oracle.com> <89c99e78-cc56-845e-fe23-86b4c927b0d2@oracle.com> <5C7052ED.7020706@oracle.com> <5a1da25a-c4e4-f61b-a483-bfc2be2c3c4c@oracle.com> <41c12dcc-1c1b-5d59-6cc3-9869de85f357@oracle.com> <4956c393-fe9e-1d76-5b03-e0a69cc00750@oracle.com> <5C792276.3070502@oracle.com> Message-ID: <559fb2df-a02e-b143-d9dd-647b87a07534@oracle.com> On 03/01/2019 04:15, Gary Adams wrote: > I will move the logging statement up. > > Leaving the "docontinue" in the synchronized block > will guarantee the debugger suspends the debuggee > main thread without any chance of interference > with logging commands. > > I'm sure this test was left with verbose logging enabled in the > hopes of catching more details about the failing sequence of > events. In this case it was the excessive logging that was causing > the test to hang. > > Now that the test can run reliably, I think we should turn off > the verbose logging. I think it would be better to keep the logging verbose to simplify analysis if the test fails in the future. --alex > > On 2/28/19, 4:44 PM, Alex Menkov wrote: >> Hi Gary, >> >> Now "mainThread is out of: synchronized (lockingObject) {" record is >> logged at the end of the scenario and that makes it useless. >> >> I think it would be better to call >> pipe.println("docontinue") after logging of this message: >> >> ? log1("mainThread is out of: synchronized (lockingObject) {"); >> +? pipe.println("docontinue"); >> +? // wait until the scenario is completed to avoid deadlocks on logging >> +? synchronized (Threadissuspended002a.waitnotifyObj) { >> +??? Threadissuspended002a.waitnotifyObj.wait(); >> +? } >> >> --alex >> >> On 02/27/2019 02:29, gary.adams at oracle.com wrote: >>> Revised webrev : http://cr.openjdk.java.net/~gadams/4903717/webrev.02/ >>> >>> To prevent the main thread from holding the logging lock when >>> the debugger suspends the debuggee, an explicit wait/notify is used >>> so the test thread can safely issue log messages while the main thread >>> remains suspended. >>> >>> Testing is in progress. >>> >>> On 2/26/19 3:49 PM, gary.adams at oracle.com wrote: >>>> New fix will be coming tomorrow... >>>> >>>> I dumped the main and thread2 stacks at the >>>> point of the timeout and found they were >>>> both contending for the java.io.PrintStream >>>> writeln() synchronization block. >>>> >>>> While writing log messages main thread held the >>>> lock and was suspended and thread2 was blocked >>>> trying to report it's progress. So thread2 never reaches the >>>> breakpoint. >>>> >>>> java.nio.Buffer:292 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.CharBuffer:1260 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.CharBuffer:265 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.Buffer:223 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.CharBuffer:284 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.HeapCharBuffer:77 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.nio.CharBuffer:396 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> sun.nio.cs.StreamEncoder:280 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> sun.nio.cs.StreamEncoder:125 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.io.OutputStreamWriter:211 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> java.io.BufferedWriter:120 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> *java.io.PrintStream:653 in thread instance of >>>> java.lang.Thread(name='main', id=1)* >>>> java.io.PrintStream:958 in thread instance of >>>> java.lang.Thread(name='main', id=1) >>>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:49 in thread >>>> instance of java.lang.Thread(name='main', id=1) >>>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:124 in thread >>>> instance of java.lang.Thread(name='main', id=1) >>>> >>>> >>>> *java.io.PrintStream:650 in thread instance of >>>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>>> id=589)* >>>> java.io.PrintStream:958 in thread instance of >>>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>>> id=589) >>>> nsk.jdi.ThreadReference.isSuspended.issuspended002a:53 in thread >>>> instance of >>>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>>> id=589) >>>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a:203 in >>>> thread instance of >>>> nsk.jdi.ThreadReference.isSuspended.Threadissuspended002a(name='testedThread', >>>> id=589) >>>> >>>> On 2/22/19 11:21 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Gary, >>>>> >>>>> Thank you for cosmetic changes. >>>>> >>>>> One thing to notice there is no guard against spurious wakeup for >>>>> this: >>>>> ?? 108 Threadissuspended002a.waitnotifyObj.wait(); >>>>> >>>>> But I doubt it causes these timeouts as they are very well >>>>> reproducible. >>>>> >>>>> This time I looked more to the debugger side. >>>>> The code is poorly structured, it is hard to understand what it is >>>>> doing. >>>>> >>>>> >?? - resumed main thread after breakpoint enabled and thread2 >>>>> ???? double resume >>>>> >>>>> Could you, please, explain more how does this help and why timeouts >>>>> are intermittent? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 2/22/19 11:52 AM, Gary Adams wrote: >>>>>> After 1000 successful testruns, it seems like a reasonable >>>>>> solution is >>>>>> to resume the main thread to resolve any locks holding back the >>>>>> thread2 reaching the desired breakpoint. >>>>>> >>>>>> ? Updated webrev: >>>>>> http://cr.openjdk.java.net/~gadams/4903717/webrev.01/ >>>>>> >>>>>> Changes in this iteration: >>>>>> ? - cosmetic changes >>>>>> ???? - spaces around operators >>>>>> ???? - removed extra spaces around parens >>>>>> ???? - removed extra blank lines >>>>>> ???? - fixed typo in ERRROR >>>>>> ???? - fixed curl braces indenting >>>>>> ? - resumed main thread after breakpoint enabled and thread2 >>>>>> ???? double resume >>>>>> >>>>>> >>>>>> On 2/22/19, 6:19 AM, gary.adams at oracle.com wrote: >>>>>>> I'll make a pass over the code for cosmetic fixes after the test >>>>>>> is working correctly. >>>>>>> >>>>>>> I think the purpose of the lockingObject is to ensure the debugger >>>>>>> has time to enable the breakpoint and perform the double resume >>>>>>> before debuggee thread2 is released to run to the expected >>>>>>> breakpoint. >>>>>>> >>>>>>> I'm assuming the timeout and break point location are correct, >>>>>>> because >>>>>>> the test passes most of the time. I'll dump the values to make sure. >>>>>>> >>>>>>> I'll also try to capture a thread dump at the time of the timeout, >>>>>>> to see if the debuggee is hung somewhere unexpected. >>>>>>> >>>>>>> The test leaves the main thread suspended while thread2 is >>>>>>> is resumed. I'll see if resuming the main thread unblocks thread2. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> On 2/21/19 10:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> I do not see any cause of this timeout yet. >>>>>>>> However, the synchronization on the lockingObject looks >>>>>>>> completely wasteful. >>>>>>>> Moreover, it adds unreasonable complexity and makes the test >>>>>>>> harder to understand. >>>>>>>> >>>>>>>> So, I'd suggested to do a small cleanup that includes: >>>>>>>> ? - removing the lockingObject field and sync around it >>>>>>>> ? - fix wrong indents in the fragment: >>>>>>>> ? 161???????? synchronized (waitnotifyObj)??????????????????? { >>>>>>>> ? 162???????????? log("entered into block:? synchronized >>>>>>>> (waitnotifyObj)"); >>>>>>>> ? 163???????????? waitnotifyObj.notify();???????????????????? } >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 2/21/19 10:57, gary.adams at oracle.com wrote: >>>>>>>>> The commented out "docontinue" was done to match the style >>>>>>>>> used in the other tests. I'll remove it for this test. >>>>>>>>> >>>>>>>>> In any event, the test still is failing 8 / 500 testruns on >>>>>>>>> macosx and windows debug builds. >>>>>>>>> >>>>>>>>> The change is not sufficient. >>>>>>>>> >>>>>>>>> Here's a recent failure. You can see in the log that the >>>>>>>>> debugger did >>>>>>>>> wait until the new "docontinue" arrives outside the lockingObject >>>>>>>>> synchronized block. >>>>>>>>> >>>>>>>>> It appears with the main thread suspended and the thread2 >>>>>>>>> double resumed, >>>>>>>>> it still does not continue executing up to the breakpoint in >>>>>>>>> thread2. >>>>>>>>> After the eventQueue.remove(timeout), when the vm is resumed >>>>>>>>> you can see the debuggee messages expected leading up to the >>>>>>>>> breakpoint. >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> --> debugger:?????? suspending VM with vm.suspend(); >>>>>>>>> *debugee.stderr> **> mainThread: mainThread is out of: >>>>>>>>> synchronized (lockingObject) {* >>>>>>>>> --> debugger:????????? thread2.suspendCount() == 2 >>>>>>>>> --> debugger:????? :?? thread2.isSuspended() >>>>>>>>> --> debugger:????????? mainThread.suspendCount() == 1 >>>>>>>>> --> debugger:????? :?? mainThread.isSuspended() >>>>>>>>> --> debugger:?????? double resuming thread2 with thread2.resume(); >>>>>>>>> --> debugger:????????? thread2.suspendCount() == 1 >>>>>>>>> --> debugger:????? :?? thread2.isSuspended() >>>>>>>>> --> debugger:????? enabling breakpRequest1 >>>>>>>>> --> debugger:????????? thread2.suspendCount() == 0 >>>>>>>>> --> debugger:????? :? !thread2.isAtBreakpoint() before call to >>>>>>>>> breakpoint() >>>>>>>>> --> debugger:??????? waiting for BreakpointEvent >>>>>>>>> *--> debugger: new: eventSet = eventQueue.remove();* >>>>>>>>> # ERROR: ##> debugger: ERROR:? timeout for waiting for a >>>>>>>>> BreakpintEvent >>>>>>>>> The following stacktrace is for failure analysis. >>>>>>>>> nsk.share.TestFailure: ##> debugger: ERROR:? timeout for >>>>>>>>> waiting for a BreakpintEvent >>>>>>>>> ??? at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428) >>>>>>>>> ??? at nsk.share.Log.complain(Log.java:399) >>>>>>>>> ??? at >>>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.log3(issuspended002.java:104) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.breakpoint(issuspended002.java:555) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.runThis(issuspended002.java:389) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.run(issuspended002.java:90) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> nsk.jdi.ThreadReference.isSuspended.issuspended002.main(issuspended002.java:85) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>> Method) >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> ??? at java.base/java.lang.reflect.Method.invoke(Method.java:567) >>>>>>>>> ??? at >>>>>>>>> PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104) >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>> Method) >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>>> >>>>>>>>> ??? at >>>>>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> ??? at java.base/java.lang.reflect.Method.invoke(Method.java:567) >>>>>>>>> ??? at >>>>>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >>>>>>>>> >>>>>>>>> ??? at java.base/java.lang.Thread.run(Thread.java:835) >>>>>>>>> *--> debugger: resuming both second and main thread >>>>>>>>> debugee.stderr> **> mainThread: waiting for an instruction from >>>>>>>>> the debugger ... --> debugger: the end of testing >>>>>>>>> debugee.stderr> **> thread2: entered into block: synchronized >>>>>>>>> (lockingObject) debugee.stderr> **> thread2: exited from block: >>>>>>>>> synchronized (lockingObject) debugee.stderr> **> thread2: call >>>>>>>>> to the method 'runt1' debugee.stderr> **> thread2: method >>>>>>>>> 'runt1' enter* >>>>>>>>> --> debugger:????? : returned string is 'checkend' >>>>>>>>> debugee.stderr> **> mainThread: waiting for an instruction from >>>>>>>>> the debugger ... >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/20/19 5:15 PM, Alex Menkov wrote: >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> But could you please remove old "pipe.println("docontinue")" >>>>>>>>>> statement instead of commenting it out (no new webrev is >>>>>>>>>> required) >>>>>>>>>> >>>>>>>>>> --alex >>>>>>>>>> >>>>>>>>>> On 02/20/2019 09:58, Chris Plummer wrote: >>>>>>>>>>> Looks good. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 2/20/19 7:57 AM, Gary Adams wrote: >>>>>>>>>>>> The issuspended002 has been on the ProblemList since the >>>>>>>>>>>> tests were moved to >>>>>>>>>>>> the open repos. The proposed changeset applies the same fix >>>>>>>>>>>> that was used in issuspended001. >>>>>>>>>>>> >>>>>>>>>>>> The current test fails when the debuggee replies with the >>>>>>>>>>>> "docontinue" response, >>>>>>>>>>>> while it is still holding a lock in a syncrhonized block. >>>>>>>>>>>> When the debugger then >>>>>>>>>>>> suspends the vm the debuggee test thread fails to proceed to >>>>>>>>>>>> the expected breakpoint. >>>>>>>>>>>> Testing in progress. >>>>>>>>>>>> >>>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-4903717 >>>>>>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/4903717/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From chris.plummer at oracle.com Fri Mar 1 23:28:08 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 1 Mar 2019 15:28:08 -0800 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> Message-ID: <16703b12-cd1c-d497-ea80-1af47dd93805@oracle.com> +1 thanks, Chris On 3/1/19 2:56 PM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 2/03/2019 7:46 am, Dmitry Chuyko wrote: >> Ok. typedef part removed according to review comments (not related to >> fix). >> >> Updated webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.01/ >> >> -Dmitry >> >> On 3/1/19 10:07 PM, Chris Plummer wrote: >>> On 2/28/19 11:12 PM, Dmitry Chuyko wrote: >>>> On 3/1/19 6:36 AM, Chris Plummer wrote: >>>>> On 2/28/19 5:07 PM, David Holmes wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a small fix for GCC 8.x warning in log_messages.c. >>>>>>> Buffer sizes for parts of timestamp string can be adjusted to >>>>>>> not exceed maximum buffer size when combined, while being able >>>>>>> to hold necessary information. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>>>>>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>>>>>> Dev-submit job started. >>>>>> >>>>>> This looks good. >>>>>> >>>>>> One query: >>>>>> >>>>>> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >>>>>> >>>>>> Is this needed so that the size of the buffer is known by gcc >>>>>> inside get_time_stamp? (Generally I prefer to see explicitly when >>>>>> an array is being stack allocated, not have it hidden behind a >>>>>> typedef.) >>>>> This also caught my attention and then got me thinking on what >>>>> basis is gcc producing the warning in the first place. The warning >>>>> is: >>>>> >>>>> ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: >>>>> error: '%.3d' directive output may be truncated writing between 3 >>>>> and 11 bytes into a region of size between 0 and 80 >>>>> [-Werror=format-truncation=] >>>>> ??????????????????? "%s.%.3d %s", timestamp_prefix, >>>>> ??????????????????????? ^~~~ >>>>> >>>>> I think it deduced this by seeing that the call to >>>>> get_time_stamp() is passing in a char[80] for the tbuf argument. >>>>> It then also sees that the argument for the first %s is also a >>>>> char[80] array, so is pointing out that this first %s might fill >>>>> (or nearly fill) tbuf, not leaving room for the %.3d argument. If >>>>> this is the case, there is no need for the timestamp_buffer >>>>> typedef. The real fix was making timestamp_date_time and >>>>> timestamp_timezone smaller so gcc doesn't think they can overflow >>>>> tbuf. >>>>> >>>>> Chris >>>> >>>> Current signature of helper function is get_time_stamp(char *tbuf, >>>> size_t ltbuf). If we drop typedef change, this function either >>>> logically needs ltbuf parameter or it internally assumes it to be >>>> somewhat (TIMESTAMP_SIZE+1). >>> Hi Dmitry, >>> >>> Ok, but that's unrelated to the compiler warning and not needed for >>> the fix. Using a typedef hides the fact that we are dealing with a >>> char* so makes the code less readable. I actually prefer the way it >>> was with a char* and size_t arguments. My next preference would be: >>> >>> ???? get_time_stamp(char tbuf[MAXLEN_TIMESTAMP+1]) >>> >>> Although I think it's also a bit odd. I don't recall seeing array >>> sizes in function prototypes before. >>> >>> thanks, >>> >>> Chris >>> >>>> In first case we in general should care about arbitrary ltbuf size. >>>> Like 5 or 2. In second case there are no static checks/hints that >>>> we don't pass tbuf of diferent size. So I preferred to have this >>>> information in the function signature and to use known lengths of >>>> parts: get_time_stamp(timestamp_buffer tbuf). >>>> >>>> -Dmitry >>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>> >>>>> >>> >>> From daniil.x.titov at oracle.com Sat Mar 2 04:33:07 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 01 Mar 2019 20:33:07 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails Message-ID: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: [0] adjustCompilationLevel [1] adjustCompilationLevel [2] testedMethod [3] run In this case the test looks for the test method only in 2 top frames and fails. The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 Thanks! --Daniil From dean.long at oracle.com Sat Mar 2 05:13:51 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 1 Mar 2019 21:13:51 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> Message-ID: Looks good, but what about sp06t003?? Doesn't it have the same problem?? Are there any other tests using similar logic? dl On 3/1/19 8:33 PM, Daniil Titov wrote: > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > [0] adjustCompilationLevel > [1] adjustCompilationLevel > [2] testedMethod > [3] run > > In this case the test looks for the test method only in 2 top frames and fails. > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > From dmitry.chuyko at bell-sw.com Sat Mar 2 08:51:55 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Sat, 2 Mar 2019 11:51:55 +0300 Subject: RFR(S): 8214854: JDWP: Unforseen output truncation in logging In-Reply-To: <16703b12-cd1c-d497-ea80-1af47dd93805@oracle.com> References: <6b080c3a-27c9-fff5-147c-c5a3baa44c5c@bell-sw.com> <831d28ed-1fd8-90d3-1090-b434e5a6eeb2@oracle.com> <031b21df-8ff7-b08b-8c81-a2825f428bdf@bell-sw.com> <16703b12-cd1c-d497-ea80-1af47dd93805@oracle.com> Message-ID: Thank you for reviews. Pushed. -Dmitry On 3/2/19 2:28 AM, Chris Plummer wrote: > +1 > > thanks, > > Chris > > On 3/1/19 2:56 PM, David Holmes wrote: >> Looks good. >> >> Thanks, >> David >> >> On 2/03/2019 7:46 am, Dmitry Chuyko wrote: >>> Ok. typedef part removed according to review comments (not related >>> to fix). >>> >>> Updated webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.01/ >>> >>> -Dmitry >>> >>> On 3/1/19 10:07 PM, Chris Plummer wrote: >>>> On 2/28/19 11:12 PM, Dmitry Chuyko wrote: >>>>> On 3/1/19 6:36 AM, Chris Plummer wrote: >>>>>> On 2/28/19 5:07 PM, David Holmes wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> On 1/03/2019 6:15 am, Dmitry Chuyko wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a small fix for GCC 8.x warning in >>>>>>>> log_messages.c. Buffer sizes for parts of timestamp string can >>>>>>>> be adjusted to not exceed maximum buffer size when combined, >>>>>>>> while being able to hold necessary information. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dchuyko/8214854/webrev.00/ >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214854 >>>>>>>> testing: after the fix GCC 8 compiles working OpenJDK on Linux. >>>>>>>> Dev-submit job started. >>>>>>> >>>>>>> This looks good. >>>>>>> >>>>>>> One query: >>>>>>> >>>>>>> ?51 typedef char timestamp_buffer[TIMESTAMP_SIZE]; >>>>>>> >>>>>>> Is this needed so that the size of the buffer is known by gcc >>>>>>> inside get_time_stamp? (Generally I prefer to see explicitly >>>>>>> when an array is being stack allocated, not have it hidden >>>>>>> behind a typedef.) >>>>>> This also caught my attention and then got me thinking on what >>>>>> basis is gcc producing the warning in the first place. The >>>>>> warning is: >>>>>> >>>>>> ?src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c:75:24: >>>>>> error: '%.3d' directive output may be truncated writing between 3 >>>>>> and 11 bytes into a region of size between 0 and 80 >>>>>> [-Werror=format-truncation=] >>>>>> ??????????????????? "%s.%.3d %s", timestamp_prefix, >>>>>> ??????????????????????? ^~~~ >>>>>> >>>>>> I think it deduced this by seeing that the call to >>>>>> get_time_stamp() is passing in a char[80] for the tbuf argument. >>>>>> It then also sees that the argument for the first %s is also a >>>>>> char[80] array, so is pointing out that this first %s might fill >>>>>> (or nearly fill) tbuf, not leaving room for the %.3d argument. If >>>>>> this is the case, there is no need for the timestamp_buffer >>>>>> typedef. The real fix was making timestamp_date_time and >>>>>> timestamp_timezone smaller so gcc doesn't think they can overflow >>>>>> tbuf. >>>>>> >>>>>> Chris >>>>> >>>>> Current signature of helper function is get_time_stamp(char *tbuf, >>>>> size_t ltbuf). If we drop typedef change, this function either >>>>> logically needs ltbuf parameter or it internally assumes it to be >>>>> somewhat (TIMESTAMP_SIZE+1). >>>> Hi Dmitry, >>>> >>>> Ok, but that's unrelated to the compiler warning and not needed for >>>> the fix. Using a typedef hides the fact that we are dealing with a >>>> char* so makes the code less readable. I actually prefer the way it >>>> was with a char* and size_t arguments. My next preference would be: >>>> >>>> ???? get_time_stamp(char tbuf[MAXLEN_TIMESTAMP+1]) >>>> >>>> Although I think it's also a bit odd. I don't recall seeing array >>>> sizes in function prototypes before. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>>> In first case we in general should care about arbitrary ltbuf >>>>> size. Like 5 or 2. In second case there are no static checks/hints >>>>> that we don't pass tbuf of diferent size. So I preferred to have >>>>> this information in the function signature and to use known >>>>> lengths of parts: get_time_stamp(timestamp_buffer tbuf). >>>>> >>>>> -Dmitry >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>> >>>>>> >>>> >>>> > > From david.holmes at oracle.com Mon Mar 4 07:22:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Mar 2019 17:22:34 +1000 Subject: Protocol version of Attach API In-Reply-To: References: <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> Message-ID: Hi Lin, I think this is fine to address the problem that was introduced. There's more to be done in this area as there is obviously a misunderstanding about the "args" expected in the "packet" versus the 'args' for any particular command. With this change we can close JDK-8219895 as "Not an issue". Thanks, David On 1/03/2019 7:22 pm, ?? wrote: > Dear All, > I have upload a webrev at http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.00/ (just found there is a jank file "abc", I will omit it in next webrev, but let's review other changes first for time saving.) > And here are my comments and questions: > * With this patch , I have tested with jdk8/jdk11's jcmd/jmap, all works as expected > * And passed tier1 test on my linux box > * Besides change from 4 to 3 , I also found one compatibility issue of using old "jmap" like "jmap -histo:live", caused by the sequence of arguments for inspectheap. And I have include the fix in the webrev. What I am concerned is that is this trivial enough to avoid revert and redo. IMO, if you think it shoud be revert 8215622 with this change, please let me know. > > Thanks for all of your help and suggestions. > > BRs, > Lin > >> -----Original Message----- >> From: David Holmes >> Sent: Friday, March 1, 2019 12:22 PM >> To: Yasumasa Suenaga ; ?? >> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> >> Subject: Re: Protocol version of Attach API >> >> On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I agree with David. I think we should backout 8215622. >> >> Note that I conceded that if Lin's proposal for changing the 4 back to 3 fixed >> everything, then I'm okay with making that fix rather than a full backout re- >> do. >> >> I'm not at all convinced we need change the number of args at the protocol >> level, regardless of the number of apparent "args" the command has. >> >> Cheers, >> David >> >>> We should re-do 8215622 completely for all platforms (includes >>> Windows) and support receiving requests from earlier serviceability >>> tools. >>> Problems about arguments of AttachListener should be worked as another >> issues. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> 2019?3?1?(?) 12:39 ?? : >>>> >>>> Hi David, >>>> My understanding about those "arg" is that they are trying to make >> limitation of the overall message length and make it convince to communicate >> with sockets. >>>> I will do more test try to see whether changing back to 3 makes >> everything fine, and then prepare a webrev. >>>> Thanks. >>>> >>>> Lin >>>> ________________________________________ >>>> From: David Holmes >>>> Sent: Thursday, February 28, 2019 7:55:01 PM >>>> To: ??; Yasumasa Suenaga >>>> Cc: serviceability-dev at openjdk.java.net >>>> serviceability-dev at openjdk.java.net >>>> Subject: Re: Protocol version of Attach API >>>> >>>> Hi Lin, >>>> >>>> On 28/02/2019 7:30 pm, ?? wrote: >>>>> Hi David, >>>>> I am a little confused, do you think it is proper to made the patch as a >> fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't >> need to backout and REDO? >>>> >>>> Generally I'd prefer to do the backout and then apply the revised fix >>>> as it will make the changes easier to track. >>>> >>>> However, if you are saying that everything works fine just by >>>> changing the 4 back to 3 everywhere, then that does seem a very >>>> simple fix to apply directly. >>>> >>>> I admit that if that does work then I really don't understand what >>>> these "arg" values actually means. :( Though it would explain why >>>> windows appears to work fine even though it was left at 3. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> LIn >>>>> ________________________________________ >>>>> From: ?? >>>>> Sent: Thursday, February 28, 2019 4:50:12 PM >>>>> To: David Holmes; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Dear All, >>>>> I have tried simply recover the max argument count makes jmap - >> histo works and also makes the compatibility works fine. >>>>> Following are the changes I made: >>>>> >>>>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp >>>>> --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >> 02:47:39 2019 +0100 >>>>> +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >> 16:48:19 2019 +0800 >>>>> @@ -106,7 +106,7 @@ >>>>> enum { >>>>> name_length_max = 16, // maximum length of name >>>>> arg_length_max = 1024, // maximum length of argument >>>>> - arg_count_max = 4 // maximum number of arguments >>>>> + arg_count_max = 3 // maximum number of arguments >>>>> }; >>>>> >>>>> // name of special operation that can be enqueued when all diff >>>>> -r 07dd34f487d4 >> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu >> Feb 28 16:48:19 2019 +0800 >>>>> @@ -138,7 +138,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> @@ -166,7 +166,7 @@ >>>>> writeString(s, PROTOCOL_VERSION); >>>>> writeString(s, cmd); >>>>> >>>>> - for (int i = 0; i < 4; i++) { >>>>> + for (int i = 0; i < 3; i++) { >>>>> if (i < args.length && args[i] != null) { >>>>> writeString(s, (String)args[i]); >>>>> } else { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -143,7 +143,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -139,7 +139,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -126,7 +126,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // first check that we are still attached >>>>> int door; >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -77,7 +77,7 @@ >>>>> InputStream execute(String cmd, Object ... args) >>>>> throws AgentLoadException, IOException >>>>> { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // create a pipe using a random name >>>>> Random rnd = new Random(); >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Lin >>>>> ________________________________________ >>>>> From: ?? >>>>> Sent: Thursday, February 28, 2019 3:24:52 PM >>>>> To: David Holmes; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: RE: Protocol version of Attach API >>>>> >>>>> Hi David, >>>>> Since I don't have the access to JBS, may I ask your help to ceate sub- >> task? Thanks. >>>>> >>>>> BRs, >>>>> Lin >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Thursday, February 28, 2019 3:16 PM >>>>>> To: ?? ; Yasumasa Suenaga >> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>> >>>>>> Hi Lin, >>>>>> >>>>>> On 28/02/2019 4:49 pm, ?? wrote: >>>>>>> Hi David, >>>>>>> Your are right and thanks for pointing it out. when I worte >>>>>>> that patch, I >>>>>> was considering implement -filename and -incremental together. and >>>>>> I must be too stupid to forget recover it when I divided the patch into >> two. >>>>>>> And it seems a good solution is to refine the original >>>>>>> patch of jmap histo, >>>>>> and try to composite all args as one when passing it to socket and >>>>>> let attachlistener to handle the analyze. >>>>>>> I will try that. >>>>>>> One more, do I need to consider changing the jmap -dump also? >>>>>> >>>>>> I'm assuming -dump already works fine, so I'm just expecting to see >>>>>> -histo handle the file in a similar manner. >>>>>> >>>>>> If you find this works I suggest creating a sub-task of 8215622 to >>>>>> first backout the original changes (hg backout), and a second >>>>>> sub-task to REDO with the new implementation. Each will need >>>>>> reviewing separately in their own RFR thread. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> BRs, >>>>>>> Lin >>>>>>> ________________________________________ >>>>>>> From: David Holmes >>>>>>> Sent: Thursday, February 28, 2019 12:59:28 PM >>>>>>> To: ??; Yasumasa Suenaga >>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>>> Sorry I'm going to pick up on the rollback and re-do option here >>>>>>> as I just had a closer look at jmap. Given jmap -dump already has >>>>>>> more options than -histo does, why was any change to the "maximum >>>>>>> number of args" needed in the first place ??? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I'm not sure we're converging on a suitable solution here, but to >>>>>>>> address the issues flagged by Lin below ... >>>>>>>> >>>>>>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>>>>>> Hi Suenaga, >>>>>>>>> >>>>>>>>> Thanks for your expaination about the arg_length_max, >>>>>>>>> I generally agree with you that it is better to consider using >>>>>>>>> dynamic memory, and that would be handled carefully to aviod >>>>>>>>> introduce compatibility issue, plus it would be a big change. So >>>>>>>>> let?s see what others suggest. >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> It seems for me that there are basically three problems forked >>>>>>>>> by this >>>>>>>>> thread? >>>>>>>>> >>>>>>>>> ?Compatibility issue with old jcmd alike tools with >>>>>>>>> attachListener?s change. >>>>>>>> >>>>>>>> This is issue: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>>>>>> >>>>>>>>> ?Only 3 arguments limited to passed by socket to attachListener >>>>>>>>> for Windows, which cause 8215622 work abnormally on Windows. >>>>>>>> >>>>>>>> I have filed a new bug for this: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>>>>>> >>>>>>>>> ?The arg_length_max may not be enough for handling filename. >>>>>>>> >>>>>>>> I have filed a new bug for this: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>>>>>> >>>>>>>> though it seems very related to this issue. >>>>>>>> >>>>>>>>> So I suggest we keep the first problem discussed in this thread, >>>>>>>>> and create separate thread for the others. Do you agree? >>>>>>>> >>>>>>>> There is some overlap but yes this can be broken down somewhat - >>>>>>>> though dealing with the variable length "packet" is going to have >>>>>>>> to consider that what is received is in fact much larger than the >>>>>>>> purported maximum packet size if these long paths are expected >>>>>>>> and >>>>>> accepted. >>>>>>>> >>>>>>>> FWIW I don't see crashes or anything drastic if the arguments are >>>>>>>> too long - the operations just fail (in somewhat obscure ways >> sometimes). >>>>>>>> >>>>>>>>> >>>>>>>>> For me, I will refine my patch to use timeout as a fix for the >>>>>>>>> first one, and update it in this thread. And I will try to fix >>>>>>>>> the second one for Windows, and create a separate thread for >>>>>>>>> discussing. And if possible, I can help to fix the third one. >>>>>>>>> >>>>>>>>> What?s your opinion? >>>>>>>> >>>>>>>> That sounds fine ... >>>>>>>> >>>>>>>> Or you could choose to rollback JDK-8215622 and see how to solve >>>>>>>> that without increasing the arg count. Given this usage: >>>>>>>> >>>>>>>> jmap -histo:live,file=foo.txt >>>>>>>> >>>>>>>> I'm not sure why this is sent to the VM as multiple args rather >>>>>>>> than as a single composite arg that can then be parsed again by >>>>>>>> the actual "jmap" logic. There would be some double-up perhaps if >>>>>>>> the front-end tool wants to perform the command-line validation, >>>>>>>> but it would be easy enough I think to do that checking then send >>>>>>>> the original composite >>>>>> arg. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> BRs, >>>>>>>>> >>>>>>>>> Lin >>>>>>>>> >>>>>>>>> *From:*Yasumasa Suenaga >>>>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>>>>>> *To:* ?? >>>>>>>>> *Cc:* David Holmes ; >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> *Subject:* Re: Protocol version of Attach API >>>>>>>>> >>>>>>>>> 2019?2?28?(?) 0:04 ?? >>>>> >: >>>>>>>>> >>>>>>>>> Dear Suenaga, >>>>>>>>> Thanks for your reviewing. I will try to refine the patch. >>>>>>>>> For the argument length you mentioned, do you mean the >>>>>>>>> "arg_length_max" should be large enough to accept the max >> filename >>>>>>>>> length? >>>>>>>>> >>>>>>>>> Yes, but it is not enough. >>>>>>>>> >>>>>>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. >>>>>>>>> >>>>>>>>> IMHO, all the handling of the argument length is at receiver >>>>>>>>> side in the attachListener, such as >>>>>>>>> >>>>>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os >>>>>> /linux/att >>>>>> achListener_linux.cpp#l322, >>>>>>>>> for me it means that the VM side limits the argments length less >>>>>>>>> than arg_length_max, otherwise it will return NULL, which cause >> the >>>>>>>>> sender side (tools like jcmd and jmap) exits with error message. >> so >>>>>>>>> I think there may be no need to limit the argument size in tool >> side. >>>>>>>>> >>>>>>>>> IMHO all programs which use filesystem should support any >>>>>>>>> locations on it. >>>>>>>>> >>>>>>>>> So I think we should use dynamic memory (or GrowableArray) for >>>>>>>>> it if we do not change client side for compatibility. >>>>>>>>> >>>>>>>>> And from my experiment with jmap, the arguments send to >>>>>>>>> sockets are not arg0 only. as you can see in >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh >>>>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>>>>>> >>>>>>>>> and >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh are/classes/sun/tools/jmap/JMap.java#l133, >>>>>>>>> >>>>>>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both >> of >>>>>>>>> them can be NULL. so 00000 can be >>>>>>>>> 0000, and file can be null. so 00 >> may not >>>>>>>>> indicate it reach the end. >>>>>>>>> >>>>>>>>> We should consider for other tools - jstack and jinfo. >>>>>>>>> >>>>>>>>> (jstack is ok because it will not have long arguments) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> BRs, >>>>>>>>> Lin >>>>>>>>> ________________________________________ >>>>>>>>> From: Yasumasa Suenaga >>>>>>>> > >>>>>>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>>>>>> To: ?? >>>>>>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>> >>>>>>>>> Hi Lin, >>>>>>>>> >>>>>>>>> I think we need to research more about this. >>>>>>>>> IMHO we need to match length of arguments between >>>>>>>>> server (AttachListener) and client (serviceability tools) at least. >>>>>>>>> (please see previous email from me). >>>>>>>>> >>>>>>>>> I have some comments for your change: >>>>>>>>> >>>>>>>>> On 2019/02/27 18:22, ?? wrote: >>>>>>>>> > Dear All, >>>>>>>>> > Here I have figured out one solution based on timeout. >> would >>>>>>>>> you like help to see whether this is OK? >>>>>>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb >>>>>>>>> 26 14:57:23 2019 +0530 >>>>>>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed >> Feb >>>>>>>>> 27 17:21:48 2019 +0800 >>>>>>>>> > @@ -263,9 +263,29 @@ >>>>>>>>> > int off = 0; >>>>>>>>> > int left = max_len; >>>>>>>>> > >>>>>>>>> > + memset(buf, 0, max_len); >>>>>>>>> > + // set timeout for read >>>>>>>>> > + struct timeval timeout; >>>>>>>>> > + timeout.tv_sec = 3; >>>>>>>>> > + timeout.tv_usec = 0; >>>>>>>>> >>>>>>>>> I think timeout value should be configurable. >>>>>>>>> For example, we can introduce new flag in globals.hpp . >>>>>>>>> >>>>>>>>> >>>>>>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>>>>>> timeval*)&timeout, sizeof(timeout))) { >>>>>>>>> > + log_debug(attach)("Failed to set socket option >> SO_RCVTIMEO: >>>>>>>>> %s\n", strerror(errorno)); >>>>>>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: >>>>>>>>> %s!!!\n", strerror(errno)); >>>>>>>>> >>>>>>>>> You should not use printf(), and do you need to pass '\n' to >>>>>>>>> log_debug()? >>>>>>>>> >>>>>>>>> >>>>>>>>> > + } >>>>>>>>> > do { >>>>>>>>> > int n; >>>>>>>>> > - RESTARTABLE(read(s, buf+off, left), n); >>>>>>>>> > + log_debug(attach)("start reading data from socket....\n"); >>>>>>>>> > + n = read(s, buf+off, left); >>>>>>>>> >>>>>>>>> You should use RESTARTABLE macro. >>>>>>>>> read(2) might be interrupted by signal. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + if (n < 0) { >>>>>>>>> > + if (errno == EWOULDBLOCK) { >>>>>>>>> >>>>>>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. >>>>>>>>> So you should check both errno. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + for (int i = str_count; i < expected_str_count; i++) { >>>>>>>>> > + //timeout, fill reminded arguments with \0; >>>>>>>>> > + buf[off+i] = '\0'; >>>>>>>>> > + str_count++; >>>>>>>>> > + } >>>>>>>>> >>>>>>>>> You set zero to buf[] in above. >>>>>>>>> So you can remove this loop, and set str_count to >> expected_str_count >>>>>>>>> without manipulating buf[]. >>>>>>>>> >>>>>>>>> In addition, I prefer to add log_debug() at this >>>>>>>>> to record NULL arguments are added. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + break;; >>>>>>>>> > + } >>>>>>>>> > + } >>>>>>>>> > assert(n <= left, "buffer was too small, impossible!"); >>>>>>>>> > buf[max_len - 1] = '\0'; >>>>>>>>> > if (n == -1) { >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> > Thanks. >>>>>>>>> > Lin >>>>>>>>> > >>>>>>>>> > ________________________________________ >>>>>>>>> > From: Yasumasa Suenaga >>>>>>>> > >>>>>>>>> > Sent: Wednesday, February 27, 2019 15:15 >>>>>>>>> > To: David Holmes; ?? >>>>>>>>> > Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> > Subject: Re: Protocol version of Attach API >>>>>>>>> > >>>>>>>>> > On 2019/02/27 15:59, David Holmes wrote: >>>>>>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>>>>>> >>> Hi, >>>>>>>>> >>> >>>>>>>>> >>> Buffer size for receiving packets from client is >>>>>>>>> determined at [1]. >>>>>>>>> >> >>>>>>>>> >> Maximum buffer size, yes. >>>>>>>>> >> >>>>>>>>> >>> It defines length of command name and of argument. >>>>>>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining >>>>>>>>> bytes and >>>>>>>>> >>> might be able to assume all arguments are passed >>>>>>>>> with empty string. >>>>>>>>> >> >>>>>>>>> >> Not sure what you mean. >>>>>>>>> >> >>>>>>>>> >> // The buffer is expected to be formatted as follows: >>>>>>>>> >> // 00000 >>>>>>>>> >> >>>>>>>>> >> so we can expect to read at least two things - the ver and >> cmd. >>>>>>>>> If we encounter 00 we can infer we reached the end. But we may >> not >>>>>>>>> have read the full data into the buffer, so can't tell if another >>>>>>>>> call to read() is needed yet - you only know after you've >>>>>>>>> read the 00. >>>>>>>>> >> >>>>>>>>> >>> BTW length of arguments is defined to 1024 in [2]. >>>>>>>>> >>> jcmd and jmap might pas file path - it might be >> JVM_MAXPATHLEN >>>>>>>>> (4097 bytes). >>>>>>>>> >>> Buffer size which is used in AttachListener seems >>>>>>>>> not to be enough. >>>>>>>>> >> >>>>>>>>> >> One has to assume/hope that the code sending the data is >> working >>>>>>>>> to the same protocol rules as the receiver! Otherwise this is just >>>>>>>>> completely broken. >>>>>>>>> > >>>>>>>>> > On Linux, client (VirtualMachineImpl) seems not to check >> length >>>>>>>>> of arguments: >>>>>>>>> > >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.att >>>>>>>>> ach/ >>>>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>>>>>> >>>>>>>>> > >>>>>>>>> > In case of jcmd, all options are passed to arg #1. It seems not >>>>>>>>> to check the length: >>>>>>>>> > >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh >>>>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>>>>>> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > I guess other tools (jstack, jmap, etc) which connect to >>>>>>>>> AttachListener are same. >>>>>>>>> > So we can fix both Attach API and AttachListener (it will be big >>>>>>>>> change!), >>>>>>>>> > but I concern we can keep protocol version... >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > >>>>>>>>> > Yasumasa >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> David >>>>>>>>> >> ----- >>>>>>>>> >> >>>>>>>>> >>> We might have to change more. >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Thanks, >>>>>>>>> >>> >>>>>>>>> >>> Yasumasa >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> [1] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>> /os/ >>>>>>>>> linux/attachListener_linux.cpp#l254 >>>>>>>>> >>>>>>>>> >>> [2] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>> /sha >>>>>>>>> re/services/attachListener.hpp#l106 >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On 2019/02/27 15:00, ?? wrote: >>>>>>>>> >>>> Another solution I can figure out is try to add timeout for >>>>>>>>> socket read. I will also investigate whether is works. >>>>>>>>> >>>> >>>>>>>>> >>>> Cheers, >>>>>>>>> >>>> Lin >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>>> -----Original Message----- >>>>>>>>> >>>>> From: ?? >>>>>>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>>>>>> >>>>> To: 'David Holmes' >>>>>>>> >; Yasumasa Suenaga >>>>>>>>> >>>>> > >>>>>>>>> >>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> >>>>> Subject: RE: Protocol version of Attach API >>>>>>>>> >>>>> >>>>>>>>> >>>>> Dear David, Yasumasa, >>>>>>>>> >>>>> I think it is hard to know how long the buffer is >>>>>>>>> passed from socket >>>>>>>>> >>>>> without changing the info of the message from the >>>>>>>>> receiver side. >>>>>>>>> >>>>> So how about when str_count reach to 3, we test it >>>>>>>>> with non_blocking >>>>>>>>> >>>>> read? >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Cheers, >>>>>>>>> >>>>> Lin >>>>>>>>> >>>>>> -----Original Message----- >>>>>>>>> >>>>>> From: David Holmes >>>>>>>> > >>>>>>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>>>>>> >>>>>> To: Yasumasa Suenaga >>>>>>>> >; ?? >>>>>>>> > >>>>>>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Hi Yasumasa, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>> Hi Lin, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> AttachListener receives raw command. >>>>>>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see >>>>>>>>> >>>>>>> HotSpotVirtualMachine and extended classes. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive >> message >>>>>>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it >> well). >>>>>>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not >> reach >>>>>>>>> to maximum. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I don't see how this approach can work. You have >>>>>>>>> to know >>>>>> how >>>>>>>>> many >>>>>>>>> >>>>>> arguments are coming in the "packet", but that >> information >>>>>>>>> is not >>>>>>>>> >>>>>> available in the current Linux implementation.Without it >> you >>>>>>>>> can't >>>>>>>>> >>>>>> know when to stop calling read(). >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> The protocol would need to be changed to send the >> "packet" >>>>>>>>> size, but >>>>>>>>> >>>>>> that's not compatible with older JDKs. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Otherwise I think we have no choice but to use a >>>>>>>>> non-blocking read ... >>>>>>>>> >>>>>> though I'm still unsure if you can know for >>>>>>>>> certain that you've >>>>>>>>> >>>>>> reached the end of the "packet" ... >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Thanks, >>>>>>>>> >>>>>> David >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Thanks, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Yasumasa >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>> Dear Yasumasa, >>>>>>>>> >>>>>>>> The fix you mentioned seems not work as >> expected. >>>>>>>>> >>>>>>>> I have done an experiment that use jdk1.8's "jcmd >>>>>>>>> help" to >>>>>>>>> >>>>>>>> attach to latest jdk. >>>>>>>>> >>>>>>>> it seem the whole "jcmd help" buffer is not >>>>>>>>> >>>>>>>> read completely at one time. in my case it is "jcmd", >>>>>>>>> "", >>>>>>>>> >>>>>>>> "help", and then block at while(). >>>>>>>>> >>>>>>>> After applied your change, it seems only the "jcmd" >> is >>>>>>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> BRs, >>>>>>>>> >>>>>>>> Lin >>>>>>>>> >>>>>>>> >>>>>>>>> From zanglin5 at jd.com Mon Mar 4 07:30:47 2019 From: zanglin5 at jd.com (=?euc-kr?B?7fXX+w==?=) Date: Mon, 4 Mar 2019 07:30:47 +0000 Subject: Protocol version of Attach API In-Reply-To: References: <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> , Message-ID: Thanks David, I will update the webrev for the fix by EOD today. Then we can review it. I agree with you for more work to do for the args, and that seems the precondition for me to move forward for other enhancement of the jmap/jcmd alike tools. I will try to investigate it. BRs, Lin ________________________________________ From: David Holmes Sent: Monday, March 4, 2019 3:22:34 PM To: ??; Yasumasa Suenaga; Hohensee, Paul Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: Protocol version of Attach API Hi Lin, I think this is fine to address the problem that was introduced. There's more to be done in this area as there is obviously a misunderstanding about the "args" expected in the "packet" versus the 'args' for any particular command. With this change we can close JDK-8219895 as "Not an issue". Thanks, David On 1/03/2019 7:22 pm, ?? wrote: > Dear All, > I have upload a webrev at http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.00/ (just found there is a jank file "abc", I will omit it in next webrev, but let's review other changes first for time saving.) > And here are my comments and questions: > * With this patch , I have tested with jdk8/jdk11's jcmd/jmap, all works as expected > * And passed tier1 test on my linux box > * Besides change from 4 to 3 , I also found one compatibility issue of using old "jmap" like "jmap -histo:live", caused by the sequence of arguments for inspectheap. And I have include the fix in the webrev. What I am concerned is that is this trivial enough to avoid revert and redo. IMO, if you think it shoud be revert 8215622 with this change, please let me know. > > Thanks for all of your help and suggestions. > > BRs, > Lin > >> -----Original Message----- >> From: David Holmes >> Sent: Friday, March 1, 2019 12:22 PM >> To: Yasumasa Suenaga ; ?? >> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> >> Subject: Re: Protocol version of Attach API >> >> On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I agree with David. I think we should backout 8215622. >> >> Note that I conceded that if Lin's proposal for changing the 4 back to 3 fixed >> everything, then I'm okay with making that fix rather than a full backout re- >> do. >> >> I'm not at all convinced we need change the number of args at the protocol >> level, regardless of the number of apparent "args" the command has. >> >> Cheers, >> David >> >>> We should re-do 8215622 completely for all platforms (includes >>> Windows) and support receiving requests from earlier serviceability >>> tools. >>> Problems about arguments of AttachListener should be worked as another >> issues. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> 2019?3?1?(?) 12:39 ?? : >>>> >>>> Hi David, >>>> My understanding about those "arg" is that they are trying to make >> limitation of the overall message length and make it convince to communicate >> with sockets. >>>> I will do more test try to see whether changing back to 3 makes >> everything fine, and then prepare a webrev. >>>> Thanks. >>>> >>>> Lin >>>> ________________________________________ >>>> From: David Holmes >>>> Sent: Thursday, February 28, 2019 7:55:01 PM >>>> To: ??; Yasumasa Suenaga >>>> Cc: serviceability-dev at openjdk.java.net >>>> serviceability-dev at openjdk.java.net >>>> Subject: Re: Protocol version of Attach API >>>> >>>> Hi Lin, >>>> >>>> On 28/02/2019 7:30 pm, ?? wrote: >>>>> Hi David, >>>>> I am a little confused, do you think it is proper to made the patch as a >> fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we don't >> need to backout and REDO? >>>> >>>> Generally I'd prefer to do the backout and then apply the revised fix >>>> as it will make the changes easier to track. >>>> >>>> However, if you are saying that everything works fine just by >>>> changing the 4 back to 3 everywhere, then that does seem a very >>>> simple fix to apply directly. >>>> >>>> I admit that if that does work then I really don't understand what >>>> these "arg" values actually means. :( Though it would explain why >>>> windows appears to work fine even though it was left at 3. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> LIn >>>>> ________________________________________ >>>>> From: ?? >>>>> Sent: Thursday, February 28, 2019 4:50:12 PM >>>>> To: David Holmes; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Dear All, >>>>> I have tried simply recover the max argument count makes jmap - >> histo works and also makes the compatibility works fine. >>>>> Following are the changes I made: >>>>> >>>>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp >>>>> --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >> 02:47:39 2019 +0100 >>>>> +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >> 16:48:19 2019 +0800 >>>>> @@ -106,7 +106,7 @@ >>>>> enum { >>>>> name_length_max = 16, // maximum length of name >>>>> arg_length_max = 1024, // maximum length of argument >>>>> - arg_count_max = 4 // maximum number of arguments >>>>> + arg_count_max = 3 // maximum number of arguments >>>>> }; >>>>> >>>>> // name of special operation that can be enqueued when all diff >>>>> -r 07dd34f487d4 >> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java Thu >> Feb 28 16:48:19 2019 +0800 >>>>> @@ -138,7 +138,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> @@ -166,7 +166,7 @@ >>>>> writeString(s, PROTOCOL_VERSION); >>>>> writeString(s, cmd); >>>>> >>>>> - for (int i = 0; i < 4; i++) { >>>>> + for (int i = 0; i < 3; i++) { >>>>> if (i < args.length && args[i] != null) { >>>>> writeString(s, (String)args[i]); >>>>> } else { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -143,7 +143,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -139,7 +139,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // did we detach? >>>>> synchronized (this) { >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -126,7 +126,7 @@ >>>>> * Execute the given command in the target VM. >>>>> */ >>>>> InputStream execute(String cmd, Object ... args) throws >> AgentLoadException, IOException { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // first check that we are still attached >>>>> int door; >>>>> diff -r 07dd34f487d4 >> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> --- >> a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 02:47:39 2019 +0100 >>>>> +++ >> b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >> Thu Feb 28 16:48:19 2019 +0800 >>>>> @@ -77,7 +77,7 @@ >>>>> InputStream execute(String cmd, Object ... args) >>>>> throws AgentLoadException, IOException >>>>> { >>>>> - assert args.length <= 4; // includes null >>>>> + assert args.length <= 3; // includes null >>>>> >>>>> // create a pipe using a random name >>>>> Random rnd = new Random(); >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Lin >>>>> ________________________________________ >>>>> From: ?? >>>>> Sent: Thursday, February 28, 2019 3:24:52 PM >>>>> To: David Holmes; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: RE: Protocol version of Attach API >>>>> >>>>> Hi David, >>>>> Since I don't have the access to JBS, may I ask your help to ceate sub- >> task? Thanks. >>>>> >>>>> BRs, >>>>> Lin >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Thursday, February 28, 2019 3:16 PM >>>>>> To: ?? ; Yasumasa Suenaga >> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>> >>>>>> Hi Lin, >>>>>> >>>>>> On 28/02/2019 4:49 pm, ?? wrote: >>>>>>> Hi David, >>>>>>> Your are right and thanks for pointing it out. when I worte >>>>>>> that patch, I >>>>>> was considering implement -filename and -incremental together. and >>>>>> I must be too stupid to forget recover it when I divided the patch into >> two. >>>>>>> And it seems a good solution is to refine the original >>>>>>> patch of jmap histo, >>>>>> and try to composite all args as one when passing it to socket and >>>>>> let attachlistener to handle the analyze. >>>>>>> I will try that. >>>>>>> One more, do I need to consider changing the jmap -dump also? >>>>>> >>>>>> I'm assuming -dump already works fine, so I'm just expecting to see >>>>>> -histo handle the file in a similar manner. >>>>>> >>>>>> If you find this works I suggest creating a sub-task of 8215622 to >>>>>> first backout the original changes (hg backout), and a second >>>>>> sub-task to REDO with the new implementation. Each will need >>>>>> reviewing separately in their own RFR thread. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> BRs, >>>>>>> Lin >>>>>>> ________________________________________ >>>>>>> From: David Holmes >>>>>>> Sent: Thursday, February 28, 2019 12:59:28 PM >>>>>>> To: ??; Yasumasa Suenaga >>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>>> Sorry I'm going to pick up on the rollback and re-do option here >>>>>>> as I just had a closer look at jmap. Given jmap -dump already has >>>>>>> more options than -histo does, why was any change to the "maximum >>>>>>> number of args" needed in the first place ??? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I'm not sure we're converging on a suitable solution here, but to >>>>>>>> address the issues flagged by Lin below ... >>>>>>>> >>>>>>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>>>>>> Hi Suenaga, >>>>>>>>> >>>>>>>>> Thanks for your expaination about the arg_length_max, >>>>>>>>> I generally agree with you that it is better to consider using >>>>>>>>> dynamic memory, and that would be handled carefully to aviod >>>>>>>>> introduce compatibility issue, plus it would be a big change. So >>>>>>>>> let?s see what others suggest. >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> It seems for me that there are basically three problems forked >>>>>>>>> by this >>>>>>>>> thread? >>>>>>>>> >>>>>>>>> ?Compatibility issue with old jcmd alike tools with >>>>>>>>> attachListener?s change. >>>>>>>> >>>>>>>> This is issue: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>>>>>> >>>>>>>>> ?Only 3 arguments limited to passed by socket to attachListener >>>>>>>>> for Windows, which cause 8215622 work abnormally on Windows. >>>>>>>> >>>>>>>> I have filed a new bug for this: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>>>>>> >>>>>>>>> ?The arg_length_max may not be enough for handling filename. >>>>>>>> >>>>>>>> I have filed a new bug for this: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>>>>>> >>>>>>>> though it seems very related to this issue. >>>>>>>> >>>>>>>>> So I suggest we keep the first problem discussed in this thread, >>>>>>>>> and create separate thread for the others. Do you agree? >>>>>>>> >>>>>>>> There is some overlap but yes this can be broken down somewhat - >>>>>>>> though dealing with the variable length "packet" is going to have >>>>>>>> to consider that what is received is in fact much larger than the >>>>>>>> purported maximum packet size if these long paths are expected >>>>>>>> and >>>>>> accepted. >>>>>>>> >>>>>>>> FWIW I don't see crashes or anything drastic if the arguments are >>>>>>>> too long - the operations just fail (in somewhat obscure ways >> sometimes). >>>>>>>> >>>>>>>>> >>>>>>>>> For me, I will refine my patch to use timeout as a fix for the >>>>>>>>> first one, and update it in this thread. And I will try to fix >>>>>>>>> the second one for Windows, and create a separate thread for >>>>>>>>> discussing. And if possible, I can help to fix the third one. >>>>>>>>> >>>>>>>>> What?s your opinion? >>>>>>>> >>>>>>>> That sounds fine ... >>>>>>>> >>>>>>>> Or you could choose to rollback JDK-8215622 and see how to solve >>>>>>>> that without increasing the arg count. Given this usage: >>>>>>>> >>>>>>>> jmap -histo:live,file=foo.txt >>>>>>>> >>>>>>>> I'm not sure why this is sent to the VM as multiple args rather >>>>>>>> than as a single composite arg that can then be parsed again by >>>>>>>> the actual "jmap" logic. There would be some double-up perhaps if >>>>>>>> the front-end tool wants to perform the command-line validation, >>>>>>>> but it would be easy enough I think to do that checking then send >>>>>>>> the original composite >>>>>> arg. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> BRs, >>>>>>>>> >>>>>>>>> Lin >>>>>>>>> >>>>>>>>> *From:*Yasumasa Suenaga >>>>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>>>>>> *To:* ?? >>>>>>>>> *Cc:* David Holmes ; >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> *Subject:* Re: Protocol version of Attach API >>>>>>>>> >>>>>>>>> 2019?2?28?(?) 0:04 ?? >>>>> >: >>>>>>>>> >>>>>>>>> Dear Suenaga, >>>>>>>>> Thanks for your reviewing. I will try to refine the patch. >>>>>>>>> For the argument length you mentioned, do you mean the >>>>>>>>> "arg_length_max" should be large enough to accept the max >> filename >>>>>>>>> length? >>>>>>>>> >>>>>>>>> Yes, but it is not enough. >>>>>>>>> >>>>>>>>> For example, jcmd VM.log might pass 2 or more paths to define logs. >>>>>>>>> >>>>>>>>> IMHO, all the handling of the argument length is at receiver >>>>>>>>> side in the attachListener, such as >>>>>>>>> >>>>>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os >>>>>> /linux/att >>>>>> achListener_linux.cpp#l322, >>>>>>>>> for me it means that the VM side limits the argments length less >>>>>>>>> than arg_length_max, otherwise it will return NULL, which cause >> the >>>>>>>>> sender side (tools like jcmd and jmap) exits with error message. >> so >>>>>>>>> I think there may be no need to limit the argument size in tool >> side. >>>>>>>>> >>>>>>>>> IMHO all programs which use filesystem should support any >>>>>>>>> locations on it. >>>>>>>>> >>>>>>>>> So I think we should use dynamic memory (or GrowableArray) for >>>>>>>>> it if we do not change client side for compatibility. >>>>>>>>> >>>>>>>>> And from my experiment with jmap, the arguments send to >>>>>>>>> sockets are not arg0 only. as you can see in >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh >>>>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>>>>>> >>>>>>>>> and >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh are/classes/sun/tools/jmap/JMap.java#l133, >>>>>>>>> >>>>>>>>> jmap can pass arg0 as "filename", and arg1 as "-live", and both >> of >>>>>>>>> them can be NULL. so 00000 can be >>>>>>>>> 0000, and file can be null. so 00 >> may not >>>>>>>>> indicate it reach the end. >>>>>>>>> >>>>>>>>> We should consider for other tools - jstack and jinfo. >>>>>>>>> >>>>>>>>> (jstack is ok because it will not have long arguments) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> BRs, >>>>>>>>> Lin >>>>>>>>> ________________________________________ >>>>>>>>> From: Yasumasa Suenaga >>>>>>>> > >>>>>>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>>>>>> To: ?? >>>>>>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>> >>>>>>>>> Hi Lin, >>>>>>>>> >>>>>>>>> I think we need to research more about this. >>>>>>>>> IMHO we need to match length of arguments between >>>>>>>>> server (AttachListener) and client (serviceability tools) at least. >>>>>>>>> (please see previous email from me). >>>>>>>>> >>>>>>>>> I have some comments for your change: >>>>>>>>> >>>>>>>>> On 2019/02/27 18:22, ?? wrote: >>>>>>>>> > Dear All, >>>>>>>>> > Here I have figured out one solution based on timeout. >> would >>>>>>>>> you like help to see whether this is OK? >>>>>>>>> > --- a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb >>>>>>>>> 26 14:57:23 2019 +0530 >>>>>>>>> > +++ b/src/hotspot/os/linux/attachListener_linux.cpp Wed >> Feb >>>>>>>>> 27 17:21:48 2019 +0800 >>>>>>>>> > @@ -263,9 +263,29 @@ >>>>>>>>> > int off = 0; >>>>>>>>> > int left = max_len; >>>>>>>>> > >>>>>>>>> > + memset(buf, 0, max_len); >>>>>>>>> > + // set timeout for read >>>>>>>>> > + struct timeval timeout; >>>>>>>>> > + timeout.tv_sec = 3; >>>>>>>>> > + timeout.tv_usec = 0; >>>>>>>>> >>>>>>>>> I think timeout value should be configurable. >>>>>>>>> For example, we can introduce new flag in globals.hpp . >>>>>>>>> >>>>>>>>> >>>>>>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>>>>>> timeval*)&timeout, sizeof(timeout))) { >>>>>>>>> > + log_debug(attach)("Failed to set socket option >> SO_RCVTIMEO: >>>>>>>>> %s\n", strerror(errorno)); >>>>>>>>> > + printf("Warning: Failed to set socket option SO_RCVTIMEO: >>>>>>>>> %s!!!\n", strerror(errno)); >>>>>>>>> >>>>>>>>> You should not use printf(), and do you need to pass '\n' to >>>>>>>>> log_debug()? >>>>>>>>> >>>>>>>>> >>>>>>>>> > + } >>>>>>>>> > do { >>>>>>>>> > int n; >>>>>>>>> > - RESTARTABLE(read(s, buf+off, left), n); >>>>>>>>> > + log_debug(attach)("start reading data from socket....\n"); >>>>>>>>> > + n = read(s, buf+off, left); >>>>>>>>> >>>>>>>>> You should use RESTARTABLE macro. >>>>>>>>> read(2) might be interrupted by signal. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + if (n < 0) { >>>>>>>>> > + if (errno == EWOULDBLOCK) { >>>>>>>>> >>>>>>>>> According to man page, read(2) sets EWOULDBLOCK or EAGAIN. >>>>>>>>> So you should check both errno. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + for (int i = str_count; i < expected_str_count; i++) { >>>>>>>>> > + //timeout, fill reminded arguments with \0; >>>>>>>>> > + buf[off+i] = '\0'; >>>>>>>>> > + str_count++; >>>>>>>>> > + } >>>>>>>>> >>>>>>>>> You set zero to buf[] in above. >>>>>>>>> So you can remove this loop, and set str_count to >> expected_str_count >>>>>>>>> without manipulating buf[]. >>>>>>>>> >>>>>>>>> In addition, I prefer to add log_debug() at this >>>>>>>>> to record NULL arguments are added. >>>>>>>>> >>>>>>>>> >>>>>>>>> > + break;; >>>>>>>>> > + } >>>>>>>>> > + } >>>>>>>>> > assert(n <= left, "buffer was too small, impossible!"); >>>>>>>>> > buf[max_len - 1] = '\0'; >>>>>>>>> > if (n == -1) { >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> > Thanks. >>>>>>>>> > Lin >>>>>>>>> > >>>>>>>>> > ________________________________________ >>>>>>>>> > From: Yasumasa Suenaga >>>>>>>> > >>>>>>>>> > Sent: Wednesday, February 27, 2019 15:15 >>>>>>>>> > To: David Holmes; ?? >>>>>>>>> > Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> > Subject: Re: Protocol version of Attach API >>>>>>>>> > >>>>>>>>> > On 2019/02/27 15:59, David Holmes wrote: >>>>>>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>>>>>> >>> Hi, >>>>>>>>> >>> >>>>>>>>> >>> Buffer size for receiving packets from client is >>>>>>>>> determined at [1]. >>>>>>>>> >> >>>>>>>>> >> Maximum buffer size, yes. >>>>>>>>> >> >>>>>>>>> >>> It defines length of command name and of argument. >>>>>>>>> >>> It is passed via Unix domain, so we fill '\0' to remaining >>>>>>>>> bytes and >>>>>>>>> >>> might be able to assume all arguments are passed >>>>>>>>> with empty string. >>>>>>>>> >> >>>>>>>>> >> Not sure what you mean. >>>>>>>>> >> >>>>>>>>> >> // The buffer is expected to be formatted as follows: >>>>>>>>> >> // 00000 >>>>>>>>> >> >>>>>>>>> >> so we can expect to read at least two things - the ver and >> cmd. >>>>>>>>> If we encounter 00 we can infer we reached the end. But we may >> not >>>>>>>>> have read the full data into the buffer, so can't tell if another >>>>>>>>> call to read() is needed yet - you only know after you've >>>>>>>>> read the 00. >>>>>>>>> >> >>>>>>>>> >>> BTW length of arguments is defined to 1024 in [2]. >>>>>>>>> >>> jcmd and jmap might pas file path - it might be >> JVM_MAXPATHLEN >>>>>>>>> (4097 bytes). >>>>>>>>> >>> Buffer size which is used in AttachListener seems >>>>>>>>> not to be enough. >>>>>>>>> >> >>>>>>>>> >> One has to assume/hope that the code sending the data is >> working >>>>>>>>> to the same protocol rules as the receiver! Otherwise this is just >>>>>>>>> completely broken. >>>>>>>>> > >>>>>>>>> > On Linux, client (VirtualMachineImpl) seems not to check >> length >>>>>>>>> of arguments: >>>>>>>>> > >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.att >>>>>>>>> ach/ >>>>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>>>>>> >>>>>>>>> > >>>>>>>>> > In case of jcmd, all options are passed to arg #1. It seems not >>>>>>>>> to check the length: >>>>>>>>> > >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>> d/sh >>>>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>>>>>> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > I guess other tools (jstack, jmap, etc) which connect to >>>>>>>>> AttachListener are same. >>>>>>>>> > So we can fix both Attach API and AttachListener (it will be big >>>>>>>>> change!), >>>>>>>>> > but I concern we can keep protocol version... >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > >>>>>>>>> > Yasumasa >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> David >>>>>>>>> >> ----- >>>>>>>>> >> >>>>>>>>> >>> We might have to change more. >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Thanks, >>>>>>>>> >>> >>>>>>>>> >>> Yasumasa >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> [1] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>> /os/ >>>>>>>>> linux/attachListener_linux.cpp#l254 >>>>>>>>> >>>>>>>>> >>> [2] >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>> /sha >>>>>>>>> re/services/attachListener.hpp#l106 >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On 2019/02/27 15:00, ?? wrote: >>>>>>>>> >>>> Another solution I can figure out is try to add timeout for >>>>>>>>> socket read. I will also investigate whether is works. >>>>>>>>> >>>> >>>>>>>>> >>>> Cheers, >>>>>>>>> >>>> Lin >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>>> -----Original Message----- >>>>>>>>> >>>>> From: ?? >>>>>>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>>>>>> >>>>> To: 'David Holmes' >>>>>>>> >; Yasumasa Suenaga >>>>>>>>> >>>>> > >>>>>>>>> >>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> >>>>> Subject: RE: Protocol version of Attach API >>>>>>>>> >>>>> >>>>>>>>> >>>>> Dear David, Yasumasa, >>>>>>>>> >>>>> I think it is hard to know how long the buffer is >>>>>>>>> passed from socket >>>>>>>>> >>>>> without changing the info of the message from the >>>>>>>>> receiver side. >>>>>>>>> >>>>> So how about when str_count reach to 3, we test it >>>>>>>>> with non_blocking >>>>>>>>> >>>>> read? >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Cheers, >>>>>>>>> >>>>> Lin >>>>>>>>> >>>>>> -----Original Message----- >>>>>>>>> >>>>>> From: David Holmes >>>>>>>> > >>>>>>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>>>>>> >>>>>> To: Yasumasa Suenaga >>>>>>>> >; ?? >>>>>>>> > >>>>>>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Hi Yasumasa, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>> Hi Lin, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> My proposal is a just idea, so you need to tweak it. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> AttachListener receives raw command. >>>>>>>>> >>>>>>> For example, jcmd is `jcmd\0`. Please see >>>>>>>>> >>>>>>> HotSpotVirtualMachine and extended classes. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> In case of jcmd, I guess AttachListener will receive >> message >>>>>>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not check it >> well). >>>>>>>>> >>>>>>> So I guess we can add '\0' when `str_count` does not >> reach >>>>>>>>> to maximum. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I don't see how this approach can work. You have >>>>>>>>> to know >>>>>> how >>>>>>>>> many >>>>>>>>> >>>>>> arguments are coming in the "packet", but that >> information >>>>>>>>> is not >>>>>>>>> >>>>>> available in the current Linux implementation.Without it >> you >>>>>>>>> can't >>>>>>>>> >>>>>> know when to stop calling read(). >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> The protocol would need to be changed to send the >> "packet" >>>>>>>>> size, but >>>>>>>>> >>>>>> that's not compatible with older JDKs. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Otherwise I think we have no choice but to use a >>>>>>>>> non-blocking read ... >>>>>>>>> >>>>>> though I'm still unsure if you can know for >>>>>>>>> certain that you've >>>>>>>>> >>>>>> reached the end of the "packet" ... >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Thanks, >>>>>>>>> >>>>>> David >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Thanks, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Yasumasa >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>> Dear Yasumasa, >>>>>>>>> >>>>>>>> The fix you mentioned seems not work as >> expected. >>>>>>>>> >>>>>>>> I have done an experiment that use jdk1.8's "jcmd >>>>>>>>> help" to >>>>>>>>> >>>>>>>> attach to latest jdk. >>>>>>>>> >>>>>>>> it seem the whole "jcmd help" buffer is not >>>>>>>>> >>>>>>>> read completely at one time. in my case it is "jcmd", >>>>>>>>> "", >>>>>>>>> >>>>>>>> "help", and then block at while(). >>>>>>>>> >>>>>>>> After applied your change, it seems only the "jcmd" >> is >>>>>>>>> >>>>>>>> processed, the "", "help" is replaced by '\0'. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> BRs, >>>>>>>>> >>>>>>>> Lin >>>>>>>>> >>>>>>>> >>>>>>>>> From david.holmes at oracle.com Mon Mar 4 07:34:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Mar 2019 17:34:10 +1000 Subject: Protocol version of Attach API In-Reply-To: References: <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> Message-ID: <70cd6709-0f75-2a1b-33c6-e482fe2d6bd0@oracle.com> PS. This should be sent out in a proper RFR thread for JDK-8219721 Thanks, David On 4/03/2019 5:22 pm, David Holmes wrote: > Hi Lin, > > I think this is fine to address the problem that was introduced. > > There's more to be done in this area as there is obviously a > misunderstanding about the "args" expected in the "packet" versus the > 'args' for any particular command. > > With this change we can close JDK-8219895 as "Not an issue". > > Thanks, > David > > > On 1/03/2019 7:22 pm, ?? wrote: >> Dear All, >> ????? I have upload a webrev at >> http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.00/ (just found >> there is a jank file "abc", I will omit it in next webrev, but let's >> review other changes first for time saving.) >> ????? And here are my comments and questions: >> ???? * With this patch , I have tested with jdk8/jdk11's jcmd/jmap, >> all works as expected >> ???? * And passed tier1 test on my linux box >> ???? * Besides change from 4 to 3 , I also found one compatibility >> issue of using old "jmap" like "jmap -histo:live", caused by the >> sequence of arguments for inspectheap. And I have include the fix in >> the webrev. What I am concerned is that is this trivial enough to >> avoid revert and redo. IMO, if you think it shoud be revert 8215622 >> with this change, please let me know. >> >> ????? Thanks for all of your help and suggestions. >> >> BRs, >> Lin >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Friday, March 1, 2019 12:22 PM >>> To: Yasumasa Suenaga ; ?? >>> Cc: serviceability-dev at openjdk.java.net >>> serviceability-dev at openjdk.java.net >>> >>> Subject: Re: Protocol version of Attach API >>> >>> On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> I agree with David. I think we should backout 8215622. >>> >>> Note that I conceded that if Lin's proposal for changing the 4 back >>> to 3 fixed >>> everything, then I'm okay with making that fix rather than a full >>> backout re- >>> do. >>> >>> I'm not at all convinced we need change the number of args at the >>> protocol >>> level, regardless of the number of apparent "args" the command has. >>> >>> Cheers, >>> David >>> >>>> We should re-do 8215622 completely for all platforms (includes >>>> Windows) and support receiving requests from earlier serviceability >>>> tools. >>>> Problems about arguments of AttachListener should be worked as another >>> issues. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> 2019?3?1?(?) 12:39 ?? : >>>>> >>>>> Hi David, >>>>> ????? My understanding about those "arg" is that they are trying to >>>>> make >>> limitation of the overall message length and make it convince to >>> communicate >>> with sockets. >>>>> ????? I will do more test try to see whether changing back to 3 makes >>> everything fine, and then prepare a webrev. >>>>> Thanks. >>>>> >>>>> Lin >>>>> ________________________________________ >>>>> From: David Holmes >>>>> Sent: Thursday, February 28, 2019 7:55:01 PM >>>>> To: ??; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Hi Lin, >>>>> >>>>> On 28/02/2019 7:30 pm, ?? wrote: >>>>>> Hi David, >>>>>> ??????? I am a little confused, do you think it is proper to made >>>>>> the patch as a >>> fix of https://bugs.openjdk.java.net/browse/JDK-8219721? so that we >>> don't >>> need to backout and REDO? >>>>> >>>>> Generally I'd prefer to do the backout and then apply the revised fix >>>>> as it will make the changes easier to track. >>>>> >>>>> However, if you are saying that everything works fine just by >>>>> changing the 4 back to 3 everywhere, then that does seem a very >>>>> simple fix to apply directly. >>>>> >>>>> I admit that if that does work then I really don't understand what >>>>> these "arg" values actually means. :( Though it would explain why >>>>> windows appears to work fine even though it was left at 3. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> LIn >>>>>> ________________________________________ >>>>>> From: ?? >>>>>> Sent: Thursday, February 28, 2019 4:50:12 PM >>>>>> To: David Holmes; Yasumasa Suenaga >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> Subject: Re: Protocol version of Attach API >>>>>> >>>>>> Dear All, >>>>>> ???????? I have tried simply recover the max argument count makes >>>>>> jmap - >>> histo works and also makes the compatibility works fine. >>>>>> ???????? Following are the changes I made: >>>>>> >>>>>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp >>>>>> --- a/src/hotspot/share/services/attachListener.hpp???? Thu Feb 28 >>> 02:47:39 2019 +0100 >>>>>> +++ b/src/hotspot/share/services/attachListener.hpp???? Thu Feb 28 >>> 16:48:19 2019 +0800 >>>>>> @@ -106,7 +106,7 @@ >>>>>> ????? enum { >>>>>> ??????? name_length_max = 16,?????? // maximum length of? name >>>>>> ??????? arg_length_max = 1024,????? // maximum length of argument >>>>>> -??? arg_count_max = 4?????????? // maximum number of arguments >>>>>> +??? arg_count_max = 3?????????? // maximum number of arguments >>>>>> ????? }; >>>>>> >>>>>> ????? // name of special operation that can be enqueued when all diff >>>>>> -r 07dd34f487d4 >>> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>>>>> a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu >>> Feb 28 16:48:19 2019 +0800 >>>>>> @@ -138,7 +138,7 @@ >>>>>> ???????? * Execute the given command in the target VM. >>>>>> ???????? */ >>>>>> ??????? InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> -??????? assert args.length <= 4;??????????????? // includes null >>>>>> +??????? assert args.length <= 3;??????????????? // includes null >>>>>> >>>>>> ??????????? // did we detach? >>>>>> ??????????? synchronized (this) { >>>>>> @@ -166,7 +166,7 @@ >>>>>> ??????????????? writeString(s, PROTOCOL_VERSION); >>>>>> ??????????????? writeString(s, cmd); >>>>>> >>>>>> -??????????? for (int i = 0; i < 4; i++) { >>>>>> +??????????? for (int i = 0; i < 3; i++) { >>>>>> ??????????????????? if (i < args.length && args[i] != null) { >>>>>> ??????????????????????? writeString(s, (String)args[i]); >>>>>> ??????????????????? } else { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -143,7 +143,7 @@ >>>>>> ???????? * Execute the given command in the target VM. >>>>>> ???????? */ >>>>>> ??????? InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> -??????? assert args.length <= 4;??????????????? // includes null >>>>>> +??????? assert args.length <= 3;??????????????? // includes null >>>>>> >>>>>> ??????????? // did we detach? >>>>>> ??????????? synchronized (this) { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -139,7 +139,7 @@ >>>>>> ???????? * Execute the given command in the target VM. >>>>>> ???????? */ >>>>>> ??????? InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> -??????? assert args.length <= 4;??????????????? // includes null >>>>>> +??????? assert args.length <= 3;??????????????? // includes null >>>>>> >>>>>> ??????????? // did we detach? >>>>>> ??????????? synchronized (this) { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -126,7 +126,7 @@ >>>>>> ???????? * Execute the given command in the target VM. >>>>>> ???????? */ >>>>>> ??????? InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> -??????? assert args.length <= 4;??????????????? // includes null >>>>>> +??????? assert args.length <= 3;??????????????? // includes null >>>>>> >>>>>> ??????????? // first check that we are still attached >>>>>> ??????????? int door; >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -77,7 +77,7 @@ >>>>>> ??????? InputStream execute(String cmd, Object ... args) >>>>>> ??????????? throws AgentLoadException, IOException >>>>>> ??????? { >>>>>> -??????? assert args.length <= 4;??????? // includes null >>>>>> +??????? assert args.length <= 3;??????? // includes null >>>>>> >>>>>> ??????????? // create a pipe using a random name >>>>>> ??????????? Random rnd = new Random(); >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Lin >>>>>> ________________________________________ >>>>>> From: ?? >>>>>> Sent: Thursday, February 28, 2019 3:24:52 PM >>>>>> To: David Holmes; Yasumasa Suenaga >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> Subject: RE: Protocol version of Attach API >>>>>> >>>>>> Hi David, >>>>>> ??????? Since I don't have the access to JBS, may I ask your help >>>>>> to ceate sub- >>> task?? Thanks. >>>>>> >>>>>> BRs, >>>>>> Lin >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Thursday, February 28, 2019 3:16 PM >>>>>>> To: ?? ; Yasumasa Suenaga >>> >>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>>> Hi Lin, >>>>>>> >>>>>>> On 28/02/2019 4:49 pm, ?? wrote: >>>>>>>> Hi David, >>>>>>>> ??????? Your are right and thanks for pointing it out. when I worte >>>>>>>> that patch, I >>>>>>> was considering implement -filename and -incremental together. and >>>>>>> I must be too stupid to forget recover it when I divided the >>>>>>> patch into >>> two. >>>>>>>> ??????? And it seems a good solution is to refine the original >>>>>>>> patch of jmap histo, >>>>>>> and try to composite all args as one when passing it to socket and >>>>>>> let attachlistener to handle the analyze. >>>>>>>> ?????? I will try that. >>>>>>>> ?????? One more, do I need to consider changing the jmap -dump >>>>>>>> also? >>>>>>> >>>>>>> I'm assuming -dump already works fine, so I'm just expecting to see >>>>>>> -histo handle the file in a similar manner. >>>>>>> >>>>>>> If you find this works I suggest creating a sub-task of 8215622 to >>>>>>> first backout the original changes (hg backout), and a second >>>>>>> sub-task to REDO with the new implementation. Each will need >>>>>>> reviewing separately in their own RFR thread. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> BRs, >>>>>>>> Lin >>>>>>>> ________________________________________ >>>>>>>> From: David Holmes >>>>>>>> Sent: Thursday, February 28, 2019 12:59:28 PM >>>>>>>> To: ??; Yasumasa Suenaga >>>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> Subject: Re: Protocol version of Attach API >>>>>>>> >>>>>>>> Sorry I'm going to pick up on the rollback and re-do option here >>>>>>>> as I just had a closer look at jmap. Given jmap -dump already has >>>>>>>> more options than -histo does, why was any change to the "maximum >>>>>>>> number of args" needed in the first place ??? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I'm not sure we're converging on a suitable solution here, but to >>>>>>>>> address the issues flagged by Lin below ... >>>>>>>>> >>>>>>>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>>>>>>> Hi Suenaga, >>>>>>>>>> >>>>>>>>>> ????????? Thanks for your expaination about? the arg_length_max, >>>>>>>>>> I generally agree with you that it is better to consider using >>>>>>>>>> dynamic memory, and that would be handled carefully to aviod >>>>>>>>>> introduce compatibility issue, plus it would be a big change. So >>>>>>>>>> let?s see what others suggest. >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> It seems for me that there are basically three problems forked >>>>>>>>>> by this >>>>>>>>>> thread? >>>>>>>>>> >>>>>>>>>> ?Compatibility issue with old jcmd alike tools with >>>>>>>>>> attachListener?s change. >>>>>>>>> >>>>>>>>> This is issue: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>>>>>>> >>>>>>>>>> ?Only 3 arguments limited to passed by socket to attachListener >>>>>>>>>> for Windows, which cause 8215622 work abnormally on Windows. >>>>>>>>> >>>>>>>>> I have filed a new bug for this: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>>>>>>> >>>>>>>>>> ?The arg_length_max may not be enough for handling filename. >>>>>>>>> >>>>>>>>> I have filed a new bug for this: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>>>>>>> >>>>>>>>> though it seems very related to this issue. >>>>>>>>> >>>>>>>>>> So I suggest we keep the first problem discussed in this thread, >>>>>>>>>> and create separate thread for the others. Do you agree? >>>>>>>>> >>>>>>>>> There is some overlap but yes this can be broken down somewhat - >>>>>>>>> though dealing with the variable length "packet" is going to have >>>>>>>>> to consider that what is received is in fact much larger than the >>>>>>>>> purported maximum packet size if these long paths are expected >>>>>>>>> and >>>>>>> accepted. >>>>>>>>> >>>>>>>>> FWIW I don't see crashes or anything drastic if the arguments are >>>>>>>>> too long - the operations just fail (in somewhat obscure ways >>> sometimes). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For me, I will refine my patch to use timeout as a fix for the >>>>>>>>>> first one, and update it in this thread. And I will try to fix >>>>>>>>>> the second one for Windows, and create a separate thread for >>>>>>>>>> discussing. And if possible, I can help to fix the third one. >>>>>>>>>> >>>>>>>>>> What?s your opinion? >>>>>>>>> >>>>>>>>> That sounds fine ... >>>>>>>>> >>>>>>>>> Or you could choose to rollback JDK-8215622 and see how to solve >>>>>>>>> that without increasing the arg count. Given this usage: >>>>>>>>> >>>>>>>>> jmap -histo:live,file=foo.txt >>>>>>>>> >>>>>>>>> I'm not sure why this is sent to the VM as multiple args rather >>>>>>>>> than as a single composite arg that can then be parsed again by >>>>>>>>> the actual "jmap" logic. There would be some double-up perhaps if >>>>>>>>> the front-end tool wants to perform the command-line validation, >>>>>>>>> but it would be easy enough I think to do that checking then send >>>>>>>>> the original composite >>>>>>> arg. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> BRs, >>>>>>>>>> >>>>>>>>>> Lin >>>>>>>>>> >>>>>>>>>> *From:*Yasumasa Suenaga >>>>>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>>>>>>> *To:* ?? >>>>>>>>>> *Cc:* David Holmes ; >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> *Subject:* Re: Protocol version of Attach API >>>>>>>>>> >>>>>>>>>> 2019?2?28?(?) 0:04 ?? >>>>>> >: >>>>>>>>>> >>>>>>>>>> ??????? Dear Suenaga, >>>>>>>>>> ?????????????? Thanks for your reviewing. I will try to refine >>>>>>>>>> the patch. >>>>>>>>>> ?????????????? For the argument length you mentioned, do you >>>>>>>>>> mean the >>>>>>>>>> ??????? "arg_length_max" should be large enough to accept the max >>> filename >>>>>>>>>> ??????? length? >>>>>>>>>> >>>>>>>>>> Yes, but it is not enough. >>>>>>>>>> >>>>>>>>>> For example, jcmd VM.log might pass 2 or more paths to define >>>>>>>>>> logs. >>>>>>>>>> >>>>>>>>>> ?????????????? IMHO, all the handling of the argument length >>>>>>>>>> is at receiver >>>>>>>>>> ??????? side in the attachListener, such as >>>>>>>>>> >>>>>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os >>>>>>> /linux/att >>>>>>> achListener_linux.cpp#l322, >>>>>>>>>> ??????? for me it means that the VM side limits the argments >>>>>>>>>> length less >>>>>>>>>> ??????? than arg_length_max, otherwise it will return NULL, >>>>>>>>>> which cause >>> the >>>>>>>>>> ??????? sender side (tools like jcmd and jmap) exits with >>>>>>>>>> error message. >>> so >>>>>>>>>> ??????? I think there may be no need to limit the argument >>>>>>>>>> size in tool >>> side. >>>>>>>>>> >>>>>>>>>> IMHO all programs which use filesystem should support any >>>>>>>>>> locations on it. >>>>>>>>>> >>>>>>>>>> So I think we should use dynamic memory (or GrowableArray) for >>>>>>>>>> it if we do not change client side for compatibility. >>>>>>>>>> >>>>>>>>>> ?????????????? And from my experiment with jmap, the arguments >>>>>>>>>> send to >>>>>>>>>> ??????? sockets are not arg0 only.? as you can see in >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh >>>>>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>>>>>>> >>>>>>>>>> ??????? and >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh are/classes/sun/tools/jmap/JMap.java#l133, >>>>>>>>>> >>>>>>>>>> ??????? jmap can pass arg0 as "filename", and arg1 as "-live", >>>>>>>>>> and both >>> of >>>>>>>>>> ??????? them can be NULL. so 00000 >>>>>>>>>> can be >>>>>>>>>> ??????? 0000, and file can be null. >>>>>>>>>> so 00 >>> may not >>>>>>>>>> ??????? indicate it reach the end. >>>>>>>>>> >>>>>>>>>> We should consider for other tools - jstack and jinfo. >>>>>>>>>> >>>>>>>>>> (jstack is ok because it will not have long arguments) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??????? BRs, >>>>>>>>>> ??????? Lin >>>>>>>>>> ??????? ________________________________________ >>>>>>>>>> ??????? From: Yasumasa Suenaga >>>>>>>>> > >>>>>>>>>> ??????? Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>>>>>>> ??????? To: ?? >>>>>>>>>> ??????? Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>>>>>>> ??????? >>>>>>>>>> ??????? Subject: Re: Protocol version of Attach API >>>>>>>>>> >>>>>>>>>> ??????? Hi Lin, >>>>>>>>>> >>>>>>>>>> ??????? I think we need to research more about this. >>>>>>>>>> ??????? IMHO we need to match length of arguments between >>>>>>>>>> ??????? server (AttachListener) and client (serviceability >>>>>>>>>> tools) at least. >>>>>>>>>> ??????? (please see previous email from me). >>>>>>>>>> >>>>>>>>>> ??????? I have some comments for your change: >>>>>>>>>> >>>>>>>>>> ??????? On 2019/02/27 18:22, ?? wrote: >>>>>>>>>> ???????? > Dear All, >>>>>>>>>> ???????? >????? Here I have figured out one solution based on >>>>>>>>>> timeout. >>> would >>>>>>>>>> ??????? you like help to see whether this is OK? >>>>>>>>>> ???????? > --- >>>>>>>>>> a/src/hotspot/os/linux/attachListener_linux.cpp???? Tue Feb >>>>>>>>>> ??????? 26 14:57:23 2019 +0530 >>>>>>>>>> ???????? > +++ >>>>>>>>>> b/src/hotspot/os/linux/attachListener_linux.cpp???? Wed >>> Feb >>>>>>>>>> ??????? 27 17:21:48 2019 +0800 >>>>>>>>>> ???????? > @@ -263,9 +263,29 @@ >>>>>>>>>> ???????? >???? int off = 0; >>>>>>>>>> ???????? >???? int left = max_len; >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > +? memset(buf, 0, max_len); >>>>>>>>>> ???????? > +? // set timeout for read >>>>>>>>>> ???????? > +? struct timeval timeout; >>>>>>>>>> ???????? > +? timeout.tv_sec = 3; >>>>>>>>>> ???????? > +? timeout.tv_usec = 0; >>>>>>>>>> >>>>>>>>>> ??????? I think timeout value should be configurable. >>>>>>>>>> ??????? For example, we can introduce new flag in globals.hpp . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > +? if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>>>>>>> ??????? timeval*)&timeout, sizeof(timeout))) { >>>>>>>>>> ???????? > +??? log_debug(attach)("Failed to set socket option >>> SO_RCVTIMEO: >>>>>>>>>> ??????? %s\n", strerror(errorno)); >>>>>>>>>> ???????? > +??? printf("Warning: Failed to set socket option >>>>>>>>>> SO_RCVTIMEO: >>>>>>>>>> ??????? %s!!!\n", strerror(errno)); >>>>>>>>>> >>>>>>>>>> ??????? You should not use printf(), and do you need to pass >>>>>>>>>> '\n' to >>>>>>>>>> ??????? log_debug()? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > +? } >>>>>>>>>> ???????? >???? do { >>>>>>>>>> ???????? >?????? int n; >>>>>>>>>> ???????? > -??? RESTARTABLE(read(s, buf+off, left), n); >>>>>>>>>> ???????? > +??? log_debug(attach)("start reading data from >>>>>>>>>> socket....\n"); >>>>>>>>>> ???????? > +??? n = read(s, buf+off, left); >>>>>>>>>> >>>>>>>>>> ??????? You should use RESTARTABLE macro. >>>>>>>>>> ??????? read(2) might be interrupted by signal. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > +??? if (n < 0) { >>>>>>>>>> ???????? > +?????? if (errno == EWOULDBLOCK) { >>>>>>>>>> >>>>>>>>>> ??????? According to man page, read(2) sets EWOULDBLOCK or >>>>>>>>>> EAGAIN. >>>>>>>>>> ??????? So you should check both errno. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > +???????? for (int i = str_count; i < >>>>>>>>>> expected_str_count; i++) { >>>>>>>>>> ???????? > +?????????? //timeout, fill reminded arguments with >>>>>>>>>> \0; >>>>>>>>>> ???????? > +?????????? buf[off+i] = '\0'; >>>>>>>>>> ???????? > +?????????? str_count++; >>>>>>>>>> ???????? > +???????? } >>>>>>>>>> >>>>>>>>>> ??????? You set zero to buf[] in above. >>>>>>>>>> ??????? So you can remove this loop, and set str_count to >>> expected_str_count >>>>>>>>>> ??????? without manipulating buf[]. >>>>>>>>>> >>>>>>>>>> ??????? In addition, I prefer to add log_debug() at this >>>>>>>>>> ??????? to record NULL arguments are added. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > +???????? break;; >>>>>>>>>> ???????? > +?????? } >>>>>>>>>> ???????? > +??? } >>>>>>>>>> ???????? >?????? assert(n <= left, "buffer was too small, >>>>>>>>>> impossible!"); >>>>>>>>>> ???????? >?????? buf[max_len - 1] = '\0'; >>>>>>>>>> ???????? >?????? if (n == -1) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??????? Thanks, >>>>>>>>>> >>>>>>>>>> ??????? Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ???????? > Thanks. >>>>>>>>>> ???????? > Lin >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > ________________________________________ >>>>>>>>>> ???????? > From: Yasumasa Suenaga >>>>>>>>> ??????? > >>>>>>>>>> ???????? > Sent: Wednesday, February 27, 2019 15:15 >>>>>>>>>> ???????? > To: David Holmes; ?? >>>>>>>>>> ???????? > Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> ??????? >>>>>>>>>> ???????? > Subject: Re: Protocol version of Attach API >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > On 2019/02/27 15:59, David Holmes wrote: >>>>>>>>>> ???????? >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>>>>>>> ???????? >>> Hi, >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> Buffer size for receiving packets from client is >>>>>>>>>> determined at [1]. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >> Maximum buffer size, yes. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >>> It defines length of command name and of argument. >>>>>>>>>> ???????? >>> It is passed via Unix domain, so we fill '\0' to >>>>>>>>>> remaining >>>>>>>>>> ??????? bytes and >>>>>>>>>> ???????? >>> might be able to assume all arguments are passed >>>>>>>>>> with empty string. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >> Not sure what you mean. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >> // The buffer is expected to be formatted as follows: >>>>>>>>>> ???????? >> // 00000 >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >> so we can expect to read at least two things - the >>>>>>>>>> ver and >>> cmd. >>>>>>>>>> ??????? If we encounter 00 we can infer we reached the end. >>>>>>>>>> But we may >>> not >>>>>>>>>> ??????? have read the full data into the buffer, so can't tell >>>>>>>>>> if another >>>>>>>>>> ??????? call to read() is needed yet - you only know after you've >>>>>>>>>> read the 00. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >>> BTW length of arguments is defined to 1024 in [2]. >>>>>>>>>> ???????? >>> jcmd and jmap might pas file path - it might be >>> JVM_MAXPATHLEN >>>>>>>>>> ??????? (4097 bytes). >>>>>>>>>> ???????? >>> Buffer size which is used in AttachListener seems >>>>>>>>>> not to be enough. >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >> One has to assume/hope that the code sending the >>>>>>>>>> data is >>> working >>>>>>>>>> ??????? to the same protocol rules as the receiver! Otherwise >>>>>>>>>> this is just >>>>>>>>>> ??????? completely broken. >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > On Linux, client (VirtualMachineImpl) seems not to >>>>>>>>>> check >>> length >>>>>>>>>> ??????? of arguments: >>>>>>>>>> ???????? > >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.att >>>>>>>>>> ach/ >>>>>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>>>>>>> >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > In case of jcmd, all options are passed to arg #1. >>>>>>>>>> It seems not >>>>>>>>>> ??????? to check the length: >>>>>>>>>> ???????? > >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh >>>>>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>>>>>>> >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > I guess other tools (jstack, jmap, etc) which >>>>>>>>>> connect to >>>>>>>>>> ??????? AttachListener are same. >>>>>>>>>> ???????? > So we can fix both Attach API and AttachListener >>>>>>>>>> (it will be big >>>>>>>>>> ??????? change!), >>>>>>>>>> ???????? > but I concern we can keep protocol version... >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > Thanks, >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > Yasumasa >>>>>>>>>> ???????? > >>>>>>>>>> ???????? > >>>>>>>>>> ???????? >> David >>>>>>>>>> ???????? >> ----- >>>>>>>>>> ???????? >> >>>>>>>>>> ???????? >>> We might have to change more. >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> Thanks, >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> Yasumasa >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> [1] >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>>> /os/ >>>>>>>>>> linux/attachListener_linux.cpp#l254 >>>>>>>>>> >>>>>>>>>> ???????? >>> [2] >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>>> /sha >>>>>>>>>> re/services/attachListener.hpp#l106 >>>>>>>>>> >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> >>>>>>>>>> ???????? >>> On 2019/02/27 15:00, ?? wrote: >>>>>>>>>> ???????? >>>> Another solution I can figure out is try to add >>>>>>>>>> timeout for >>>>>>>>>> ??????? socket read. I will also investigate whether is works. >>>>>>>>>> ???????? >>>> >>>>>>>>>> ???????? >>>> Cheers, >>>>>>>>>> ???????? >>>> Lin >>>>>>>>>> ???????? >>>> >>>>>>>>>> ???????? >>>> >>>>>>>>>> ???????? >>>>> -----Original Message----- >>>>>>>>>> ???????? >>>>> From: ?? >>>>>>>>>> ???????? >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>>>>>>> ???????? >>>>> To: 'David Holmes' >>>>>>>>> ??????? >; Yasumasa Suenaga >>>>>>>>>> ???????? >>>>> > >>>>>>>>>> ???????? >>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> ??????? >>>>>>>>>> ???????? >>>>> Subject: RE: Protocol version of Attach API >>>>>>>>>> ???????? >>>>> >>>>>>>>>> ???????? >>>>> Dear David, Yasumasa, >>>>>>>>>> ???????? >>>>>???????? I think it is hard to know how long the >>>>>>>>>> buffer is >>>>>>>>>> ??????? passed from socket >>>>>>>>>> ???????? >>>>> without changing the info of the message from the >>>>>>>>>> receiver side. >>>>>>>>>> ???????? >>>>>???????? So how about when str_count reach to 3, >>>>>>>>>> we test it >>>>>>>>>> ??????? with non_blocking >>>>>>>>>> ???????? >>>>> read? >>>>>>>>>> ???????? >>>>> >>>>>>>>>> ???????? >>>>> >>>>>>>>>> ???????? >>>>> Cheers, >>>>>>>>>> ???????? >>>>> Lin >>>>>>>>>> ???????? >>>>>> -----Original Message----- >>>>>>>>>> ???????? >>>>>> From: David Holmes >>>>>>>>> ??????? > >>>>>>>>>> ???????? >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>>>>>>> ???????? >>>>>> To: Yasumasa Suenaga >>>>>>>>> ??????? >; ?? >>>>>>>>> ??????? > >>>>>>>>>> ???????? >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> ??????? >>>>>>>>>> ???????? >>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> Hi Yasumasa, >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>>>>>>> ???????? >>>>>>> Hi Lin, >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> My proposal is a just idea, so you need to >>>>>>>>>> tweak it. >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> AttachListener receives raw command. >>>>>>>>>> ???????? >>>>>>> For example, jcmd is `jcmd\0`. >>>>>>>>>> Please see >>>>>>>>>> ???????? >>>>>>> HotSpotVirtualMachine and extended classes. >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> In case of jcmd, I guess AttachListener will >>>>>>>>>> receive >>> message >>>>>>>>>> ???????? >>>>>>> `\0jcmd\0\0\0\0` (I did not >>>>>>>>>> check it >>> well). >>>>>>>>>> ???????? >>>>>>> So I guess we can add '\0' when `str_count` >>>>>>>>>> does not >>> reach >>>>>>>>>> ??????? to maximum. >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> I don't see how this approach can work. You have >>>>>>>>>> to know >>>>>>> how >>>>>>>>>> ??????? many >>>>>>>>>> ???????? >>>>>> arguments are coming in the "packet", but that >>> information >>>>>>>>>> ??????? is not >>>>>>>>>> ???????? >>>>>> available in the current Linux >>>>>>>>>> implementation.Without it >>> you >>>>>>>>>> ??????? can't >>>>>>>>>> ???????? >>>>>> know when to stop calling read(). >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> The protocol would need to be changed to send the >>> "packet" >>>>>>>>>> ??????? size, but >>>>>>>>>> ???????? >>>>>> that's not compatible with older JDKs. >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> Otherwise I think we have no choice but to use a >>>>>>>>>> ??????? non-blocking read ... >>>>>>>>>> ???????? >>>>>> though I'm still unsure if you can know for >>>>>>>>>> certain that you've >>>>>>>>>> ???????? >>>>>> reached the end of the "packet" ... >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>> Thanks, >>>>>>>>>> ???????? >>>>>> David >>>>>>>>>> ???????? >>>>>> >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> Thanks, >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> Yasumasa >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> >>>>>>>>>> ???????? >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>>>>>>> ??????? wrote: >>>>>>>>>> ???????? >>>>>>>> Dear? Yasumasa, >>>>>>>>>> ???????? >>>>>>>>???? The fix you mentioned seems not work as >>> expected. >>>>>>>>>> ???????? >>>>>>>>???? I have done an experiment that use >>>>>>>>>> jdk1.8's "jcmd >>>>>>>>>> ??????? help" to >>>>>>>>>> ???????? >>>>>>>> attach to latest jdk. >>>>>>>>>> ???????? >>>>>>>>???? it seem the whole "jcmd help" >>>>>>>>>> buffer is not >>>>>>>>>> ???????? >>>>>>>>???? read completely at one time. in my case >>>>>>>>>> it is "jcmd", >>>>>>>>>> ??????? "", >>>>>>>>>> ???????? >>>>>>>> "help", and then block at while(). >>>>>>>>>> ???????? >>>>>>>>???? After applied your change, it seems only >>>>>>>>>> the "jcmd" >>> is >>>>>>>>>> ???????? >>>>>>>> processed, the "", "help" is replaced >>>>>>>>>> by '\0'. >>>>>>>>>> ???????? >>>>>>>> >>>>>>>>>> ???????? >>>>>>>> BRs, >>>>>>>>>> ???????? >>>>>>>> Lin >>>>>>>>>> ???????? >>>>>>>> >>>>>>>>>> From zanglin5 at jd.com Mon Mar 4 09:13:27 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Mon, 4 Mar 2019 09:13:27 +0000 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied Message-ID: Dear All, May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. Thanks, Lin From zanglin5 at jd.com Mon Mar 4 09:14:23 2019 From: zanglin5 at jd.com (=?ks_c_5601-1987?B?7fXX+w==?=) Date: Mon, 4 Mar 2019 09:14:23 +0000 Subject: Protocol version of Attach API In-Reply-To: <70cd6709-0f75-2a1b-33c6-e482fe2d6bd0@oracle.com> References: <4a5f251d-67ef-a81a-ef73-48f9aa9c853e@gmail.com> <0e7c23fec044419d845c5608b0586fcb@jd.com> <3dab08619bbd4254943361d2cdc1298b@jd.com> <077ca61fe91f46ef93c4472accdf0337@jd.com> <8f6ec4c6-18f1-4f61-7ab0-6e1b40acf544@oracle.com> <22427d1123114a0d869eaade059fcd12@jd.com> <66511977ba394d7084d94a356f68f4b7@jd.com> <33bb67d77da949ab9410ea3cdb5dd1ce@jd.com> <650f2814-9bb6-39c1-87ab-583a206b6486@oracle.com> <5d2d51087deb43988867ae66918482aa@jd.com> , <70cd6709-0f75-2a1b-33c6-e482fe2d6bd0@oracle.com> Message-ID: Thanks David, Here is the RFR thread https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027337.html Cheers, Lin ________________________________________ From: David Holmes Sent: Monday, March 4, 2019 3:34:10 PM To: ??; Yasumasa Suenaga; Hohensee, Paul Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: Protocol version of Attach API PS. This should be sent out in a proper RFR thread for JDK-8219721 Thanks, David On 4/03/2019 5:22 pm, David Holmes wrote: > Hi Lin, > > I think this is fine to address the problem that was introduced. > > There's more to be done in this area as there is obviously a > misunderstanding about the "args" expected in the "packet" versus the > 'args' for any particular command. > > With this change we can close JDK-8219895 as "Not an issue". > > Thanks, > David > > > On 1/03/2019 7:22 pm, ?? wrote: >> Dear All, >> I have upload a webrev at >> http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.00/ (just found >> there is a jank file "abc", I will omit it in next webrev, but let's >> review other changes first for time saving.) >> And here are my comments and questions: >> * With this patch , I have tested with jdk8/jdk11's jcmd/jmap, >> all works as expected >> * And passed tier1 test on my linux box >> * Besides change from 4 to 3 , I also found one compatibility >> issue of using old "jmap" like "jmap -histo:live", caused by the >> sequence of arguments for inspectheap. And I have include the fix in >> the webrev. What I am concerned is that is this trivial enough to >> avoid revert and redo. IMO, if you think it shoud be revert 8215622 >> with this change, please let me know. >> >> Thanks for all of your help and suggestions. >> >> BRs, >> Lin >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Friday, March 1, 2019 12:22 PM >>> To: Yasumasa Suenaga ; ?? >>> Cc: serviceability-dev at openjdk.java.net >>> serviceability-dev at openjdk.java.net >>> >>> Subject: Re: Protocol version of Attach API >>> >>> On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> I agree with David. I think we should backout 8215622. >>> >>> Note that I conceded that if Lin's proposal for changing the 4 back >>> to 3 fixed >>> everything, then I'm okay with making that fix rather than a full >>> backout re- >>> do. >>> >>> I'm not at all convinced we need change the number of args at the >>> protocol >>> level, regardless of the number of apparent "args" the command has. >>> >>> Cheers, >>> David >>> >>>> We should re-do 8215622 completely for all platforms (includes >>>> Windows) and support receiving requests from earlier serviceability >>>> tools. >>>> Problems about arguments of AttachListener should be worked as another >>> issues. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> 2019?3?1?(?) 12:39 ?? : >>>>> >>>>> Hi David, >>>>> My understanding about those "arg" is that they are trying to >>>>> make >>> limitation of the overall message length and make it convince to >>> communicate >>> with sockets. >>>>> I will do more test try to see whether changing back to 3 makes >>> everything fine, and then prepare a webrev. >>>>> Thanks. >>>>> >>>>> Lin >>>>> ________________________________________ >>>>> From: David Holmes >>>>> Sent: Thursday, February 28, 2019 7:55:01 PM >>>>> To: ??; Yasumasa Suenaga >>>>> Cc: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> Subject: Re: Protocol version of Attach API >>>>> >>>>> Hi Lin, >>>>> >>>>> On 28/02/2019 7:30 pm, ?? wrote: >>>>>> Hi David, >>>>>> I am a little confused, do you think it is proper to made >>>>>> the patch as a >>> fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that we >>> don't >>> need to backout and REDO? >>>>> >>>>> Generally I'd prefer to do the backout and then apply the revised fix >>>>> as it will make the changes easier to track. >>>>> >>>>> However, if you are saying that everything works fine just by >>>>> changing the 4 back to 3 everywhere, then that does seem a very >>>>> simple fix to apply directly. >>>>> >>>>> I admit that if that does work then I really don't understand what >>>>> these "arg" values actually means. :( Though it would explain why >>>>> windows appears to work fine even though it was left at 3. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> LIn >>>>>> ________________________________________ >>>>>> From: ?? >>>>>> Sent: Thursday, February 28, 2019 4:50:12 PM >>>>>> To: David Holmes; Yasumasa Suenaga >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> Subject: Re: Protocol version of Attach API >>>>>> >>>>>> Dear All, >>>>>> I have tried simply recover the max argument count makes >>>>>> jmap - >>> histo works and also makes the compatibility works fine. >>>>>> Following are the changes I made: >>>>>> >>>>>> diff -r 07dd34f487d4 src/hotspot/share/services/attachListener.hpp >>>>>> --- a/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >>> 02:47:39 2019 +0100 >>>>>> +++ b/src/hotspot/share/services/attachListener.hpp Thu Feb 28 >>> 16:48:19 2019 +0800 >>>>>> @@ -106,7 +106,7 @@ >>>>>> enum { >>>>>> name_length_max = 16, // maximum length of name >>>>>> arg_length_max = 1024, // maximum length of argument >>>>>> - arg_count_max = 4 // maximum number of arguments >>>>>> + arg_count_max = 3 // maximum number of arguments >>>>>> }; >>>>>> >>>>>> // name of special operation that can be enqueued when all diff >>>>>> -r 07dd34f487d4 >>> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>>>>> a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu >>> Feb 28 16:48:19 2019 +0800 >>>>>> @@ -138,7 +138,7 @@ >>>>>> * Execute the given command in the target VM. >>>>>> */ >>>>>> InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> - assert args.length <= 4; // includes null >>>>>> + assert args.length <= 3; // includes null >>>>>> >>>>>> // did we detach? >>>>>> synchronized (this) { >>>>>> @@ -166,7 +166,7 @@ >>>>>> writeString(s, PROTOCOL_VERSION); >>>>>> writeString(s, cmd); >>>>>> >>>>>> - for (int i = 0; i < 4; i++) { >>>>>> + for (int i = 0; i < 3; i++) { >>>>>> if (i < args.length && args[i] != null) { >>>>>> writeString(s, (String)args[i]); >>>>>> } else { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -143,7 +143,7 @@ >>>>>> * Execute the given command in the target VM. >>>>>> */ >>>>>> InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> - assert args.length <= 4; // includes null >>>>>> + assert args.length <= 3; // includes null >>>>>> >>>>>> // did we detach? >>>>>> synchronized (this) { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -139,7 +139,7 @@ >>>>>> * Execute the given command in the target VM. >>>>>> */ >>>>>> InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> - assert args.length <= 4; // includes null >>>>>> + assert args.length <= 3; // includes null >>>>>> >>>>>> // did we detach? >>>>>> synchronized (this) { >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -126,7 +126,7 @@ >>>>>> * Execute the given command in the target VM. >>>>>> */ >>>>>> InputStream execute(String cmd, Object ... args) throws >>> AgentLoadException, IOException { >>>>>> - assert args.length <= 4; // includes null >>>>>> + assert args.length <= 3; // includes null >>>>>> >>>>>> // first check that we are still attached >>>>>> int door; >>>>>> diff -r 07dd34f487d4 >>> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>> --- >>> a/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 02:47:39 2019 +0100 >>>>>> +++ >>> b/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> Thu Feb 28 16:48:19 2019 +0800 >>>>>> @@ -77,7 +77,7 @@ >>>>>> InputStream execute(String cmd, Object ... args) >>>>>> throws AgentLoadException, IOException >>>>>> { >>>>>> - assert args.length <= 4; // includes null >>>>>> + assert args.length <= 3; // includes null >>>>>> >>>>>> // create a pipe using a random name >>>>>> Random rnd = new Random(); >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Lin >>>>>> ________________________________________ >>>>>> From: ?? >>>>>> Sent: Thursday, February 28, 2019 3:24:52 PM >>>>>> To: David Holmes; Yasumasa Suenaga >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> Subject: RE: Protocol version of Attach API >>>>>> >>>>>> Hi David, >>>>>> Since I don't have the access to JBS, may I ask your help >>>>>> to ceate sub- >>> task? Thanks. >>>>>> >>>>>> BRs, >>>>>> Lin >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Thursday, February 28, 2019 3:16 PM >>>>>>> To: ?? ; Yasumasa Suenaga >>> >>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> >>>>>>> Subject: Re: Protocol version of Attach API >>>>>>> >>>>>>> Hi Lin, >>>>>>> >>>>>>> On 28/02/2019 4:49 pm, ?? wrote: >>>>>>>> Hi David, >>>>>>>> Your are right and thanks for pointing it out. when I worte >>>>>>>> that patch, I >>>>>>> was considering implement -filename and -incremental together. and >>>>>>> I must be too stupid to forget recover it when I divided the >>>>>>> patch into >>> two. >>>>>>>> And it seems a good solution is to refine the original >>>>>>>> patch of jmap histo, >>>>>>> and try to composite all args as one when passing it to socket and >>>>>>> let attachlistener to handle the analyze. >>>>>>>> I will try that. >>>>>>>> One more, do I need to consider changing the jmap -dump >>>>>>>> also? >>>>>>> >>>>>>> I'm assuming -dump already works fine, so I'm just expecting to see >>>>>>> -histo handle the file in a similar manner. >>>>>>> >>>>>>> If you find this works I suggest creating a sub-task of 8215622 to >>>>>>> first backout the original changes (hg backout), and a second >>>>>>> sub-task to REDO with the new implementation. Each will need >>>>>>> reviewing separately in their own RFR thread. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> BRs, >>>>>>>> Lin >>>>>>>> ________________________________________ >>>>>>>> From: David Holmes >>>>>>>> Sent: Thursday, February 28, 2019 12:59:28 PM >>>>>>>> To: ??; Yasumasa Suenaga >>>>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> Subject: Re: Protocol version of Attach API >>>>>>>> >>>>>>>> Sorry I'm going to pick up on the rollback and re-do option here >>>>>>>> as I just had a closer look at jmap. Given jmap -dump already has >>>>>>>> more options than -histo does, why was any change to the "maximum >>>>>>>> number of args" needed in the first place ??? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 28/02/2019 2:43 pm, David Holmes wrote: >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I'm not sure we're converging on a suitable solution here, but to >>>>>>>>> address the issues flagged by Lin below ... >>>>>>>>> >>>>>>>>> On 28/02/2019 12:39 pm, ?? wrote: >>>>>>>>>> Hi Suenaga, >>>>>>>>>> >>>>>>>>>> Thanks for your expaination about the arg_length_max, >>>>>>>>>> I generally agree with you that it is better to consider using >>>>>>>>>> dynamic memory, and that would be handled carefully to aviod >>>>>>>>>> introduce compatibility issue, plus it would be a big change. So >>>>>>>>>> let?s see what others suggest. >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> It seems for me that there are basically three problems forked >>>>>>>>>> by this >>>>>>>>>> thread? >>>>>>>>>> >>>>>>>>>> ?Compatibility issue with old jcmd alike tools with >>>>>>>>>> attachListener?s change. >>>>>>>>> >>>>>>>>> This is issue: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219721 >>>>>>>>> >>>>>>>>>> ?Only 3 arguments limited to passed by socket to attachListener >>>>>>>>>> for Windows, which cause 8215622 work abnormally on Windows. >>>>>>>>> >>>>>>>>> I have filed a new bug for this: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219895 >>>>>>>>> >>>>>>>>>> ?The arg_length_max may not be enough for handling filename. >>>>>>>>> >>>>>>>>> I have filed a new bug for this: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219896 >>>>>>>>> >>>>>>>>> though it seems very related to this issue. >>>>>>>>> >>>>>>>>>> So I suggest we keep the first problem discussed in this thread, >>>>>>>>>> and create separate thread for the others. Do you agree? >>>>>>>>> >>>>>>>>> There is some overlap but yes this can be broken down somewhat - >>>>>>>>> though dealing with the variable length "packet" is going to have >>>>>>>>> to consider that what is received is in fact much larger than the >>>>>>>>> purported maximum packet size if these long paths are expected >>>>>>>>> and >>>>>>> accepted. >>>>>>>>> >>>>>>>>> FWIW I don't see crashes or anything drastic if the arguments are >>>>>>>>> too long - the operations just fail (in somewhat obscure ways >>> sometimes). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For me, I will refine my patch to use timeout as a fix for the >>>>>>>>>> first one, and update it in this thread. And I will try to fix >>>>>>>>>> the second one for Windows, and create a separate thread for >>>>>>>>>> discussing. And if possible, I can help to fix the third one. >>>>>>>>>> >>>>>>>>>> What?s your opinion? >>>>>>>>> >>>>>>>>> That sounds fine ... >>>>>>>>> >>>>>>>>> Or you could choose to rollback JDK-8215622 and see how to solve >>>>>>>>> that without increasing the arg count. Given this usage: >>>>>>>>> >>>>>>>>> jmap -histo:live,file=foo.txt >>>>>>>>> >>>>>>>>> I'm not sure why this is sent to the VM as multiple args rather >>>>>>>>> than as a single composite arg that can then be parsed again by >>>>>>>>> the actual "jmap" logic. There would be some double-up perhaps if >>>>>>>>> the front-end tool wants to perform the command-line validation, >>>>>>>>> but it would be easy enough I think to do that checking then send >>>>>>>>> the original composite >>>>>>> arg. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> BRs, >>>>>>>>>> >>>>>>>>>> Lin >>>>>>>>>> >>>>>>>>>> *From:*Yasumasa Suenaga >>>>>>>>>> *Sent:* Thursday, February 28, 2019 8:39 AM >>>>>>>>>> *To:* ?? >>>>>>>>>> *Cc:* David Holmes ; >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> *Subject:* Re: Protocol version of Attach API >>>>>>>>>> >>>>>>>>>> 2019?2?28?(?) 0:04 ?? >>>>>> >: >>>>>>>>>> >>>>>>>>>> Dear Suenaga, >>>>>>>>>> Thanks for your reviewing. I will try to refine >>>>>>>>>> the patch. >>>>>>>>>> For the argument length you mentioned, do you >>>>>>>>>> mean the >>>>>>>>>> "arg_length_max" should be large enough to accept the max >>> filename >>>>>>>>>> length? >>>>>>>>>> >>>>>>>>>> Yes, but it is not enough. >>>>>>>>>> >>>>>>>>>> For example, jcmd VM.log might pass 2 or more paths to define >>>>>>>>>> logs. >>>>>>>>>> >>>>>>>>>> IMHO, all the handling of the argument length >>>>>>>>>> is at receiver >>>>>>>>>> side in the attachListener, such as >>>>>>>>>> >>>>>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot/os >>>>>>> /linux/att >>>>>>> achListener_linux.cpp#l322, >>>>>>>>>> for me it means that the VM side limits the argments >>>>>>>>>> length less >>>>>>>>>> than arg_length_max, otherwise it will return NULL, >>>>>>>>>> which cause >>> the >>>>>>>>>> sender side (tools like jcmd and jmap) exits with >>>>>>>>>> error message. >>> so >>>>>>>>>> I think there may be no need to limit the argument >>>>>>>>>> size in tool >>> side. >>>>>>>>>> >>>>>>>>>> IMHO all programs which use filesystem should support any >>>>>>>>>> locations on it. >>>>>>>>>> >>>>>>>>>> So I think we should use dynamic memory (or GrowableArray) for >>>>>>>>>> it if we do not change client side for compatibility. >>>>>>>>>> >>>>>>>>>> And from my experiment with jmap, the arguments >>>>>>>>>> send to >>>>>>>>>> sockets are not arg0 only. as you can see in >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh >>>>>>>>>> are/classes/sun/tools/jmap/JMap.java#l193 >>>>>>>>>> >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh are/classes/sun/tools/jmap/JMap.java#l133, >>>>>>>>>> >>>>>>>>>> jmap can pass arg0 as "filename", and arg1 as "-live", >>>>>>>>>> and both >>> of >>>>>>>>>> them can be NULL. so 00000 >>>>>>>>>> can be >>>>>>>>>> 0000, and file can be null. >>>>>>>>>> so 00 >>> may not >>>>>>>>>> indicate it reach the end. >>>>>>>>>> >>>>>>>>>> We should consider for other tools - jstack and jinfo. >>>>>>>>>> >>>>>>>>>> (jstack is ok because it will not have long arguments) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> BRs, >>>>>>>>>> Lin >>>>>>>>>> ________________________________________ >>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>> > >>>>>>>>>> Sent: Wednesday, February 27, 2019 8:10:14 PM >>>>>>>>>> To: ?? >>>>>>>>>> Cc: David Holmes; serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>>> >>>>>>>>>> Hi Lin, >>>>>>>>>> >>>>>>>>>> I think we need to research more about this. >>>>>>>>>> IMHO we need to match length of arguments between >>>>>>>>>> server (AttachListener) and client (serviceability >>>>>>>>>> tools) at least. >>>>>>>>>> (please see previous email from me). >>>>>>>>>> >>>>>>>>>> I have some comments for your change: >>>>>>>>>> >>>>>>>>>> On 2019/02/27 18:22, ?? wrote: >>>>>>>>>> > Dear All, >>>>>>>>>> >????? Here I have figured out one solution based on >>>>>>>>>> timeout. >>> would >>>>>>>>>> you like help to see whether this is OK? >>>>>>>>>> > --- >>>>>>>>>> a/src/hotspot/os/linux/attachListener_linux.cpp Tue Feb >>>>>>>>>> 26 14:57:23 2019 +0530 >>>>>>>>>> > +++ >>>>>>>>>> b/src/hotspot/os/linux/attachListener_linux.cpp Wed >>> Feb >>>>>>>>>> 27 17:21:48 2019 +0800 >>>>>>>>>> > @@ -263,9 +263,29 @@ >>>>>>>>>> >???? int off = 0; >>>>>>>>>> >???? int left = max_len; >>>>>>>>>> > >>>>>>>>>> > + memset(buf, 0, max_len); >>>>>>>>>> > + // set timeout for read >>>>>>>>>> > + struct timeval timeout; >>>>>>>>>> > + timeout.tv_sec = 3; >>>>>>>>>> > + timeout.tv_usec = 0; >>>>>>>>>> >>>>>>>>>> I think timeout value should be configurable. >>>>>>>>>> For example, we can introduce new flag in globals.hpp . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > + if(setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, (struct >>>>>>>>>> timeval*)&timeout, sizeof(timeout))) { >>>>>>>>>> > + log_debug(attach)("Failed to set socket option >>> SO_RCVTIMEO: >>>>>>>>>> %s\n", strerror(errorno)); >>>>>>>>>> > + printf("Warning: Failed to set socket option >>>>>>>>>> SO_RCVTIMEO: >>>>>>>>>> %s!!!\n", strerror(errno)); >>>>>>>>>> >>>>>>>>>> You should not use printf(), and do you need to pass >>>>>>>>>> '\n' to >>>>>>>>>> log_debug()? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > + } >>>>>>>>>> >???? do { >>>>>>>>>> >?????? int n; >>>>>>>>>> > - RESTARTABLE(read(s, buf+off, left), n); >>>>>>>>>> > + log_debug(attach)("start reading data from >>>>>>>>>> socket....\n"); >>>>>>>>>> > + n = read(s, buf+off, left); >>>>>>>>>> >>>>>>>>>> You should use RESTARTABLE macro. >>>>>>>>>> read(2) might be interrupted by signal. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > + if (n < 0) { >>>>>>>>>> > + if (errno == EWOULDBLOCK) { >>>>>>>>>> >>>>>>>>>> According to man page, read(2) sets EWOULDBLOCK or >>>>>>>>>> EAGAIN. >>>>>>>>>> So you should check both errno. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > + for (int i = str_count; i < >>>>>>>>>> expected_str_count; i++) { >>>>>>>>>> > + //timeout, fill reminded arguments with >>>>>>>>>> \0; >>>>>>>>>> > + buf[off+i] = '\0'; >>>>>>>>>> > + str_count++; >>>>>>>>>> > + } >>>>>>>>>> >>>>>>>>>> You set zero to buf[] in above. >>>>>>>>>> So you can remove this loop, and set str_count to >>> expected_str_count >>>>>>>>>> without manipulating buf[]. >>>>>>>>>> >>>>>>>>>> In addition, I prefer to add log_debug() at this >>>>>>>>>> to record NULL arguments are added. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > + break;; >>>>>>>>>> > + } >>>>>>>>>> > + } >>>>>>>>>> >?????? assert(n <= left, "buffer was too small, >>>>>>>>>> impossible!"); >>>>>>>>>> >?????? buf[max_len - 1] = '\0'; >>>>>>>>>> >?????? if (n == -1) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > Thanks. >>>>>>>>>> > Lin >>>>>>>>>> > >>>>>>>>>> > ________________________________________ >>>>>>>>>> > From: Yasumasa Suenaga >>>>>>>>> > >>>>>>>>>> > Sent: Wednesday, February 27, 2019 15:15 >>>>>>>>>> > To: David Holmes; ?? >>>>>>>>>> > Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> > Subject: Re: Protocol version of Attach API >>>>>>>>>> > >>>>>>>>>> > On 2019/02/27 15:59, David Holmes wrote: >>>>>>>>>> >> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote: >>>>>>>>>> >>> Hi, >>>>>>>>>> >>> >>>>>>>>>> >>> Buffer size for receiving packets from client is >>>>>>>>>> determined at [1]. >>>>>>>>>> >> >>>>>>>>>> >> Maximum buffer size, yes. >>>>>>>>>> >> >>>>>>>>>> >>> It defines length of command name and of argument. >>>>>>>>>> >>> It is passed via Unix domain, so we fill '\0' to >>>>>>>>>> remaining >>>>>>>>>> bytes and >>>>>>>>>> >>> might be able to assume all arguments are passed >>>>>>>>>> with empty string. >>>>>>>>>> >> >>>>>>>>>> >> Not sure what you mean. >>>>>>>>>> >> >>>>>>>>>> >> // The buffer is expected to be formatted as follows: >>>>>>>>>> >> // 00000 >>>>>>>>>> >> >>>>>>>>>> >> so we can expect to read at least two things - the >>>>>>>>>> ver and >>> cmd. >>>>>>>>>> If we encounter 00 we can infer we reached the end. >>>>>>>>>> But we may >>> not >>>>>>>>>> have read the full data into the buffer, so can't tell >>>>>>>>>> if another >>>>>>>>>> call to read() is needed yet - you only know after you've >>>>>>>>>> read the 00. >>>>>>>>>> >> >>>>>>>>>> >>> BTW length of arguments is defined to 1024 in [2]. >>>>>>>>>> >>> jcmd and jmap might pas file path - it might be >>> JVM_MAXPATHLEN >>>>>>>>>> (4097 bytes). >>>>>>>>>> >>> Buffer size which is used in AttachListener seems >>>>>>>>>> not to be enough. >>>>>>>>>> >> >>>>>>>>>> >> One has to assume/hope that the code sending the >>>>>>>>>> data is >>> working >>>>>>>>>> to the same protocol rules as the receiver! Otherwise >>>>>>>>>> this is just >>>>>>>>>> completely broken. >>>>>>>>>> > >>>>>>>>>> > On Linux, client (VirtualMachineImpl) seems not to >>>>>>>>>> check >>> length >>>>>>>>>> of arguments: >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.att >>>>>>>>>> ach/ >>>>>>>>>> linux/classes/sun/tools/attach/VirtualMachineImpl.java#l168 >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > In case of jcmd, all options are passed to arg #1. >>>>>>>>>> It seems not >>>>>>>>>> to check the length: >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/jdk.jcm >>>>>>>>>> d/sh >>>>>>>>>> are/classes/sun/tools/jcmd/JCmd.java#l111 >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > I guess other tools (jstack, jmap, etc) which >>>>>>>>>> connect to >>>>>>>>>> AttachListener are same. >>>>>>>>>> > So we can fix both Attach API and AttachListener >>>>>>>>>> (it will be big >>>>>>>>>> change!), >>>>>>>>>> > but I concern we can keep protocol version... >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Thanks, >>>>>>>>>> > >>>>>>>>>> > Yasumasa >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >> David >>>>>>>>>> >> ----- >>>>>>>>>> >> >>>>>>>>>> >>> We might have to change more. >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> Thanks, >>>>>>>>>> >>> >>>>>>>>>> >>> Yasumasa >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> [1] >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>>> /os/ >>>>>>>>>> linux/attachListener_linux.cpp#l254 >>>>>>>>>> >>>>>>>>>> >>> [2] >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/df3d253aaf81/src/hotspot >>>>>>>>>> /sha >>>>>>>>>> re/services/attachListener.hpp#l106 >>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> On 2019/02/27 15:00, ?? wrote: >>>>>>>>>> >>>> Another solution I can figure out is try to add >>>>>>>>>> timeout for >>>>>>>>>> socket read. I will also investigate whether is works. >>>>>>>>>> >>>> >>>>>>>>>> >>>> Cheers, >>>>>>>>>> >>>> Lin >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>>> -----Original Message----- >>>>>>>>>> >>>>> From: ?? >>>>>>>>>> >>>>> Sent: Wednesday, February 27, 2019 1:52 PM >>>>>>>>>> >>>>> To: 'David Holmes' >>>>>>>>> >; Yasumasa Suenaga >>>>>>>>>> >>>>> > >>>>>>>>>> >>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> >>>>> Subject: RE: Protocol version of Attach API >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Dear David, Yasumasa, >>>>>>>>>> >>>>>???????? I think it is hard to know how long the >>>>>>>>>> buffer is >>>>>>>>>> passed from socket >>>>>>>>>> >>>>> without changing the info of the message from the >>>>>>>>>> receiver side. >>>>>>>>>> >>>>>???????? So how about when str_count reach to 3, >>>>>>>>>> we test it >>>>>>>>>> with non_blocking >>>>>>>>>> >>>>> read? >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Cheers, >>>>>>>>>> >>>>> Lin >>>>>>>>>> >>>>>> -----Original Message----- >>>>>>>>>> >>>>>> From: David Holmes >>>>>>>>> > >>>>>>>>>> >>>>>> Sent: Wednesday, February 27, 2019 1:44 PM >>>>>>>>>> >>>>>> To: Yasumasa Suenaga >>>>>>>>> >; ?? >>>>>>>>> > >>>>>>>>>> >>>>>> Cc: serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> >>>>>> Subject: Re: Protocol version of Attach API >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>> Hi Lin, >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> My proposal is a just idea, so you need to >>>>>>>>>> tweak it. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> AttachListener receives raw command. >>>>>>>>>> >>>>>>> For example, jcmd is `jcmd\0`. >>>>>>>>>> Please see >>>>>>>>>> >>>>>>> HotSpotVirtualMachine and extended classes. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> In case of jcmd, I guess AttachListener will >>>>>>>>>> receive >>> message >>>>>>>>>> >>>>>>> `\0jcmd\0\0\0\0` (I did not >>>>>>>>>> check it >>> well). >>>>>>>>>> >>>>>>> So I guess we can add '\0' when `str_count` >>>>>>>>>> does not >>> reach >>>>>>>>>> to maximum. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I don't see how this approach can work. You have >>>>>>>>>> to know >>>>>>> how >>>>>>>>>> many >>>>>>>>>> >>>>>> arguments are coming in the "packet", but that >>> information >>>>>>>>>> is not >>>>>>>>>> >>>>>> available in the current Linux >>>>>>>>>> implementation.Without it >>> you >>>>>>>>>> can't >>>>>>>>>> >>>>>> know when to stop calling read(). >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> The protocol would need to be changed to send the >>> "packet" >>>>>>>>>> size, but >>>>>>>>>> >>>>>> that's not compatible with older JDKs. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Otherwise I think we have no choice but to use a >>>>>>>>>> non-blocking read ... >>>>>>>>>> >>>>>> though I'm still unsure if you can know for >>>>>>>>>> certain that you've >>>>>>>>>> >>>>>> reached the end of the "packet" ... >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Thanks, >>>>>>>>>> >>>>>> David >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Yasumasa >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> On 2019/02/27 11:50, zanglin5 at jd.com >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>> Dear Yasumasa, >>>>>>>>>> >>>>>>>>???? The fix you mentioned seems not work as >>> expected. >>>>>>>>>> >>>>>>>>???? I have done an experiment that use >>>>>>>>>> jdk1.8's "jcmd >>>>>>>>>> help" to >>>>>>>>>> >>>>>>>> attach to latest jdk. >>>>>>>>>> >>>>>>>>???? it seem the whole "jcmd help" >>>>>>>>>> buffer is not >>>>>>>>>> >>>>>>>>???? read completely at one time. in my case >>>>>>>>>> it is "jcmd", >>>>>>>>>> "", >>>>>>>>>> >>>>>>>> "help", and then block at while(). >>>>>>>>>> >>>>>>>>???? After applied your change, it seems only >>>>>>>>>> the "jcmd" >>> is >>>>>>>>>> >>>>>>>> processed, the "", "help" is replaced >>>>>>>>>> by '\0'. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> BRs, >>>>>>>>>> >>>>>>>> Lin >>>>>>>>>> >>>>>>>> >>>>>>>>>> From daniil.x.titov at oracle.com Mon Mar 4 23:03:49 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 04 Mar 2019 15:03:49 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: Hi Dean, You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 Thanks! --Daniil ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: Looks good, but what about sp06t003? Doesn't it have the same problem? Are there any other tests using similar logic? dl On 3/1/19 8:33 PM, Daniil Titov wrote: > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > [0] adjustCompilationLevel > [1] adjustCompilationLevel > [2] testedMethod > [3] run > > In this case the test looks for the test method only in 2 top frames and fails. > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > From dean.long at oracle.com Tue Mar 5 00:04:49 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Mar 2019 16:04:49 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: <62eff3ae-18b7-f039-2acf-e9f16f0d39a0@oracle.com> Looks good! dl On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From chris.plummer at oracle.com Tue Mar 5 03:00:14 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 4 Mar 2019 19:00:14 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: Hi Daniil, I think the fix is fine. I was wondering why the test was originally written to use the smaller of the two stack sizes. I noticed that the "suspended == NSK_TRUE" checks seem to defend against test failures that might be introduced with your change (you can only get two different stack sizes when the thread is not suspended). This check was added as part of the fix for JDK-8051349, which was done a few months ago, so if the fix for JDK-8051349 were not in place then your fix would not have worked. thanks, Chris On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From chris.plummer at oracle.com Tue Mar 5 03:41:51 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 4 Mar 2019 19:41:51 -0800 Subject: RFR(XS) 8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream" Message-ID: <87f3e7c2-e133-4355-5a0b-5c437648c12b@oracle.com> Hello, Please review the following. Details are in the bug. In short, the way I was checking for the application exit was a bit non-standard and exposed what is probably a bug in the JdbTest shutdown code. I changed the test to conform to the way other test run to exit: https://bugs.openjdk.java.net/browse/JDK-8220030 diff --git a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java --- a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java +++ b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java @@ -32,6 +32,7 @@ ? * @run main/othervm JdbStopThreadidTest ? */ +import jdk.test.lib.process.OutputAnalyzer; ?import lib.jdb.Jdb; ?import lib.jdb.JdbCommand; ?import lib.jdb.JdbTest; @@ -138,6 +139,7 @@ ???????? jdb.command(JdbCommand.cont().waitForPrompt("Breakpoint hit: \"thread=MYTHREAD-2\", \\S+MyThread.brkMethod", true)); ???????? // Continue until the application exits. Once again, hitting a breakpoint will cause ???????? // a failure because we are not suppose to hit one. - jdb.command(JdbCommand.cont().waitForPrompt(Jdb.APPLICATION_EXIT, true)); +??????? jdb.contToExit(1); +??????? new OutputAnalyzer(getJdbOutput()).shouldContain(Jdb.APPLICATION_EXIT); thanks, Chris From daniil.x.titov at oracle.com Tue Mar 5 03:55:33 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 04 Mar 2019 19:55:33 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: Hi Chris, I also was wondering about what might be behind the decision to use "commonDepth" when the tests were originally written. You are right there were several issues in these tests when running with Graal. The first issue (the different stack sizes returned by jvmti->GetFrameCount and jvmti-> GetStackTrace when Graal is on and the thread is not suspended) was addressed by JDK-8051349 and another issue ( JDK- 8218167, that the test method is not found in the frame stack) is addressed by this change. Best regards, Daniil ?On 3/4/19, 7:00 PM, "Chris Plummer" wrote: Hi Daniil, I think the fix is fine. I was wondering why the test was originally written to use the smaller of the two stack sizes. I noticed that the "suspended == NSK_TRUE" checks seem to defend against test failures that might be introduced with your change (you can only get two different stack sizes when the thread is not suspended). This check was added as part of the fix for JDK-8051349, which was done a few months ago, so if the fix for JDK-8051349 were not in place then your fix would not have worked. thanks, Chris On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From david.holmes at oracle.com Tue Mar 5 06:11:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Mar 2019 16:11:43 +1000 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: References: Message-ID: <1aa8c7d1-79aa-12b1-1a10-9cedffe82aa5@oracle.com> Hi Lin, On 4/03/2019 7:13 pm, ?? wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. This looks good to me. I can confirm that it fixes the problem of tools from earlier releases hanging. Thanks, David > Thanks, > Lin > From zanglin5 at jd.com Tue Mar 5 09:13:45 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Tue, 5 Mar 2019 09:13:45 +0000 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: <1aa8c7d1-79aa-12b1-1a10-9cedffe82aa5@oracle.com> References: <1aa8c7d1-79aa-12b1-1a10-9cedffe82aa5@oracle.com> Message-ID: Hi David, Thanks a lot for your review. Hi All, May I get more review about this patch, it is a trivial patch to fix compatibility issue. Thanks, Lin > -----Original Message----- > From: David Holmes > Sent: Tuesday, March 5, 2019 2:12 PM > To: ?? ; serviceability-dev at openjdk.java.net > serviceability-dev at openjdk.java.net > Subject: Re: RFR:8219721: jcmd from earlier release will hang attaching to VM > with JDK-8215622 applied > > Hi Lin, > > On 4/03/2019 7:13 pm, ?? wrote: > > Dear All, > > May I ask your help to review the fix of compatibility issue introduced by > JDK-8215622 > > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > > > FYI, this webrev is forked from the discussion > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019- > February/027240.html. > > This looks good to me. I can confirm that it fixes the problem of tools from > earlier releases hanging. > > Thanks, > David > > > Thanks, > > Lin > > From gary.adams at oracle.com Tue Mar 5 12:47:23 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 05 Mar 2019 07:47:23 -0500 Subject: RFR(XS) 8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream" In-Reply-To: <87f3e7c2-e133-4355-5a0b-5c437648c12b@oracle.com> References: <87f3e7c2-e133-4355-5a0b-5c437648c12b@oracle.com> Message-ID: <5C7E6FDB.30705@oracle.com> This looks OK to me. If a specific return code is expected, then the test should wait until it gets the response it needs. If a specific return is not required, the test should be lenient about what information is required for the test to complete. On 3/4/19, 10:41 PM, Chris Plummer wrote: > Hello, > > Please review the following. Details are in the bug. In short, the way > I was checking for the application exit was a bit non-standard and > exposed what is probably a bug in the JdbTest shutdown code. I changed > the test to conform to the way other test run to exit: > > https://bugs.openjdk.java.net/browse/JDK-8220030 > > diff --git a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java > b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java > --- a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java > +++ b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java > @@ -32,6 +32,7 @@ > * @run main/othervm JdbStopThreadidTest > */ > > +import jdk.test.lib.process.OutputAnalyzer; > import lib.jdb.Jdb; > import lib.jdb.JdbCommand; > import lib.jdb.JdbTest; > @@ -138,6 +139,7 @@ > jdb.command(JdbCommand.cont().waitForPrompt("Breakpoint hit: > \"thread=MYTHREAD-2\", \\S+MyThread.brkMethod", true)); > // Continue until the application exits. Once again, hitting > a breakpoint will cause > // a failure because we are not suppose to hit one. > - jdb.command(JdbCommand.cont().waitForPrompt(Jdb.APPLICATION_EXIT, > true)); > + jdb.contToExit(1); > + new > OutputAnalyzer(getJdbOutput()).shouldContain(Jdb.APPLICATION_EXIT); > > thanks, > > Chris > > From yasuenag at gmail.com Tue Mar 5 13:22:35 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 5 Mar 2019 22:22:35 +0900 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: References: Message-ID: <68a7575e-9296-83fe-84f3-dfa78861d66f@gmail.com> Looks good. Yasumasa (ysuenaga) On 2019/03/04 18:13, zanglin5 at jd.com wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. > > Thanks, > Lin > From sgehwolf at redhat.com Tue Mar 5 14:33:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 05 Mar 2019 15:33:02 +0100 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> Message-ID: <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> Hi Daniel, Latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/03/webrev/ It's incorporating your changes wrt. to some timeouts and asserting the expected exit code. Instead of the ProcessThread changes, I'm using the sendMessage() approach. That API is already there. Unfortunately when running both SSL and plain sockets tests, it would randomly fail for me. Even if I choose different sets of ports for plain/ssl. So I've taken a different route of randomly selecting SSL or plain. Overall, this should give reasonable coverage for both (plain and SSL). This made test stability improve a lot on my Linux x86_64 machine. Ran for 100 iterations without failure. I'll run this through jdk/submit now. Could you run this through your test system too, please? Would you be OK with getting this patch pushed once we'd have positive results for both? Thanks, Severin On Fri, 2019-03-01 at 15:08 +0000, Daniel Fuchs wrote: > Hi Severin, > > On 28/02/2019 15:47, Severin Gehwolf wrote: > > Yes, thanks for looking at this Daniel. That was my determination as > > well. However, even if we do all of the above, and add a test config > > with /etc/hosts mapping a non-loopback address to "localhost" it would > > break other tests. E.g. this one: > > java/net/InetAddress/GetLocalHostWithSM.java > > > > So I'd have to explore whether your suggestion with > > InetAddress.getLocalHost() is viable. It seems promising. > > > > I'll keep you posted. > > Thanks for keeping the investigation going! > > For what it's worth this is what I have been experimenting with: > http://cr.openjdk.java.net/~dfuchs/experiment-8219585/experiment.00/ > > It's only a POC and obviously need more cleaning. > Maybe some of the arbitrary timeouts in the test could be scaled > in accordance to timeout-factor (I think there's an adjustTimeout(long) > function somewhere in the test libs that does that). > > I ran it 50 times in our test system - and it passed on all platforms, > so there's yet hope :-) > > hope this helps, > > -- daniel > > From alexey.menkov at oracle.com Tue Mar 5 17:48:36 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 5 Mar 2019 09:48:36 -0800 Subject: RFR(XS) 8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream" In-Reply-To: <5C7E6FDB.30705@oracle.com> References: <87f3e7c2-e133-4355-5a0b-5c437648c12b@oracle.com> <5C7E6FDB.30705@oracle.com> Message-ID: <234f0da1-59fd-e735-78ec-66bf96270e1a@oracle.com> LGTM too. --alex On 03/05/2019 04:47, Gary Adams wrote: > This looks OK to me. > > If a specific return code is expected, > then the test should wait until it gets the response it needs. > > If a specific return is not required, the test should be lenient > about what information is required for the test to complete. > > On 3/4/19, 10:41 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following. Details are in the bug. In short, the way >> I was checking for the application exit was a bit non-standard and >> exposed what is probably a bug in the JdbTest shutdown code. I changed >> the test to conform to the way other test run to exit: >> >> https://bugs.openjdk.java.net/browse/JDK-8220030 >> >> diff --git a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java >> b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java >> --- a/test/jdk/com/sun/jdi/JdbStopThreadidTest.java >> +++ b/test/jdk/com/sun/jdi/JdbStopThreadidTest.java >> @@ -32,6 +32,7 @@ >> ? * @run main/othervm JdbStopThreadidTest >> ? */ >> >> +import jdk.test.lib.process.OutputAnalyzer; >> ?import lib.jdb.Jdb; >> ?import lib.jdb.JdbCommand; >> ?import lib.jdb.JdbTest; >> @@ -138,6 +139,7 @@ >> ???????? jdb.command(JdbCommand.cont().waitForPrompt("Breakpoint hit: >> \"thread=MYTHREAD-2\", \\S+MyThread.brkMethod", true)); >> ???????? // Continue until the application exits. Once again, hitting >> a breakpoint will cause >> ???????? // a failure because we are not suppose to hit one. >> - jdb.command(JdbCommand.cont().waitForPrompt(Jdb.APPLICATION_EXIT, >> true)); >> +??????? jdb.contToExit(1); >> +??????? new >> OutputAnalyzer(getJdbOutput()).shouldContain(Jdb.APPLICATION_EXIT); >> >> thanks, >> >> Chris >> >> > From daniil.x.titov at oracle.com Tue Mar 5 18:59:36 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 05 Mar 2019 10:59:36 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: <9F300F0A-62A8-45E2-8D36-7677517FE140@oracle.com> Thank you, Dean and Chris, for reviewing this change! --Daniil ? ?On 3/4/19, 7:00 PM, "Chris Plummer" wrote: Hi Daniil, I think the fix is fine. I was wondering why the test was originally written to use the smaller of the two stack sizes. I noticed that the "suspended == NSK_TRUE" checks seem to defend against test failures that might be introduced with your change (you can only get two different stack sizes when the thread is not suspended). This check was added as part of the fix for JDK-8051349, which was done a few months ago, so if the fix for JDK-8051349 were not in place then your fix would not have worked. thanks, Chris On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From daniil.x.titov at oracle.com Tue Mar 5 21:59:21 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 05 Mar 2019 13:59:21 -0800 Subject: RFR: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed Message-ID: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> Please review a fix for this test that intermittently fails with Graal on. The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 Thanks! --Daniil From serguei.spitsyn at oracle.com Tue Mar 5 22:29:50 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Mar 2019 14:29:50 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: Hi Daniil, It looks okay. How did you test this fix? Did you run these tests in different compiler modes? Thanks, Serguei On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From serguei.spitsyn at oracle.com Tue Mar 5 22:41:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Mar 2019 14:41:05 -0800 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: References: Message-ID: Hi Lin, It looks good to me too. Thanks, Serguei On 3/4/19 1:13 AM, ?? wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. > > Thanks, > Lin From serguei.spitsyn at oracle.com Tue Mar 5 22:47:44 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Mar 2019 14:47:44 -0800 Subject: RFR: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed In-Reply-To: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> References: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> Message-ID: <48810813-6f08-c21d-c2a3-52598b1a1ce4@oracle.com> Hi Daniil, The fix looks good. Thanks, Serguei On 3/5/19 1:59 PM, Daniil Titov wrote: > Please review a fix for this test that intermittently fails with Graal on. > > The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 > > Thanks! > --Daniil > > > From daniil.x.titov at oracle.com Tue Mar 5 22:52:50 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 05 Mar 2019 14:52:50 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> Message-ID: <1D3445ED-587E-4D38-9F75-1C71DB04F73F@oracle.com> Hi Serguei, I tested it with different options: -Xcomp and Graal. I also had tier1, tier2 and tier3 tests passed. Bests regards, Daniil ?On 3/5/19, 2:29 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, It looks okay. How did you test this fix? Did you run these tests in different compiler modes? Thanks, Serguei On 3/4/19 3:03 PM, Daniil Titov wrote: > Hi Dean, > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > Thanks! > --Daniil > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > Looks good, but what about sp06t003? Doesn't it have the same problem? > Are there any other tests using similar logic? > > dl > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > [0] adjustCompilationLevel > > [1] adjustCompilationLevel > > [2] testedMethod > > [3] run > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > > > > > > From serguei.spitsyn at oracle.com Wed Mar 6 00:20:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Mar 2019 16:20:52 -0800 Subject: RFR 8218167: nsk/jvmti/scenarios/sampling/SP02/sp02t003 fails In-Reply-To: <1D3445ED-587E-4D38-9F75-1C71DB04F73F@oracle.com> References: <3312FD66-27D9-416C-B3D9-14B0A7B78461@oracle.com> <27F20AC1-8967-4016-B8A3-17FD3D401815@oracle.com> <1D3445ED-587E-4D38-9F75-1C71DB04F73F@oracle.com> Message-ID: Okay, thanks! Serguei On 3/5/19 2:52 PM, Daniil Titov wrote: > Hi Serguei, > > I tested it with different options: -Xcomp and Graal. I also had tier1, tier2 and tier3 tests passed. > > Bests regards, > Daniil > > > > ?On 3/5/19, 2:29 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > It looks okay. > How did you test this fix? > Did you run these tests in different compiler modes? > > Thanks, > Serguei > > > On 3/4/19 3:03 PM, Daniil Titov wrote: > > Hi Dean, > > > > You are right, test sp06t003 has the same problem. Please, review a new version of the change that fixes both tests. I checked other tests and no more tests use the this approach with "commonDepth". > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.02 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > Thanks! > > --Daniil > > > > ?On 3/1/19, 9:14 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: > > > > Looks good, but what about sp06t003? Doesn't it have the same problem? > > Are there any other tests using similar logic? > > > > dl > > > > On 3/1/19 8:33 PM, Daniil Titov wrote: > > > Please review the change that fix intermittent failure for test nsk/jvmti/scenarios/sampling/SP02/sp02t003 when running with Graal. > > > > > > The problem with the test here is that method checkThread() looks for the test method in the top "commonDepth" frames where "commonDepth" is a minimum of "frameCount" (returned by jvmti->GetFrameCount) and "frameStackSize"( returned by jvmti->GetStackTrace). > > > > > > If a compilation is triggered between these 2 calls then there are cases when "frameCount" is 2, "frameStackSize" is 4, and the frame stack is as the following: > > > > > > [0] adjustCompilationLevel > > > [1] adjustCompilationLevel > > > [2] testedMethod > > > [3] run > > > > > > In this case the test looks for the test method only in 2 top frames and fails. > > > > > > The fix ensures that the test iterates over all frames in the frame stack when looking for the test method. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218167/webrev.01 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218167 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > From gary.adams at oracle.com Wed Mar 6 15:33:54 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Mar 2019 10:33:54 -0500 Subject: RFR: JDK-8201252: unquarantine nsk/jdi/ThreadReference/resume/resume001 Message-ID: <5C7FE862.9070505@oracle.com> After 1000's of test runs with the resume001 test off the ProblemList, no new sightings have been observed. I intend to use the JDK-8201252 issue to restore the test. JDK-8072701 will be updated and left for sustaining, if the fix needs to be applied to older releases. diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -157,7 +157,6 @@ vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded005/TestDescription.java 8153598 generic-all vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java 8060733 generic-all -vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java 8072701 generic-all vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 7034630 generic-all vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java 8013728 generic-all vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all From gary.adams at oracle.com Wed Mar 6 16:59:26 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Mar 2019 11:59:26 -0500 Subject: RFR: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed In-Reply-To: <48810813-6f08-c21d-c2a3-52598b1a1ce4@oracle.com> References: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> <48810813-6f08-c21d-c2a3-52598b1a1ce4@oracle.com> Message-ID: <5C7FFC6E.3030601@oracle.com> Looks OK to me. On 3/5/19, 5:47 PM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > The fix looks good. > > Thanks, > Serguei > > > On 3/5/19 1:59 PM, Daniil Titov wrote: >> Please review a fix for this test that intermittently fails with >> Graal on. >> >> The problem here is that the test does two consequent calls to >> VirtualMachine.allThreads() and checks that the number of threads >> returned by these calls is the same. With Graal on there is a chance >> that a new JVMCI compiler thread could be started between these calls >> that makes test to fail. The fix temporary suspends the debuggee VM >> while these two calls to VirtualMachine.allThreads() are made. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 >> >> Thanks! >> --Daniil >> >> >> > From daniil.x.titov at oracle.com Wed Mar 6 17:16:29 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 06 Mar 2019 09:16:29 -0800 Subject: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed In-Reply-To: <5C7FFC6E.3030601@oracle.com> References: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> <48810813-6f08-c21d-c2a3-52598b1a1ce4@oracle.com> <5C7FFC6E.3030601@oracle.com> Message-ID: <513622B9-7E43-40C7-860A-AD97B958A2EA@oracle.com> Thank you, Serguei and Gary, for reviewing this change! --Daniil ?On 3/6/19, 8:57 AM, "Gary Adams" wrote: Looks OK to me. On 3/5/19, 5:47 PM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > The fix looks good. > > Thanks, > Serguei > > > On 3/5/19 1:59 PM, Daniil Titov wrote: >> Please review a fix for this test that intermittently fails with >> Graal on. >> >> The problem here is that the test does two consequent calls to >> VirtualMachine.allThreads() and checks that the number of threads >> returned by these calls is the same. With Graal on there is a chance >> that a new JVMCI compiler thread could be started between these calls >> that makes test to fail. The fix temporary suspends the debuggee VM >> while these two calls to VirtualMachine.allThreads() are made. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 >> >> Thanks! >> --Daniil >> >> >> > From gnu.andrew at redhat.com Wed Mar 6 18:25:49 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 Mar 2019 18:25:49 +0000 Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime) In-Reply-To: <5784a2dbe5944f07b1feb03b7b1f87e7@sap.com> References: <5784a2dbe5944f07b1feb03b7b1f87e7@sap.com> Message-ID: <4633f2bd-2036-e89c-5811-559d2f2b566a@redhat.com> On 22/11/2018 08:51, Lindenmaier, Goetz wrote: > Hi, > > Doesn't this have to be posted to jdk8u-dev? > > I had a look at the backport. > Including 7127191 confused me a bit. Is it good to hide the fact that > this was backported in the repository? > In os_linux one fix is missing, is this on purpose? I don't think this is a > critical issue, though, so leaving it out is fine. > >> the dropping of the changes to ... >> src/share/vm/runtime/task.cpp and >> src/os/windows/vm/attachListener_windows.cpp > These changes are included in the webrev ...? > > The webrev looks good to me. > > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Andrew Hughes >> Sent: Mittwoch, 21. November 2018 07:45 >> To: serviceability-dev ; hotspot-dev >> >> Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140482 >> Original changeset: >> https://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/rev/cd86b5699825 >> Webrev: >> https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/ >> >> The patch largely applies as is, with some adjustment for context and >> the dropping of the changes to src/cpu/x86/vm/stubRoutines_x86.cpp, >> src/share/vm/runtime/task.cpp and >> src/os/windows/vm/attachListener_windows.cpp >> which don't exist in 8u. A clean backport of 7127191 is included, which >> allows the changes to agent/src/os/linux/libproc_impl.c to apply as-is. >> >> Applying the change to 8u improves the code quality there and aids >> in backporting other changes, such as 8210836 [0]. >> >> Ok for 8u? >> >> [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018- >> November/025991.html >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Web Site: http://fuseyism.com >> Twitter: https://twitter.com/gnu_andrew_java >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Coming back to this after the 2019-01 CPU... I've flagged 7127191 with jdk8u-fix-request and I'll get that in first before revising this as a webrev for 8140482 only. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From chris.plummer at oracle.com Wed Mar 6 19:10:45 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Mar 2019 11:10:45 -0800 Subject: RFR: JDK-8201252: unquarantine nsk/jdi/ThreadReference/resume/resume001 In-Reply-To: <5C7FE862.9070505@oracle.com> References: <5C7FE862.9070505@oracle.com> Message-ID: <69efb789-4cc1-be69-d25c-26ac2b365da6@oracle.com> Looks good. Chris On 3/6/19 7:33 AM, Gary Adams wrote: > After 1000's of test runs with the resume001 test off the ProblemList, > no new sightings have been observed. I intend to use the JDK-8201252 > issue to restore the test. JDK-8072701 will be updated and left for > sustaining, if the fix needs to be applied to older releases. > > > diff --git a/test/hotspot/jtreg/ProblemList.txt > b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -157,7 +157,6 @@ > ?vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded005/TestDescription.java > 8153598 generic-all > ?vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java > 8060733 generic-all > > -vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java > 8072701 generic-all > ?vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java > 7034630 generic-all > ?vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java > 8013728 generic-all > ?vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java > 8066993 generic-all From hohensee at amazon.com Wed Mar 6 23:13:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 6 Mar 2019 23:13:59 +0000 Subject: 8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied Message-ID: <39795979-4F22-47BF-84D0-51F50301D873@amazon.com> +1. Paul ?On 3/5/19, 2:44 PM, "serviceability-dev on behalf of serguei.spitsyn at oracle.com" wrote: Hi Lin, It looks good to me too. Thanks, Serguei On 3/4/19 1:13 AM, ?? wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. > > Thanks, > Lin From thomas.stuefe at gmail.com Thu Mar 7 07:39:05 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Mar 2019 08:39:05 +0100 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: References: Message-ID: Neat! Both directions are fixed now: I can connect with new jcmd to old VMs and vice versa. Thanks a lot! ..Thomas On Mon, Mar 4, 2019 at 10:14 AM ?? wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced > by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html > . > > Thanks, > Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Mar 7 13:19:13 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 07 Mar 2019 08:19:13 -0500 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure Message-ID: <5C811A51.5080005@oracle.com> While trying to reproduce the timeout reported in JDK-8000669: com/sun/jdi/SimulResumerTest.java times out I was unable to reproduce the timeout failure, but I did occasionally see the ObjectCollectedException. The output from the test is very verbose and may be the source of the occasional timeout. I'd like to close JDK-8000669 as cannot reproduce and if it shows up again look into limiting the amount of non-essential output from the test. This is a racy test to begin with and it already is ignoring exceptions due to unexpected thread states. Adding the ignore for ObjectCollectedException allows the test to complete without errors. The graal label was recently removed. We should also remove it from the summary. Proposed changeset: diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java b/test/jdk/com/sun/jdi/SimulResumerTest.java --- a/test/jdk/com/sun/jdi/SimulResumerTest.java +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -211,6 +211,8 @@ } catch (IncompatibleThreadStateException ee) { // ignore + } catch (ObjectCollectedException ee) { + // ignore } catch (VMDisconnectedException ee) { // This is how we stop. The debuggee runs to completion // and we get this exception. From daniel.daugherty at oracle.com Thu Mar 7 14:45:51 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Mar 2019 09:45:51 -0500 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C811A51.5080005@oracle.com> References: <5C811A51.5080005@oracle.com> Message-ID: Gary, Since the 'graal' label was recently removed, I also removed "[Graal]" from the bug synopsis. Please make sure you update your commit mesg. On 3/7/19 8:19 AM, Gary Adams wrote: > While trying to reproduce the timeout reported in > ? JDK-8000669: com/sun/jdi/SimulResumerTest.java times out > > I was unable to reproduce the timeout failure, but I did occasionally > see the ObjectCollectedException. The output from the test is very > verbose > and may be the source of the occasional timeout. I'd like to close > JDK-8000669 > as cannot reproduce and if it shows up again look into limiting the > amount > of non-essential output from the test. > > This is a racy test to begin with and it already is ignoring exceptions > due to unexpected thread states. Adding the ignore for > ObjectCollectedException > allows the test to complete without errors. > > The graal label was recently removed. We should also remove it from > the summary. > > Proposed changeset: > > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > b/test/jdk/com/sun/jdi/SimulResumerTest.java > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -211,6 +211,8 @@ > > ???????????? } catch (IncompatibleThreadStateException ee) { > ???????????????? // ignore > +??????????? } catch (ObjectCollectedException ee) { > +??????????????? // ignore > ???????????? } catch (VMDisconnectedException ee) { > ???????????????? // This is how we stop.? The debuggee runs to completion > ???????????????? // and we get this exception. There should be some sort of comment explaining why it is okay to ignore the ObjectCollectedException. When the IncompatibleThreadStateException was ignored, there should have been a comment added for that also. Dan From daniil.x.titov at oracle.com Thu Mar 7 17:40:33 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Mar 2019 09:40:33 -0800 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed Message-ID: <9E3AB01E-4A67-4595-A47F-0ECECE4BF629@oracle.com> Please review a change that fixes this test. The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 Mach5 tier1, tier2 and tier3 tests successfully passed with this change. Thanks! -Daniil From daniil.x.titov at oracle.com Thu Mar 7 17:44:10 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Mar 2019 09:44:10 -0800 Subject: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed Message-ID: Resending review request with corrected subject... Please review a fix for this test that intermittently fails with Graal on. The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 Thanks! --Daniil From daniil.x.titov at oracle.com Thu Mar 7 17:50:38 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Mar 2019 09:50:38 -0800 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: <12B146A7-C31C-4B9A-9CBE-06702C011DA4@oracle.com> Please disregard this email, somehow it got a wrong body.. Will resend the request later after dealing with my mail client. Best regards, Danill ?On 3/7/19, 9:46 AM, "serviceability-dev on behalf of Daniil Titov" wrote: Resending review request with corrected subject... Please review a fix for this test that intermittently fails with Graal on. The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 Thanks! --Daniil From daniil.x.titov at oracle.com Thu Mar 7 17:54:50 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Mar 2019 09:54:50 -0800 Subject: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed Message-ID: Please review a change that fixes this test. The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 Mach5 tier1, tier2 and tier3 tests successfully passed with this change. Thanks! -Daniil -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Mar 7 18:57:56 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 07 Mar 2019 13:57:56 -0500 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes Message-ID: <5C8169B4.5080305@oracle.com> This proposed fix will restore the ResourceExhausted tests. Test 3 and 4 were on the ProblemList because of the potential path issues in finding the correct classes. This change searches the test.class.path for the appropriate vmTestbase classes rather than using incorrect settings on the command line. Some clean up has been done to remove quarantine keyword and @ignore directives. Should additional clean up be done to remove bug numbers, etc.? TEST.PROPERTIES were added so test 3 so it is consistent with the other tests in the group. Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html Local testing has been successful on a linux-x64-debug build. Testing on mach5 for other platforms next. From daniel.daugherty at oracle.com Thu Mar 7 19:08:42 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Mar 2019 14:08:42 -0500 Subject: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: <23478782-962c-cc85-1764-87c272e6809a@oracle.com> On 3/7/19 12:54 PM, Daniil Titov wrote: > > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and > with Graal on additional threads the test doesn't expect are started > and cause the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that > affects whether Java compiler threads are retuned with JVMTI > GetAllThreads call. By default this capability is off. The fix also > adds " HotSpotGraalManagement Bean Registration" thread to the list of > the threads the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > src/hotspot/share/prims/jvmti.xml ??? L10382: ????? ??????? You might want to include a diff between the old generated jvmti.h ??????? and the new one. I expect it to show something like this: ???? ???? unsigned int can_generate_resource_exhaustion_threads_events : 1; ????????? +??? unsigned int can_show_compiler_threads : 1; ????????? -??? unsigned int : 7; ????????? +??? unsigned int : 6; ??????? Also, I think this will need a JVM/TI version bump so that an agent ??????? can conditionally compile in the code that accesses the new ??????? can_show_compiler_threads field. ??????? This also will need a CSR since it is changing an API. src/hotspot/share/prims/jvmtiEnv.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.hpp ??? No comments. src/hotspot/share/prims/jvmtiManageCapabilities.cpp ??? No comments. src/hotspot/share/services/threadService.cpp ??? L1048: ??? if (!include_compiler_threads && jt->is_Compiler_thread()) { ? ? L1049: ??????? continue; ??????? nit - please reduce indent by two spaces src/hotspot/share/services/threadService.hpp ??? No comments. test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ??? No comments. Thumbs up on the code changes. Double check with Serguei about the need for a CSR... Dan > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > > -Daniil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Mar 7 20:19:28 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 7 Mar 2019 12:19:28 -0800 Subject: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: There are other places where is_hidden_from_external_view() is used.? Should is_hidden_from_external_view() also check the new capability?? If so, then you can simplify your changes.? I'm not sure the new capability is the best choice, however.? There is still no way to control whether compiler threads can post events, hit breakpoints, single-step, etc.? And "compiler thread" might be too specific.? There might be other types of "system thread" that we want to ignore.? Since this is a JVMTI spec change, I think it deserves more discussion.? For example, an alternative would be a way to set "can debug"/"visible"/"can post events"/etc flags on individual threads. dl On 3/7/19 9:54 AM, Daniil Titov wrote: > > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and > with Graal on additional threads the test doesn't expect are started > and cause the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that > affects whether Java compiler threads are retuned with JVMTI > GetAllThreads call. By default this capability is off. The fix also > adds " HotSpotGraalManagement Bean Registration" thread to the list of > the threads the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > > -Daniil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Mar 7 21:02:32 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Mar 2019 13:02:32 -0800 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C8169B4.5080305@oracle.com> References: <5C8169B4.5080305@oracle.com> Message-ID: Hi Gary, Why did you remove the "nonconcurrent" keyword. I know these are just comments for reference that were added when the test was ported from tonga, but as a comment it is still applicable. The test should not be run concurrent with others (which you have also fixed with the addition of the "exclusiveAccess.dirs=."). Otherwise changes look good. thanks, Chris On 3/7/19 10:57 AM, Gary Adams wrote: > This proposed fix will restore the ResourceExhausted tests. > > Test 3 and 4 were on the ProblemList because of the potential > path issues in finding the correct classes. This change searches the > test.class.path for the appropriate vmTestbase classes rather than using > incorrect settings on the command line. > > Some clean up has been done to remove quarantine keyword > and @ignore directives. Should additional clean up be done to remove > bug numbers, etc.? > > TEST.PROPERTIES were added so test 3 so it is consistent with the > other tests > in the group. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 > ? Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html > > Local testing has been successful on a linux-x64-debug build. > Testing on mach5 for other platforms next. From leonid.mesnik at oracle.com Thu Mar 7 21:06:26 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 07 Mar 2019 13:06:26 -0800 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C8169B4.5080305@oracle.com> References: <5C8169B4.5080305@oracle.com> Message-ID: <561e44870ad7ba4887c1a4edf3d472f9b346c3cd.camel@oracle.com> Hi The problemlist http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/ProblemList.txt.udiff.html Tests are excluded because of https://bugs.openjdk.java.net/browse/JDK-6606767 which is not fixed yet. Why do you want to remove them from problemlist? Also I think it is a good time to update test desrption in the http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java.udiff.html Currently it says about PermGen OOME. Leonid On Thu, 2019-03-07 at 13:57 -0500, Gary Adams wrote: > This proposed fix will restore the ResourceExhausted tests. Test 3 and 4 were on the ProblemList because of the potential path issues in finding the correct classes. This change searches the test.class.path for the appropriate vmTestbase classes rather than using incorrect settings on the command line. Some clean up has been done to remove quarantine keyword and @ignore directives. Should additional clean up be done to remove bug numbers, etc.? TEST.PROPERTIES were added so test 3 so it is consistent with the other tests in the group. Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html Local testing has been successful on a linux-x64-debug build. Testing on mach5 for other platforms next. From zanglin5 at jd.com Fri Mar 8 05:32:31 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 8 Mar 2019 05:32:31 +0000 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: References: , Message-ID: <80aebf96ee8b40419bb44c5a0f1c34cd@jd.com> Thanks all for reviewing it. I think it could be pushed now, right? BRs, Lin ________________________________________ From: Thomas St?fe Sent: Thursday, March 7, 2019 3:39:05 PM To: ?? Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Subject: Re: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied Neat! Both directions are fixed now: I can connect with new jcmd to old VMs and vice versa. Thanks a lot! ..Thomas On Mon, Mar 4, 2019 at 10:14 AM ?? > wrote: Dear All, May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. Thanks, Lin From jcbeyler at google.com Fri Mar 8 06:41:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 7 Mar 2019 22:41:19 -0800 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: <9E3AB01E-4A67-4595-A47F-0ECECE4BF629@oracle.com> References: <9E3AB01E-4A67-4595-A47F-0ECECE4BF629@oracle.com> Message-ID: Hi Daniil, If we accept that by default compiler threads should not show up in GetAllThreads, then the webrev looks good to me. However, I believe a while ago we talked about in this mailing list about a longer and broader conversation about what to do about Graal compiler threads and even stack traces containing graal stacks. Is this the right way to go in that broader case? Perhaps I'm complicating the review of this but I just would like a better idea of how Graal compiler threads are to be handled across the board in the terms of these tests and our profiling tools in general, Jc On Thu, Mar 7, 2019 at 9:41 AM Daniil Titov wrote: > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and with > Graal on additional threads the test doesn't expect are started and cause > the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that > affects whether Java compiler threads are retuned with JVMTI GetAllThreads > call. By default this capability is off. The fix also adds " > HotSpotGraalManagement Bean Registration" thread to the list of the threads > the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > -Daniil > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Mar 8 07:26:32 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 7 Mar 2019 23:26:32 -0800 Subject: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: <37088376-26a5-e7a8-0a19-6ef0bc5a1d30@oracle.com> This part seems to change the value for the include_jni_attaching_threads arg from true to false: - ThreadsListEnumerator tle(Thread::current(), true); + ThreadsListEnumerator tle(Thread::current(), true, false, JvmtiExport::should_show_compiler_threads()); dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 8 09:12:07 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Mar 2019 09:12:07 +0000 Subject: 6504660: HPI panic callback is dead code References: <3457f784-4e86-5b31-c947-29fce8687cee@oracle.com> Message-ID: <04B06C99-9C7A-4033-BC2A-C414C024C238@oracle.com> Looping in serviceability-dev at openjdk.java.net. Thanks, Brian > Begin forwarded message: > > From: Claes Redestad > Subject: Re: 6504660: HPI panic callback is dead code > Date: March 7, 2019 at 9:43:45 AM GMT > To: Brian Burkhalter , core-libs-dev > > Hi Brian, > > looks fine! > > Thanks! > > /Claes > > On 2019-03-07 10:39, Brian Burkhalter wrote: >> Please review this fix [1] to remove dead code [2]. >> Thanks, >> Brian >> [1] http://cr.openjdk.java.net/~bpb/6504660/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-6504660 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Mar 8 11:59:47 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 Mar 2019 11:59:47 +0000 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> Message-ID: <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> Hi Severin, On 05/03/2019 14:33, Severin Gehwolf wrote: > Hi Daniel, > > Latest webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/03/webrev/ > > It's incorporating your changes wrt. to some timeouts and asserting the > expected exit code. Instead of the ProcessThread changes, I'm using the > sendMessage() approach. That API is already there. Oh - nice finding, thanks for that! :-) > Unfortunately when running both SSL and plain sockets tests, it would > randomly fail for me. Even if I choose different sets of ports for > plain/ssl. So I've taken a different route of randomly selecting SSL or > plain. Overall, this should give reasonable coverage for both (plain > and SSL). This made test stability improve a lot on my Linux x86_64 > machine. Ran for 100 iterations without failure. Did you try it with a Thread.sleep(1000); statement inserted between the plain test and the SSL test? FWIW - I have imported your changes, and sent them as is in our test system. Ran them 200 times on each platform - got only one failure - on Linux x64, where one of the process failed with "address already in use". I believe this is bound to happen from time to time if by misfortune some other process on the host is binding to the same port. Then I modified your changes to test both plain and SSL, with a sleep(1000) between the two - and observed the same behavior: 1 random failure out of 200 runs (which happened on Linux x64 too but on a different machine in the farm). I'd suggest to preemptively add the `@key intermittent` keyword to the test - this hints to future maintainers (and to people that analyze failures during build promotions) that the test is known to fail intermittently. 1 out of 200 runs is probably an acceptable failure rate for that kind of test. If I could think of any way to get rid of such random failures I would insist that we fix the test before pushing it, but unfortunately I have come to the conclusion that the nature of the feature we're trying to test rules out any of the usual tricks we could try. So to sum it up: - please add the `@key intermittent` keyword - please verify on your local box if testing both plain & SSL with a Thread.sleep(1000) in between makes the test more stable. If it does, then I'd prefer we go down this road rather than selecting one plain vs SSL at random. Then I think you're good to go - you can count me in as Reviewer. If the failure rate becomes too noisy in the future, then we can revisit - and one possibility will then be to turn this test into a manual test. Sorry to have been a bit picky - I hate intermittent failures with a passion ;-) best regards, -- daniel > > I'll run this through jdk/submit now. Could you run this through your > test system too, please? > > Would you be OK with getting this patch pushed once we'd have positive > results for both? > > Thanks, > Severin > > On Fri, 2019-03-01 at 15:08 +0000, Daniel Fuchs wrote: >> Hi Severin, >> >> On 28/02/2019 15:47, Severin Gehwolf wrote: >>> Yes, thanks for looking at this Daniel. That was my determination as >>> well. However, even if we do all of the above, and add a test config >>> with /etc/hosts mapping a non-loopback address to "localhost" it would >>> break other tests. E.g. this one: >>> java/net/InetAddress/GetLocalHostWithSM.java >>> >>> So I'd have to explore whether your suggestion with >>> InetAddress.getLocalHost() is viable. It seems promising. >>> >>> I'll keep you posted. >> >> Thanks for keeping the investigation going! >> >> For what it's worth this is what I have been experimenting with: >> http://cr.openjdk.java.net/~dfuchs/experiment-8219585/experiment.00/ >> >> It's only a POC and obviously need more cleaning. >> Maybe some of the arbitrary timeouts in the test could be scaled >> in accordance to timeout-factor (I think there's an adjustTimeout(long) >> function somewhere in the test libs that does that). >> >> I ran it 50 times in our test system - and it passed on all platforms, >> so there's yet hope :-) >> >> hope this helps, >> >> -- daniel >> >> > From gary.adams at oracle.com Fri Mar 8 12:44:12 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Mar 2019 07:44:12 -0500 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <561e44870ad7ba4887c1a4edf3d472f9b346c3cd.camel@oracle.com> References: <5C8169B4.5080305@oracle.com> <561e44870ad7ba4887c1a4edf3d472f9b346c3cd.camel@oracle.com> Message-ID: <5C82639C.2030505@oracle.com> The tests have been excluded for a long time now. It appears that the tests are working at this time. I'll have more confidence in taking them off the ProblemList when the testing has been done on more platforms. Please let me know what you'd like the description to say to bring it up to date. On 3/7/19, 4:06 PM, Leonid Mesnik wrote: > Hi > The problemlist > > http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/ProblemList.txt.udiff.html > > Tests are excluded because of > https://bugs.openjdk.java.net/browse/JDK-6606767 > which is not fixed yet. Why do you want to remove them from > problemlist? > > Also I think it is a good time to update test desrption in the > > http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java.udiff.html > > Currently it says about PermGen OOME. > > Leonid > > On Thu, 2019-03-07 at 13:57 -0500, Gary Adams wrote: >> This proposed fix will restore the ResourceExhausted tests. > Test 3 and 4 were on the ProblemList because of the potential > path issues in finding the correct classes. This change searches the > test.class.path for the appropriate vmTestbase classes rather than > using > incorrect settings on the command line. > > Some clean up has been done to remove quarantine keyword > and @ignore directives. Should additional clean up be done to remove > bug numbers, etc.? > > TEST.PROPERTIES were added so test 3 so it is consistent with the > other > tests > in the group. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 > Webrev: > http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html > > Local testing has been successful on a linux-x64-debug build. > Testing on mach5 for other platforms next. > From gary.adams at oracle.com Fri Mar 8 13:07:11 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Mar 2019 08:07:11 -0500 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: References: <5C8169B4.5080305@oracle.com> Message-ID: <5C8268FF.8050007@oracle.com> I'll revert the comments that were left in during the tonga conversion. I did come across an interesting test failure in resexhausted001 which had an @ignore 7013634 JDK-7013634: jvmti resexhausted001 can timeout or fail due to excessive thread creation The test was closed because it was not reproducible. Even though the test was not on the ProblemList, I believe jtreg was excluding the test from running. The original problem reported an "out of swap" condition. The current failure reports: ----------System.out:(3/217)---------- Creating threads... Timeout refired 480 times [730.871s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. On 3/7/19, 4:02 PM, Chris Plummer wrote: > Hi Gary, > > Why did you remove the "nonconcurrent" keyword. I know these are just > comments for reference that were added when the test was ported from > tonga, but as a comment it is still applicable. The test should not be > run concurrent with others (which you have also fixed with the > addition of the "exclusiveAccess.dirs=."). > > Otherwise changes look good. > > thanks, > > Chris > > On 3/7/19 10:57 AM, Gary Adams wrote: >> This proposed fix will restore the ResourceExhausted tests. >> >> Test 3 and 4 were on the ProblemList because of the potential >> path issues in finding the correct classes. This change searches the >> test.class.path for the appropriate vmTestbase classes rather than using >> incorrect settings on the command line. >> >> Some clean up has been done to remove quarantine keyword >> and @ignore directives. Should additional clean up be done to remove >> bug numbers, etc.? >> >> TEST.PROPERTIES were added so test 3 so it is consistent with the >> other tests >> in the group. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >> Webrev: >> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >> >> Local testing has been successful on a linux-x64-debug build. >> Testing on mach5 for other platforms next. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Mar 8 13:16:44 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Mar 2019 08:16:44 -0500 Subject: RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed Message-ID: <5C826B3C.8030700@oracle.com> I've been able to reproduce the socket teardown failure in tc10x001. It appears that the debugee sends it's final output and then exits. If the debugee exits while the debugger is receiving the final output, it can result in a socket error. This proposed fix forces the debugee to wait until the debugger acknowledges it has processed the final output before exitting. Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ The original bug was filed before these tests were in the open repos. None of the other tests in the nsk/jdi/BScenarios set have shown this problem, because they do not have an early debuggee exit sequence. From sgehwolf at redhat.com Fri Mar 8 13:20:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Mar 2019 14:20:49 +0100 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> Message-ID: <9918ce41ca8bc666a1d8ab10c6d902ac728c16d4.camel@redhat.com> On Fri, 2019-03-08 at 11:59 +0000, Daniel Fuchs wrote: > - please verify on your local box if testing both plain & > SSL with a Thread.sleep(1000) in between makes the test > more stable. If it does, then I'd prefer we go down > this road rather than selecting one plain vs SSL at random. I've tested this before. With a sleep of 1 or 2 seconds. It didn't work reliably for me (it might have been a fastdebug JVM). Eventually, the SSL version of the test would fail. Yet, the latest version of the webrev used different sets of ports for SSL and plain so that led me to believe it's not related to a port clash. So Thread.sleep() wouldn't help. Have you tried without the sleep at all and running both plain and SSL in your test system? This is what I have tried: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/ If you think we should try this one. That's fine with me. Thanks, Severin From chris.plummer at oracle.com Fri Mar 8 16:58:34 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Mar 2019 08:58:34 -0800 Subject: RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed In-Reply-To: <5C826B3C.8030700@oracle.com> References: <5C826B3C.8030700@oracle.com> Message-ID: <245abec8-6e3a-6aab-0c91-f362e8221461@oracle.com> Looks good. Chris On 3/8/19 5:16 AM, Gary Adams wrote: > I've been able to reproduce the socket teardown failure in tc10x001. > It appears that the debugee sends it's final output and then exits. > If the debugee exits while the debugger is receiving the final output, > it can result in a socket error. > > This proposed fix forces the debugee to wait until the debugger > acknowledges it has processed the final output before exitting. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ > > The original bug was filed before these tests were in the open repos. > > None of the other tests in the nsk/jdi/BScenarios set have shown this > problem, > because they do not have an early debuggee exit sequence. From chris.plummer at oracle.com Fri Mar 8 17:10:01 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Mar 2019 09:10:01 -0800 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C8268FF.8050007@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Mar 8 17:19:03 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Mar 2019 09:19:03 -0800 Subject: 6504660: HPI panic callback is dead code In-Reply-To: <04B06C99-9C7A-4033-BC2A-C414C024C238@oracle.com> References: <3457f784-4e86-5b31-c947-29fce8687cee@oracle.com> <04B06C99-9C7A-4033-BC2A-C414C024C238@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Mar 8 17:18:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Mar 2019 12:18:24 -0500 Subject: 6504660: HPI panic callback is dead code In-Reply-To: <04B06C99-9C7A-4033-BC2A-C414C024C238@oracle.com> References: <3457f784-4e86-5b31-c947-29fce8687cee@oracle.com> <04B06C99-9C7A-4033-BC2A-C414C024C238@oracle.com> Message-ID: > http://cr.openjdk.java.net/~bpb/6504660/webrev.00/ src/jdk.jdwp.agent/unix/native/libjdwp/linker_md.c ??? Looks like a clean removal of the dead code. Thumbs up. Your call on whether you want to wait on someone from the current Serviceability team to chime in... Dan On 3/8/19 4:12 AM, Brian Burkhalter wrote: > Looping in serviceability-dev at openjdk.java.net > . > > Thanks, > > Brian > >> Begin forwarded message: >> >> *From: *Claes Redestad > > >> *Subject: **Re: 6504660: HPI panic callback is dead code* >> *Date: *March 7, 2019 at 9:43:45 AM GMT >> *To: *Brian Burkhalter > >, core-libs-dev >> > >> >> Hi Brian, >> >> looks fine! >> >> Thanks! >> >> /Claes >> >> On 2019-03-07 10:39, Brian Burkhalter wrote: >>> Please review this fix [1] to remove dead code [2]. >>> Thanks, >>> Brian >>> [1] http://cr.openjdk.java.net/~bpb/6504660/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-6504660 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Mar 8 17:41:24 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Mar 2019 12:41:24 -0500 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> Message-ID: <5C82A944.9020506@oracle.com> On 3/8/19, 12:10 PM, Chris Plummer wrote: > You can remove the quarantine and exclude keywords. I think that's > appropriate if the test is off the problemlist and working. It was > just nonconcurrent removal that I was against. Done > > As for the resexhausted001 failure you are still seeing, how could > jtreg exclude it if it was not on the problemlist. I didn't think > there was any other mechanism. I don't believe jtreg looks at the > tonga keywords. I believe the @ignore is a jtreg keyword. With the -ignore command line flag jtreg can be directed to quietly ignore a test, or force an error, or attempt to run the test even though the @ignore directive is there. > > thanks, > > Chris > > On 3/8/19 5:07 AM, Gary Adams wrote: >> I'll revert the comments that were left in during the tonga conversion. >> >> I did come across an interesting test failure in resexhausted001 >> which had an >> @ignore 7013634 >> >> JDK-7013634: jvmti resexhausted001 can timeout or fail due to >> excessive thread creation >> >> The test was closed because it was not reproducible. >> Even though the test was not on the ProblemList, I believe >> jtreg was excluding the test from running. >> >> The original problem reported an "out of swap" condition. >> >> The current failure reports: >> ----------System.out:(3/217)---------- >> Creating threads... >> Timeout refired 480 times >> [730.871s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >> >> >> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> Why did you remove the "nonconcurrent" keyword. I know these are >>> just comments for reference that were added when the test was ported >>> from tonga, but as a comment it is still applicable. The test should >>> not be run concurrent with others (which you have also fixed with >>> the addition of the "exclusiveAccess.dirs=."). >>> >>> Otherwise changes look good. >>> >>> thanks, >>> >>> Chris >>> >>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>> This proposed fix will restore the ResourceExhausted tests. >>>> >>>> Test 3 and 4 were on the ProblemList because of the potential >>>> path issues in finding the correct classes. This change searches the >>>> test.class.path for the appropriate vmTestbase classes rather than >>>> using >>>> incorrect settings on the command line. >>>> >>>> Some clean up has been done to remove quarantine keyword >>>> and @ignore directives. Should additional clean up be done to remove >>>> bug numbers, etc.? >>>> >>>> TEST.PROPERTIES were added so test 3 so it is consistent with the >>>> other tests >>>> in the group. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>> Webrev: >>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>> >>>> Local testing has been successful on a linux-x64-debug build. >>>> Testing on mach5 for other platforms next. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Fri Mar 8 18:24:18 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 8 Mar 2019 10:24:18 -0800 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C82639C.2030505@oracle.com> References: <5C8169B4.5080305@oracle.com> <561e44870ad7ba4887c1a4edf3d472f9b346c3cd.camel@oracle.com> <5C82639C.2030505@oracle.com> Message-ID: <20BF0B1F-403E-4220-8B64-10747A98D928@oracle.com> > On Mar 8, 2019, at 4:44 AM, Gary Adams wrote: > > The tests have been excluded for a long time now. > It appears that the tests are working at this time. > I'll have more confidence in taking them off the ProblemList when > the testing has been done on more platforms. > Please add this information into bug, to make clear that this change was intentional. > Please let me know what you'd like the description to say to bring it up to date. I think that it is enough just to change PermGen to Metaspace. Leonid > > On 3/7/19, 4:06 PM, Leonid Mesnik wrote: >> Hi >> The problemlist >> >> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/ProblemList.txt.udiff.html >> >> Tests are excluded because of >> https://bugs.openjdk.java.net/browse/JDK-6606767 >> which is not fixed yet. Why do you want to remove them from >> problemlist? >> >> Also I think it is a good time to update test desrption in the >> >> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java.udiff.html >> >> Currently it says about PermGen OOME. >> >> Leonid >> >> On Thu, 2019-03-07 at 13:57 -0500, Gary Adams wrote: >>> This proposed fix will restore the ResourceExhausted tests. >> Test 3 and 4 were on the ProblemList because of the potential >> path issues in finding the correct classes. This change searches the >> test.class.path for the appropriate vmTestbase classes rather than >> using >> incorrect settings on the command line. >> >> Some clean up has been done to remove quarantine keyword >> and @ignore directives. Should additional clean up be done to remove >> bug numbers, etc.? >> >> TEST.PROPERTIES were added so test 3 so it is consistent with the >> other >> tests >> in the group. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >> Webrev: >> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >> >> Local testing has been successful on a linux-x64-debug build. >> Testing on mach5 for other platforms next. >> > From chris.plummer at oracle.com Fri Mar 8 20:39:33 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Mar 2019 12:39:33 -0800 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C82A944.9020506@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> Message-ID: <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Mar 11 07:31:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2019 17:31:07 +1000 Subject: RFR: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed In-Reply-To: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> References: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> Message-ID: <0f6330f7-aa7e-2281-0b9b-9e979e2ae9f9@oracle.com> On 6/03/2019 7:59 am, Daniil Titov wrote: > Please review a fix for this test that intermittently fails with Graal on. > > The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. Is this because Graal/JVMCI compiler threads are returned by allThreads() while regular compiler threads are not? Suspending the VM seems safest regardless. Thanks, David ----- > Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 > > Thanks! > --Daniil > > > From gary.adams at oracle.com Mon Mar 11 11:43:41 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 11 Mar 2019 07:43:41 -0400 Subject: RFR: JDK-8149461: jmap kills process if non-java pid is specified in the command line In-Reply-To: <6d6b490d-7c48-e33f-12ff-33bee1723c5c@oracle.com> References: <5C6598E9.8090309@oracle.com> <30a54b44-db69-c9e4-c9f1-23425e8ae8e3@oracle.com> <5C65BD84.1090704@oracle.com> <676a6f1e-be6d-ced3-7c16-c97d5e75d196@oracle.com> <5C66B0B9.8050409@oracle.com> <5C66BC96.7020008@oracle.com> <5C66C25B.1050206@oracle.com> <5C66EAAE.9040806@oracle.com> <86d191a2-21ab-9125-4af0-697a4dd57837@oracle.com> <5C670779.4030600@oracle.com> <6d6b490d-7c48-e33f-12ff-33bee1723c5c@oracle.com> Message-ID: <5C8649ED.3070203@oracle.com> I'd like to bring closure to this issue. Even if we could reliable detect libjvm has been loaded in a process, it does not guarantee the VM has entered the live phase, has set up the signal handlers and is prepared proceed with the attach mechanism. Without any further input, I'll close this bug on Wed Mar 13, 2019. I'll add as much documentation as possible before closing the issue, but it is unlikely to be repopened as the use case falls outside the reasonable use of the feature. On 2/19/19, 10:50 PM, David Holmes wrote: > On 19/02/2019 10:07 pm, gary.adams at oracle.com wrote: >> I'm fine with just closing the bug as will not fix. > > I personally think it is a non-issue but others (Hi Thomas!) consider > it a real problem. > >> The issue deals with a situation where the user provided the wrong pid >> and the consequences were unexpected. >> >> The changes I was prototyping demonstrate that it is possible to >> restrict >> the cases where the attach would be limited to those Java processes >> that are visible to jps. >> >> Extending to those processes that are run with -XX:-UsePerfData will >> require >> some additional mechanism. A command line approach would introduce >> an incompatibility. Is there some other mechanism that could be used? > > Only what Thomas suggested in using a platform specific mechanism to > verify the pid is for a Java process. Though a simple binary name > check doesn't suffice as the VM may be embedded in another process, so > actually checking for libjvm as Thomas suggested may be the only > practical and reliable way to do this. > > Thanks, > David > ----- > >> On 2/15/19 9:20 PM, David Holmes wrote: >>> But this will still break existing behaviour as without UsePerfData >>> you will now have to use -f whereas it currently "just works". >>> >>> This will need a CSR request for any new flag or change in behaviour. >>> >>> But to be blunt I don't like where this is going and the cure seems >>> far worse than the disease. >>> >>> David >>> >>> On 16/02/2019 4:39 am, Gary Adams wrote: >>>> It isn't pretty, but it's functional : "-f to force >>>> communication. ... >>>> >>>> Revised webrev: >>>> http://cr.openjdk.java.net/~gadams/8149461/webrev.02/ >>>> >>>> On 2/15/19, 11:57 AM, Daniel D. Daugherty wrote: >>>>> Yes. That's the direction I was thinking about. >>>>> Don't know about the '-F' versus '-F ', but >>>>> that a cmd line option parsing detail. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/15/19 11:37 AM, Gary Adams wrote: >>>>>> Here's a quick dirty "-F" that gets past >>>>>> the "-XX:-UsePerfData" setting for jcmd. >>>>>> Need to follow up on docs and usage >>>>>> for the other commands. >>>>>> >>>>>> Is this the direction you were thinking? >>>>>> >>>>>> diff --git >>>>>> a/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.javab/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java >>>>>> >>>>>> --- >>>>>> a/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java >>>>>> >>>>>> +++ >>>>>> b/src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java >>>>>> >>>>>> @@ -48,16 +48,27 @@ >>>>>> public class ProcessArgumentMatcher { >>>>>> private String matchClass; >>>>>> private String singlePid; >>>>>> + private static boolean bypassPid; >>>>>> + private long pid; >>>>>> >>>>>> public ProcessArgumentMatcher(String pidArg) { >>>>>> if (pidArg == null || pidArg.isEmpty()) { >>>>>> throw new IllegalArgumentException("Pid string is >>>>>> invalid"); >>>>>> } >>>>>> if (pidArg.charAt(0) == '-') { >>>>>> + if (pidArg.charAt(1) == 'F') { >>>>>> + // Allow -F to bypass the pid check >>>>>> + pid = Long.parseLong(pidArg.substring(2)); >>>>>> + if (pid != 0) { >>>>>> + singlePid = String.valueOf(pid); >>>>>> + } >>>>>> + bypassPid = true; >>>>>> + } else { >>>>>> throw new IllegalArgumentException("Unrecognized " + >>>>>> pidArg); >>>>>> } >>>>>> + } >>>>>> try { >>>>>> - long pid = Long.parseLong(pidArg); >>>>>> + pid = Long.parseLong(pidArg); >>>>>> if (pid != 0) { >>>>>> singlePid = String.valueOf(pid); >>>>>> } >>>>>> @@ -170,4 +181,21 @@ >>>>>> public Collection getVirtualMachinePids() { >>>>>> return this.getVirtualMachinePids(null); >>>>>> } >>>>>> + >>>>>> + // Check that pid matches a known running Java process >>>>>> + public static boolean checkJavaPid(String pid) { >>>>>> + // Skip the perf data pid visibility check if >>>>>> "-F" requested. >>>>>> + if (bypassPid) { >>>>>> + return true; >>>>>> } >>>>>> + List l = VirtualMachine.list(); >>>>>> + boolean found = false; >>>>>> + for (VirtualMachineDescriptor vmd: l) { >>>>>> + if (vmd.id().equals(pid)) { >>>>>> + found = true; >>>>>> + break; >>>>>> + } >>>>>> + } >>>>>> + return found; >>>>>> + } >>>>>> +} >>>>>> On 2/15/19, 10:24 AM, Daniel D. Daugherty wrote: >>>>>>> On 2/15/19 8:44 AM, Gary Adams wrote: >>>>>>>> Confirmed >>>>>>>> -XX:-UsePerfData >>>>>>>> >>>>>>>> prevents visibility to jps, but allows direct access via pid. >>>>>>>> >>>>>>>> The new check would block access before the attach is attempted. >>>>>>>> >>>>>>>> May be best to close this bug as "will not fix". >>>>>>>> Requires a valid Java process pid. >>>>>>> >>>>>>> Or make it a best effort solution. The idea that a jmap on a >>>>>>> non-Java >>>>>>> PID could kill that PID violates the "do no harm" principle for an >>>>>>> observer tool. >>>>>>> >>>>>>> Of what I have seen on the thread so far, I like these: >>>>>>> >>>>>>> - make the PID check on the specified PID only (should be pretty >>>>>>> fast) >>>>>>> - add a force option that tries to attach to the PID regardless >>>>>>> of what the sanity check says; that will solve the >>>>>>> -XX:-UsePerfData >>>>>>> problem. >>>>>>> >>>>>>> Writing/updating tests for this is going to be "interesting". >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On 2/15/19, 8:29 AM, Bernd Eckenfels wrote: >>>>>>>>> I wonder, instead of listing all VMs, would it be better to >>>>>>>>> check only the target PID? >>>>>>>>> >>>>>>>>> BTW speaking of hs_perf files: is it supposed to work without >>>>>>>>> -XX:-UserPerfData also? >>>>>>>>> >>>>>>>>> Gruss >>>>>>>>> Bernd >>>>>>>>> >>>>>>>>> Gruss >>>>>>>>> Bernd >>>>>>>>> -- >>>>>>>>> http://bernd.eckenfels.net >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *Von:* Gary Adams >>>>>>>>> *Gesendet:* Freitag, Februar 15, 2019 2:19 PM >>>>>>>>> *An:* gary.adams at oracle.com >>>>>>>>> *Cc:* Bernd Eckenfels; OpenJDK Serviceability >>>>>>>>> *Betreff:* Re: RFR: JDK-8149461: jmap kills process if >>>>>>>>> non-java pid is specified in the command line >>>>>>>>> On a linux system with 1 Java process and 500 non-Java processes, >>>>>>>>> /tmp is not tmpfs mounted, 20 runs average 255.5 ms stddev 9.32. >>>>>>>>> >>>>>>>>> JDK-8176828 is the issue that enabled perfmemory visibility >>>>>>>>> once the vm is in live mode. >>>>>>>>> >>>>>>>>> For containers that are configured without a shared view of >>>>>>>>> /tmp, it may be necessary >>>>>>>>> to include a override of the pid check. >>>>>>>>> >>>>>>>>> On 2/15/19, 7:29 AM, Gary Adams wrote: >>>>>>>>>> I'll get some measurements on some local systems so we have a >>>>>>>>>> specific idea about the overhead of the pid check. >>>>>>>>>> I imagine in most production environments the /tmp tmpfs >>>>>>>>>> is memory only set of checks. >>>>>>>>>> >>>>>>>>>> One of the "not all vms are recognized" was fixed recently. >>>>>>>>>> When starting a libjdwp session with server=y and suspend=y, >>>>>>>>>> the vm was not recognized until a debugger was attached. >>>>>>>>>> >>>>>>>>>> I'm not opposed to adding a force option to skip the valid pid >>>>>>>>>> check. It might be better effort fixing the hung vm case if we >>>>>>>>>> have a concrete failure to investigate. >>>>>>>>>> >>>>>>>>>> On 2/15/19, 6:47 AM, Bernd Eckenfels wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I see possible issues here, not sure if they still exist but >>>>>>>>>>> I wanted to mention them: >>>>>>>>>>> >>>>>>>>>>> the list-vm function might be slow on a loaded system (as it >>>>>>>>>>> is a complex function). It?s not the best Situation if your >>>>>>>>>>> diagnostic attempts are slow down in such a situation. >>>>>>>>>>> >>>>>>>>>>> Also in the past not all VMs might be recognized by the list >>>>>>>>>>> function, a more targeted attach could still succeed. Is >>>>>>>>>>> that addressed since the container-PID changes? In both >>>>>>>>>>> cases a force option would help. >>>>>>>>>>> >>>>>>>>>>> Gruss >>>>>>>>>>> Bernd >>>>>>>>>>> >>>>>>>>>>> Gruss >>>>>>>>>>> Bernd >>>>>>>>>>> -- >>>>>>>>>>> http://bernd.eckenfels.net >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> *Von:* serviceability-dev >>>>>>>>>>> im Auftrag von >>>>>>>>>>> gary.adams at oracle.com >>>>>>>>>>> *Gesendet:* Freitag, Februar 15, 2019 12:07 PM >>>>>>>>>>> *An:* Thomas St?fe; David Holmes; Chris Plummer >>>>>>>>>>> *Cc:* OpenJDK Serviceability >>>>>>>>>>> *Betreff:* Re: RFR: JDK-8149461: jmap kills process if >>>>>>>>>>> non-java pid is specified in the command line >>>>>>>>>>> Let me clarify a few things about the proposed fix. >>>>>>>>>>> >>>>>>>>>>> The VirtualMachine.list() mechanism is based on >>>>>>>>>>> Java processes that are up and running. >>>>>>>>>>> During VM startup when agent libraries are loaded, >>>>>>>>>>> the fact is recorded in the filesystem that a Java process >>>>>>>>>>> is eligible for an attach request. >>>>>>>>>>> >>>>>>>>>>> This is a much smaller list than scanning for all the >>>>>>>>>>> running processes and works across all supported >>>>>>>>>>> platforms. It also doesn't rely on fragile command line >>>>>>>>>>> parsing to determine a Java launcher is used. >>>>>>>>>>> >>>>>>>>>>> I believe most of the reported hang situations >>>>>>>>>>> are not for the first level information for pid and >>>>>>>>>>> command line requests. I believe the hangs are due >>>>>>>>>>> to the second level requests that actually attach >>>>>>>>>>> to the process and issue a command to the running >>>>>>>>>>> Java process. >>>>>>>>>>> >>>>>>>>>>> The overhead for the pid check should be relatively small. >>>>>>>>>>> In a standalone command for a one time check at startup >>>>>>>>>>> with 10's of Java processes. I know the documentation >>>>>>>>>>> states the user is responsible for verifying with jps >>>>>>>>>>> that a Java process pid or vmid is provided. But the cost >>>>>>>>>>> of human error can be a terminated process. >>>>>>>>>>> >>>>>>>>>>> Selection by name also has some drawbacks when multiple >>>>>>>>>>> copies of a command are running at the same time. >>>>>>>>>>> >>>>>>>>>>> Running "jcmd 0 ..." is the documented way to run a command on >>>>>>>>>>> all running Java processes. >>>>>>>>>>> >>>>>>>>>>> May I count you as a reviewer on the current changeset? >>>>>>>>>>> >>>>>>>>>>> On 2/15/19 3:54 AM, Thomas St?fe wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Feb 15, 2019 at 3:26 AM David Holmes >>>>>>>>>>>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Gary, >>>>>>>>>>>> >>>>>>>>>>>> What is the overhead of doing the validation? How do we >>>>>>>>>>>> list VMs? Do we >>>>>>>>>>>> need to examine every running process to get the list of >>>>>>>>>>>> VMs? Wouldn't >>>>>>>>>>>> it be better to check the given process is a VM rather >>>>>>>>>>>> than >>>>>>>>>>>> checking all >>>>>>>>>>>> potential VM processes? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think this is a valid point. Listing VMs is normally >>>>>>>>>>>> quick (just use jcmd without any parms) but I have seen >>>>>>>>>>>> this fail or hang rarely in situations where I then still >>>>>>>>>>>> was able to talk to my VM via pid. I never investigated >>>>>>>>>>>> this but I would not like to be unable to connect to my VM >>>>>>>>>>>> just because some rogue VM mailfunctions. >>>>>>>>>>>> >>>>>>>>>>>> This would be an argument for the alternative I offered in >>>>>>>>>>>> my first answer - just use the proc file system or a >>>>>>>>>>>> similar mechanism to check only the pid you plan on sending >>>>>>>>>>>> sigquit to... >>>>>>>>>>>> >>>>>>>>>>>> I think there is an onus of responsibility on the user to >>>>>>>>>>>> provide a >>>>>>>>>>>> correct pid here, rather than trying to make this >>>>>>>>>>>> foolproof. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Oh but it can happen quite easily. For example, by pulling >>>>>>>>>>>> up an older jcmd from your shell history and forgetting to >>>>>>>>>>>> modify the pid. Thank god for the command name argument >>>>>>>>>>>> option on jcmd, which I now use mostly. >>>>>>>>>>>> >>>>>>>>>>>> We also had a customer which tried to find all VMs on his >>>>>>>>>>>> machine by attempting to attach with jcmd to every process, >>>>>>>>>>>> killing them left and right :) >>>>>>>>>>>> >>>>>>>>>>>> ... Thomas >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 15/02/2019 5:12 am, Gary Adams wrote: >>>>>>>>>>>> > The following commands present a similar kill process >>>>>>>>>>>> behavior: >>>>>>>>>>>> > jcmd >>>>>>>>>>>> > jinfo >>>>>>>>>>>> > jmap >>>>>>>>>>>> > jstack >>>>>>>>>>>> > >>>>>>>>>>>> > The following commands do not attach. >>>>>>>>>>>> > jstat sun.jvmstat.monitor.MonitorException "not found" >>>>>>>>>>>> > jps no pid arguments >>>>>>>>>>>> > >>>>>>>>>>>> > This update moves the checkJavaPid method into the >>>>>>>>>>>> > common/ProcessArgumentsMatcher.java >>>>>>>>>>>> > and applies the check before the pid is used for an >>>>>>>>>>>> attach operation. >>>>>>>>>>>> > >>>>>>>>>>>> > Revised webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~gadams/8149461/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > On 2/14/19, 12:07 PM, Chris Plummer wrote: >>>>>>>>>>>> >> Hi Gary, >>>>>>>>>>>> >> >>>>>>>>>>>> >> What about the other tools that attach to a user >>>>>>>>>>>> specified process. Do >>>>>>>>>>>> >> they also have this issue? >>>>>>>>>>>> >> >>>>>>>>>>>> >> thanks, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Chris >>>>>>>>>>>> >> >>>>>>>>>>>> >> On 2/14/19 8:35 AM, Gary Adams wrote: >>>>>>>>>>>> >>> There is an old reported problem that using jmap on a >>>>>>>>>>>> process that is >>>>>>>>>>>> >>> not running >>>>>>>>>>>> >>> Java could cause the process to terminate. This is due >>>>>>>>>>>> to the SIGQUIT >>>>>>>>>>>> >>> used >>>>>>>>>>>> >>> when attaching to the process. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> It is a fairly simple operation to validate that the >>>>>>>>>>>> pid matches one >>>>>>>>>>>> >>> of the known >>>>>>>>>>>> >>> running Java processes using VirtualMachine.list(). >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Issue: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149461 >>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Proposed fix: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> diff --git >>>>>>>>>>>> a/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java >>>>>>>>>>>> >>> b/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java >>>>>>>>>>>> >>> --- a/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java >>>>>>>>>>>> >>> +++ b/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java >>>>>>>>>>>> >>> @@ -1,5 +1,5 @@ >>>>>>>>>>>> >>> /* >>>>>>>>>>>> >>> - * Copyright (c) 2005, 2018, Oracle and/or its >>>>>>>>>>>> affiliates. All >>>>>>>>>>>> >>> rights reserved. >>>>>>>>>>>> >>> + * Copyright (c) 2005, 2019, Oracle and/or its >>>>>>>>>>>> affiliates. All >>>>>>>>>>>> >>> rights reserved. >>>>>>>>>>>> >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS >>>>>>>>>>>> FILE HEADER. >>>>>>>>>>>> >>> * >>>>>>>>>>>> >>> * This code is free software; you can redistribute it >>>>>>>>>>>> and/or modify it >>>>>>>>>>>> >>> @@ -30,6 +30,7 @@ >>>>>>>>>>>> >>> import java.io.InputStream; >>>>>>>>>>>> >>> import java.io >>>>>>>>>>>> .UnsupportedEncodingException; >>>>>>>>>>>> >>> import java.util.Collection; >>>>>>>>>>>> >>> +import java.util.List; >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> import com.sun.tools.attach.VirtualMachine; >>>>>>>>>>>> >>> import com.sun.tools.attach.VirtualMachineDescriptor; >>>>>>>>>>>> >>> @@ -125,6 +126,10 @@ >>>>>>>>>>>> >>> private static void executeCommandForPid(String >>>>>>>>>>>> pid, String >>>>>>>>>>>> >>> command, Object ... args) >>>>>>>>>>>> >>> throws AttachNotSupportedException, IOException, >>>>>>>>>>>> >>> UnsupportedEncodingException { >>>>>>>>>>>> >>> + // Before attaching, confirm that pid is a >>>>>>>>>>>> known Java process >>>>>>>>>>>> >>> + if (!checkJavaPid(pid)) { >>>>>>>>>>>> >>> + throw new AttachNotSupportedException(); >>>>>>>>>>>> >>> + } >>>>>>>>>>>> >>> VirtualMachine vm = VirtualMachine.attach(pid); >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> // Cast to HotSpotVirtualMachine as this is an >>>>>>>>>>>> >>> @@ -196,6 +201,19 @@ >>>>>>>>>>>> >>> executeCommandForPid(pid, "dumpheap", filename, liveopt); >>>>>>>>>>>> >>> } >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> + // Check that pid matches a known running Java >>>>>>>>>>>> process >>>>>>>>>>>> >>> + static boolean checkJavaPid(String pid) { >>>>>>>>>>>> >>> + List l = >>>>>>>>>>>> VirtualMachine.list(); >>>>>>>>>>>> >>> + boolean found = false; >>>>>>>>>>>> >>> + for (VirtualMachineDescriptor vmd: l) { >>>>>>>>>>>> >>> + if (vmd.id ().equals(pid)) { >>>>>>>>>>>> >>> + found = true; >>>>>>>>>>>> >>> + break; >>>>>>>>>>>> >>> + } >>>>>>>>>>>> >>> + } >>>>>>>>>>>> >>> + return found; >>>>>>>>>>>> >>> + } >>>>>>>>>>>> >>> + >>>>>>>>>>>> >>> private static void >>>>>>>>>>>> checkForUnsupportedOptions(String[] args) { >>>>>>>>>>>> >>> // Check arguments for -F, -m, and non-numeric >>>>>>>>>>>> value >>>>>>>>>>>> >>> // and warn the user that SA is not supported >>>>>>>>>>>> anymore >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From daniil.x.titov at oracle.com Mon Mar 11 16:11:37 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 11 Mar 2019 09:11:37 -0700 Subject: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed In-Reply-To: <0f6330f7-aa7e-2281-0b9b-9e979e2ae9f9@oracle.com> References: <8A4D10EA-5BA7-45D6-A9D2-C743282BCC6E@oracle.com> <0f6330f7-aa7e-2281-0b9b-9e979e2ae9f9@oracle.com> Message-ID: <92D95DA8-21CB-4B68-8FA8-0D50349B9CBA@oracle.com> Hi David, Yes, the failure happened because Graal/JVMCI compiler threads were returned by allThreads() and sometimes a new Graal thread got squeezed between allThreads() calls. Best regards, Daniil ?On 3/11/19, 12:31 AM, "David Holmes" wrote: On 6/03/2019 7:59 am, Daniil Titov wrote: > Please review a fix for this test that intermittently fails with Graal on. > > The problem here is that the test does two consequent calls to VirtualMachine.allThreads() and checks that the number of threads returned by these calls is the same. With Graal on there is a chance that a new JVMCI compiler thread could be started between these calls that makes test to fail. The fix temporary suspends the debuggee VM while these two calls to VirtualMachine.allThreads() are made. Is this because Graal/JVMCI compiler threads are returned by allThreads() while regular compiler threads are not? Suspending the VM seems safest regardless. Thanks, David ----- > Webrev: http://cr.openjdk.java.net/~dtitov/8218464/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218464 > > Thanks! > --Daniil > > > From alexey.menkov at oracle.com Mon Mar 11 16:24:20 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 11 Mar 2019 09:24:20 -0700 Subject: RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed In-Reply-To: <245abec8-6e3a-6aab-0c91-f362e8221461@oracle.com> References: <5C826B3C.8030700@oracle.com> <245abec8-6e3a-6aab-0c91-f362e8221461@oracle.com> Message-ID: <9ac2aed2-c981-c184-b6b4-0f0e2d3f5e83@oracle.com> +1 --alex On 03/08/2019 08:58, Chris Plummer wrote: > Looks good. > > Chris > > On 3/8/19 5:16 AM, Gary Adams wrote: >> I've been able to reproduce the socket teardown failure in tc10x001. >> It appears that the debugee sends it's final output and then exits. >> If the debugee exits while the debugger is receiving the final output, >> it can result in a socket error. >> >> This proposed fix forces the debugee to wait until the debugger >> acknowledges it has processed the final output before exitting. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8013728/webrev.01/ >> >> The original bug was filed before these tests were in the open repos. >> >> None of the other tests in the nsk/jdi/BScenarios set have shown this >> problem, >> because they do not have an early debuggee exit sequence. > > > From gary.adams at oracle.com Mon Mar 11 16:50:51 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 11 Mar 2019 12:50:51 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out Message-ID: <5C8691EB.7080103@oracle.com> These attach tests interact with all running Java processes. From the logs of the failing tests you can see a few infrastructure Java processes and a number of other Java attaching tests including jinfo, jmap, jstat, etc. JDK-8220295: sun/tools/jps/TestJps.java still timing out JDK-8220242: com/sun/tools/attach/TempDirTest.java sometimes times out It's not clear what happens, if these processes are crossing their attach requests. To simplify the interactions, the following change will request the attaching tests to be run non-concurrently. Testing is in progress. If successful, it may be possible to reduce the timeout because a fixed number of Java processes will be running in each test run. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++ b/test/jdk/TEST.ROOT @@ -22,7 +22,7 @@ javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/tools/jps com/sun/tools sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi # Group definitions groups=TEST.groups -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Mar 11 18:49:34 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Mar 2019 11:49:34 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <5C8691EB.7080103@oracle.com> References: <5C8691EB.7080103@oracle.com> Message-ID: Have you been able to reliably reproduce either of these issues? Chris On 3/11/19 9:50 AM, Gary Adams wrote: > These attach tests interact with all running Java processes. > From the logs of the failing tests you can see a few infrastructure > Java processes and a number of other Java attaching tests including > jinfo, jmap, jstat, etc. > > ? JDK-8220295: sun/tools/jps/TestJps.java still timing out > ? JDK-8220242: com/sun/tools/attach/TempDirTest.java sometimes times out > > It's not clear what happens, if these processes are crossing their > attach requests. To simplify the interactions, the following change > will request the attaching tests to be run non-concurrently. > Testing is in progress. If successful, it may be possible to reduce the > timeout because a fixed number of Java processes will be running in each > test run. > > diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT > +++ b/test/jdk/TEST.ROOT > @@ -22,7 +22,7 @@ > ?javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation > java/lang/ProcessHandle > > ?# Tests that cannot run concurrently > -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs > sun/management/jmxremote sun/tools/jstatd sun/security/mscapi > java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream > javax/rmi > +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs > sun/management/jmxremote sun/tools/jstatd sun/tools/jps com/sun/tools > sun/security/mscapi java/util/stream java/util/Arrays/largeMemory > java/util/BitSet/stream javax/rmi > ?# Group definitions > ?groups=TEST.groups From gary.adams at oracle.com Mon Mar 11 19:07:19 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Mon, 11 Mar 2019 15:07:19 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <5C8691EB.7080103@oracle.com> Message-ID: Neither of these tests has been reproduced under controlled conditions. On recent test runs, I've been more likely to see a jstat or jstatd test failing. On 3/11/19 2:49 PM, Chris Plummer wrote: > Have you been able to reliably reproduce either of these issues? > > Chris > > On 3/11/19 9:50 AM, Gary Adams wrote: >> These attach tests interact with all running Java processes. >> From the logs of the failing tests you can see a few infrastructure >> Java processes and a number of other Java attaching tests including >> jinfo, jmap, jstat, etc. >> >> ? JDK-8220295: sun/tools/jps/TestJps.java still timing out >> ? JDK-8220242: com/sun/tools/attach/TempDirTest.java sometimes times out >> >> It's not clear what happens, if these processes are crossing their >> attach requests. To simplify the interactions, the following change >> will request the attaching tests to be run non-concurrently. >> Testing is in progress. If successful, it may be possible to reduce the >> timeout because a fixed number of Java processes will be running in each >> test run. >> >> diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT >> --- a/test/jdk/TEST.ROOT >> +++ b/test/jdk/TEST.ROOT >> @@ -22,7 +22,7 @@ >> ?javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation >> java/lang/ProcessHandle >> >> ?# Tests that cannot run concurrently >> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi >> java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream >> javax/rmi >> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >> sun/management/jmxremote sun/tools/jstatd sun/tools/jps com/sun/tools >> sun/security/mscapi java/util/stream java/util/Arrays/largeMemory >> java/util/BitSet/stream javax/rmi >> ?# Group definitions >> ?groups=TEST.groups > > > From chris.plummer at oracle.com Mon Mar 11 19:14:48 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Mar 2019 12:14:48 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <5C8691EB.7080103@oracle.com> Message-ID: Maybe try a custom testlist that just runs these two tests. Chris On 3/11/19 12:07 PM, gary.adams at oracle.com wrote: > Neither of these tests has been reproduced under controlled conditions. > On recent test runs, I've been more likely to see a jstat or jstatd > test failing. > > On 3/11/19 2:49 PM, Chris Plummer wrote: >> Have you been able to reliably reproduce either of these issues? >> >> Chris >> >> On 3/11/19 9:50 AM, Gary Adams wrote: >>> These attach tests interact with all running Java processes. >>> From the logs of the failing tests you can see a few infrastructure >>> Java processes and a number of other Java attaching tests including >>> jinfo, jmap, jstat, etc. >>> >>> ? JDK-8220295: sun/tools/jps/TestJps.java still timing out >>> ? JDK-8220242: com/sun/tools/attach/TempDirTest.java sometimes times >>> out >>> >>> It's not clear what happens, if these processes are crossing their >>> attach requests. To simplify the interactions, the following change >>> will request the attaching tests to be run non-concurrently. >>> Testing is in progress. If successful, it may be possible to reduce the >>> timeout because a fixed number of Java processes will be running in >>> each >>> test run. >>> >>> diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT >>> --- a/test/jdk/TEST.ROOT >>> +++ b/test/jdk/TEST.ROOT >>> @@ -22,7 +22,7 @@ >>> ?javax/management sun/awt sun/java2d >>> javax/xml/jaxp/testng/validation java/lang/ProcessHandle >>> >>> ?# Tests that cannot run concurrently >>> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi >>> java/util/stream java/util/Arrays/largeMemory >>> java/util/BitSet/stream javax/rmi >>> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>> sun/management/jmxremote sun/tools/jstatd sun/tools/jps >>> com/sun/tools sun/security/mscapi java/util/stream >>> java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi >>> ?# Group definitions >>> ?groups=TEST.groups >> >> >> > From daniil.x.titov at oracle.com Mon Mar 11 23:32:25 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 11 Mar 2019 16:32:25 -0700 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: Hi Dean, JC and Daniel, Thank you for reviewing this change. Based on the overall output it seems as the common consensus is that the broader discussions is required to decide what would be a proper way to optionally hide/mute JVMCI compiler threads (and probably some other ?system? Java threads) from JVMTI clients. Thus, my suggestion is to move this discussion in a new enhancement [3] and limit the current issue just to the fixing the test itself. Please review a new version of the webrev that adds JVMCI compiler and "HotSpotGraalManagement Bean Registration" threads to the list of the threads the tests must ignore. Reference: -------------- [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 Thanks, Daniil From: Organization: Oracle Corporation Date: Thursday, March 7, 2019 at 12:19 PM To: Daniil Titov , OpenJDK Serviceability Subject: Re: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed There are other places where is_hidden_from_external_view() is used.? Should is_hidden_from_external_view() also check the new capability?? If so, then you can simplify your changes.? I'm not sure the new capability is the best choice, however.? There is still no way to control whether compiler threads can post events, hit breakpoints, single-step, etc.? And "compiler thread" might be too specific.? There might be other types of "system thread" that we want to ignore.? Since this is a JVMTI spec change, I think it deserves more discussion.? For example, an alternative would be a way to set "can debug"/"visible"/"can post events"/etc flags on individual threads. dl On 3/7/19 9:54 AM, Daniil Titov wrote: Please review a change that fixes this test. ? The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. ? The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. ? Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 ? Mach5 tier1, tier2 and tier3 tests successfully passed with this change. ? Thanks! -Daniil ? From david.holmes at oracle.com Mon Mar 11 23:51:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2019 09:51:33 +1000 Subject: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied In-Reply-To: <80aebf96ee8b40419bb44c5a0f1c34cd@jd.com> References: <80aebf96ee8b40419bb44c5a0f1c34cd@jd.com> Message-ID: On 8/03/2019 3:32 pm, ?? wrote: > Thanks all for reviewing it. I think it could be pushed now, right? Yes.I'll sponsor this for you seeing as noone else stepped up. David > BRs, > Lin > ________________________________________ > From: Thomas St?fe > Sent: Thursday, March 7, 2019 3:39:05 PM > To: ?? > Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > Subject: Re: RFR:8219721: jcmd from earlier release will hang attaching to VM with JDK-8215622 applied > > Neat! Both directions are fixed now: I can connect with new jcmd to old VMs and vice versa. Thanks a lot! > > ..Thomas > > On Mon, Mar 4, 2019 at 10:14 AM ?? > wrote: > Dear All, > May I ask your help to review the fix of compatibility issue introduced by JDK-8215622 > webrev: http://cr.openjdk.java.net/~xiaofeya/8219721/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8219721 > > FYI, this webrev is forked from the discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html. > > Thanks, > Lin > From jcbeyler at google.com Tue Mar 12 00:43:27 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 11 Mar 2019 17:43:27 -0700 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: Hi Daniil, Looks good to me :) Thanks, Jc On Mon, Mar 11, 2019 at 4:32 PM Daniil Titov wrote: > Hi Dean, JC and Daniel, > > Thank you for reviewing this change. Based on the overall output it seems > as the common consensus is that the broader discussions is required to > decide what would be a proper way to optionally hide/mute JVMCI compiler > threads (and probably some other ?system? Java threads) from JVMTI > clients. Thus, my suggestion is to move this discussion in a new > enhancement [3] and limit the current issue just to the fixing the test > itself. > > Please review a new version of the webrev that adds JVMCI compiler and > "HotSpotGraalManagement Bean Registration" threads to the list of the > threads the tests must ignore. > > > Reference: > -------------- > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 > > Thanks, > Daniil > > From: > Organization: Oracle Corporation > Date: Thursday, March 7, 2019 at 12:19 PM > To: Daniil Titov , OpenJDK Serviceability < > serviceability-dev at openjdk.java.net> > Subject: Re: RFR: 8218812: > vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed > > There are other places where is_hidden_from_external_view() is used. > Should is_hidden_from_external_view() also check the new capability? If > so, then you can simplify your changes. I'm not sure the new capability is > the best choice, however. There is still no way to control whether > compiler threads can post events, hit breakpoints, single-step, etc. And > "compiler thread" might be too specific. There might be other types of > "system thread" that we want to ignore. Since this is a JVMTI spec change, > I think it deserves more discussion. For example, an alternative would be > a way to set "can debug"/"visible"/"can post events"/etc flags on > individual threads. > > dl > On 3/7/19 9:54 AM, Daniil Titov wrote: > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and with > Graal on additional threads the test doesn't expect are started and cause > the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that > affects whether Java compiler threads are retuned with JVMTI GetAllThreads > call. By default this capability is off. The fix also adds " > HotSpotGraalManagement Bean Registration" thread to the list of the threads > the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > -Daniil > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Tue Mar 12 04:22:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 11 Mar 2019 21:22:21 -0700 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: <4d2407d4-7d51-e1b9-6adb-f7d3242137c7@oracle.com> This is consistent with how other system threads are handled, so it looks good to me. dl On 3/11/19 4:32 PM, Daniil Titov wrote: > Hi Dean, JC and Daniel, > > Thank you for reviewing this change. Based on the overall output it seems as the common consensus is that the broader discussions is required to decide what would be a proper way to optionally hide/mute JVMCI compiler threads (and probably some other ?system? Java threads) from JVMTI clients. Thus, my suggestion is to move this discussion in a new enhancement [3] and limit the current issue just to the fixing the test itself. > > Please review a new version of the webrev that adds JVMCI compiler and "HotSpotGraalManagement Bean Registration" threads to the list of the threads the tests must ignore. > > > Reference: > -------------- > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 > > Thanks, > Daniil > > From: > Organization: Oracle Corporation > Date: Thursday, March 7, 2019 at 12:19 PM > To: Daniil Titov , OpenJDK Serviceability > Subject: Re: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed > > There are other places where is_hidden_from_external_view() is used.? Should is_hidden_from_external_view() also check the new capability?? If so, then you can simplify your changes.? I'm not sure the new capability is the best choice, however.? There is still no way to control whether compiler threads can post events, hit breakpoints, single-step, etc.? And "compiler thread" might be too specific.? There might be other types of "system thread" that we want to ignore.? Since this is a JVMTI spec change, I think it deserves more discussion.? For example, an alternative would be a way to set "can debug"/"visible"/"can post events"/etc flags on individual threads. > > dl > On 3/7/19 9:54 AM, Daniil Titov wrote: > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > -Daniil > > > > > From gary.adams at oracle.com Tue Mar 12 11:54:44 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Mar 2019 07:54:44 -0400 Subject: RFR: JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java Message-ID: <5C879E04.9090309@oracle.com> Need one reviewer for this trivial correction . Issue: https://bugs.openjdk.java.net/browse/JDK-8220474 diff --git a/src/java.instrument/share/classes/java/lang/instrument/package-info.java b/src/java.instrument/share/classes/java/lang/instrument/package-info.java --- a/src/java.instrument/share/classes/java/lang/instrument/package-info.java +++ b/src/java.instrument/share/classes/java/lang/instrument/package-info.java @@ -1,11 +1,11 @@ /* - * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this - * particular file as subject to the Classpath exception as provided + * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT From david.holmes at oracle.com Tue Mar 12 12:32:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2019 22:32:52 +1000 Subject: RFR: JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java In-Reply-To: <5C879E04.9090309@oracle.com> References: <5C879E04.9090309@oracle.com> Message-ID: Ship it! Thanks, David On 12/03/2019 9:54 pm, Gary Adams wrote: > Need one reviewer for this trivial correction . > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8220474 > > diff --git > a/src/java.instrument/share/classes/java/lang/instrument/package-info.java > b/src/java.instrument/share/classes/java/lang/instrument/package-info.java > --- > a/src/java.instrument/share/classes/java/lang/instrument/package-info.java > +++ > b/src/java.instrument/share/classes/java/lang/instrument/package-info.java > @@ -1,11 +1,11 @@ > ?/* > - * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > ? * under the terms of the GNU General Public License version 2 only, as > ? * published by the Free Software Foundation.? Oracle designates this > - * particular file as subject to the Classpath exception as provided > + * particular file as subject to the "Classpath" exception as provided > ? * by Oracle in the LICENSE file that accompanied this code. > ? * > ? * This code is distributed in the hope that it will be useful, but > WITHOUT From david.holmes at oracle.com Tue Mar 12 12:38:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2019 22:38:34 +1000 Subject: RFR: JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java In-Reply-To: References: <5C879E04.9090309@oracle.com> Message-ID: <574c87e2-d8e1-a443-674c-859e8a36e6ff@oracle.com> Hold on! Sorry ... On 12/03/2019 10:32 pm, David Holmes wrote: > Ship it! > > Thanks, > David > > On 12/03/2019 9:54 pm, Gary Adams wrote: >> Need one reviewer for this trivial correction . >> >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8220474 >> >> diff --git >> a/src/java.instrument/share/classes/java/lang/instrument/package-info.java >> b/src/java.instrument/share/classes/java/lang/instrument/package-info.java >> >> --- >> a/src/java.instrument/share/classes/java/lang/instrument/package-info.java >> >> +++ >> b/src/java.instrument/share/classes/java/lang/instrument/package-info.java >> >> @@ -1,11 +1,11 @@ >> ??/* >> - * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights >> reserved. The copyright year should not be updated if only the copyright notice has been modified. David ----- >> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ?? * >> ?? * This code is free software; you can redistribute it and/or modify it >> ?? * under the terms of the GNU General Public License version 2 only, as >> ?? * published by the Free Software Foundation.? Oracle designates this >> - * particular file as subject to the Classpath exception as provided >> + * particular file as subject to the "Classpath" exception as provided >> ?? * by Oracle in the LICENSE file that accompanied this code. >> ?? * >> ?? * This code is distributed in the hope that it will be useful, but >> WITHOUT From gary.adams at oracle.com Tue Mar 12 14:24:15 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Mar 2019 10:24:15 -0400 Subject: RFR: JDK-8220257: fix headings in java.instrument Message-ID: <5C87C10F.8080004@oracle.com> Need one reviewer for this trivial correction . After pushing the GPL header update, the h3 to h2 tags will be updated. The copyright will be changed with the headings, so I'll push that change first. JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java diff --git a/src/java.instrument/share/classes/java/lang/instrument/package-info.java b/src/java.instrument/share/classes/java/lang/instrument/package-info.java --- a/src/java.instrument/share/classes/java/lang/instrument/package-info.java +++ b/src/java.instrument/share/classes/java/lang/instrument/package-info.java @@ -1,11 +1,11 @@ /* - * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. Oracle designates this - * particular file as subject to the Classpath exception as provided + * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT @@ -52,7 +52,7 @@ *

Each of these ways to start an agent is described below. * * - *

Starting an Agent from the Command-Line Interface

+ *

Starting an Agent from the Command-Line Interface

* *

Where an implementation provides a means to start agents from the * command-line interface, an agent is started by adding the following option @@ -113,7 +113,7 @@ * threads, is legal from {@code premain}. * * - *

Starting an Agent After VM Startup

+ *

Starting an Agent After VM Startup

* *

An implementation may provide a mechanism to start agents sometime after * the the VM has started. The details as to how this is initiated are @@ -164,7 +164,7 @@ * by the JVM for troubleshooting purposes). * * - *

Including an Agent in an Executable JAR file

+ *

Including an Agent in an Executable JAR file

* *

The JAR File Specification defines manifest attributes for standalone * applications that are packaged as executable JAR files. If an @@ -194,8 +194,8 @@ * an uncaught exception or error, the JVM will abort. * * - *

Loading agent classes and the modules/classes available to the agent - * class

+ *

Loading agent classes and the modules/classes available to the agent + * class

* *

Classes loaded from the agent JAR file are loaded by the * {@linkplain ClassLoader#getSystemClassLoader() system class loader} and are @@ -242,7 +242,7 @@ * In other words, a custom system class loader must support the mechanism to * add an agent JAR file to the system class loader search. * - *

Manifest Attributes

+ *

Manifest Attributes

* *

The following manifest attributes are defined for an agent JAR file: * @@ -311,7 +311,7 @@ * ignored). * * - *

Instrumenting code in modules

+ *

Instrumenting code in modules

* *

As an aid to agents that deploy supporting classes on the search path of * the bootstrap class loader, or the search path of the class loader that loads @@ -323,4 +323,4 @@ * @revised 9 */ From daniel.fuchs at oracle.com Tue Mar 12 14:51:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 14:51:49 +0000 Subject: RFR: JDK-8220257: fix headings in java.instrument In-Reply-To: <5C87C10F.8080004@oracle.com> References: <5C87C10F.8080004@oracle.com> Message-ID: <0ff37bf8-d787-e2f3-71d4-2bab231427c1@oracle.com> On 12/03/2019 14:24, Gary Adams wrote: > Need one reviewer for this trivial correction . Having had to do the same for java.logging, I can say that the doc changes to package-info.java look good to me :-) AFAICT the changes to the copyright notice look OK too. best regards, -- daniel > > After pushing the GPL header update, the h3 to h2 tags will be updated. > The copyright will be changed with the headings, so I'll push that > change first. > ? JDK-8220474: Incorrect GPL header in > src/java.instrument/share/classes/java/lang/instrument/package-info.java > > diff --git > a/src/java.instrument/share/classes/java/lang/instrument/package-info.java > b/src/java.instrument/share/classes/java/lang/instrument/package-info.java > --- > a/src/java.instrument/share/classes/java/lang/instrument/package-info.java > +++ > b/src/java.instrument/share/classes/java/lang/instrument/package-info.java > @@ -1,11 +1,11 @@ > ?/* > - * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > ? * under the terms of the GNU General Public License version 2 only, as > ? * published by the Free Software Foundation.? Oracle designates this > - * particular file as subject to the Classpath exception as provided > + * particular file as subject to the "Classpath" exception as provided > ? * by Oracle in the LICENSE file that accompanied this code. > ? * > ? * This code is distributed in the hope that it will be useful, but > WITHOUT > @@ -52,7 +52,7 @@ > ? *

Each of these ways to start an agent is described below. > ? * > ? * > - *

Starting an Agent from the Command-Line Interface

> + *

Starting an Agent from the Command-Line Interface

> ? * > ? *

Where an implementation provides a means to start agents from the > ? * command-line interface, an agent is started by adding the following > option > @@ -113,7 +113,7 @@ > ? * threads, is legal from {@code premain}. > ? * > ? * > - *

Starting an Agent After VM Startup

> + *

Starting an Agent After VM Startup

> ? * > ? *

An implementation may provide a mechanism to start agents > sometime after > ? * the the VM has started. The details as to how this is initiated are > @@ -164,7 +164,7 @@ > ? * by the JVM for troubleshooting purposes). > ? * > ? * > - *

Including an Agent in an Executable JAR file

> + *

Including an Agent in an Executable JAR file

> ? * > ? *

The JAR File Specification defines manifest attributes for > standalone > ? * applications that are packaged as executable JAR files. If an > @@ -194,8 +194,8 @@ > ? * an uncaught exception or error, the JVM will abort. > ? * > ? * > - *

Loading agent classes and the modules/classes available to the > agent > - * class

> + *

Loading agent classes and the modules/classes available to the > agent > + * class

> ? * > ? *

Classes loaded from the agent JAR file are loaded by the > ? * {@linkplain ClassLoader#getSystemClassLoader() system class loader} > and are > @@ -242,7 +242,7 @@ > ? * In other words, a custom system class loader must support the > mechanism to > ? * add an agent JAR file to the system class loader search. > ? * > - *

Manifest Attributes

> + *

Manifest Attributes

> ? * > ? *

The following manifest attributes are defined for an agent JAR > file: > ? * > @@ -311,7 +311,7 @@ > ? * ignored). > ? * > ? * > - *

Instrumenting code in modules

> + *

Instrumenting code in modules

> ? * > ? *

As an aid to agents that deploy supporting classes on the > search path of > ? * the bootstrap class loader, or the search path of the class loader > that loads > @@ -323,4 +323,4 @@ > ? * @revised 9 > ? */ From stefan.karlsson at oracle.com Tue Mar 12 15:19:48 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Mar 2019 16:19:48 +0100 Subject: RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots Message-ID: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> Hi all, Please review and/or comment on this change to remove CodeCache::scavenge_root_nmehods_do from VM_HeapWalkOperation::collect_simple_roots. http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220342 VM_HeapWalkOperation::collect_simple_roots is used to implement the following JVMTI functionality: IterateOverReachableObjects IterateOverObjectsReachableFromObject FollowReferences From: https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#FollowReferences "This function initiates a traversal over the objects that are directly and indirectly reachable from the specified object or, if initial_object is not specified, all objects reachable from the heap roots. The heap root are the set of system classes, JNI globals, references from thread stacks, and other objects used as roots for the purposes of garbage collection." The set of roots in collect_simple_roots matches this, and mostly visits the set of roots that one of our class unloading enabled GCs would visit. There are some roots missing. For example: Management::oops_do JvmtiExport::oops_do AOTLoader::oops_do And there's one set of roots that is present in collect_simple_roots, that is not visited by our unloading GCs: CodeCache::scavenge_root_nmethods_do As an example, in PSMarkSweep we have the following comment in the root scanning code: // Do not treat nmethods as strong roots for mark/sweep, since we can unload them. //CodeCache::scavenge_root_nmethods_do(...); The CodeCache::scavenge_root_nmethods_do is only used by Serial, Parallel, and CMS, to scan pointers into young gen. Other GCs don't use it at all, and if we run with G1 this call does nothing at all. CodeCache::scavenge_root_nmethods_do is an GC implementation detail that I want to confine with the following RFE: https://bugs.openjdk.java.net/browse/JDK-8220343 "Move scavenge_root_nmethods from shared code" and this is the only external usage of it. Note also that the only effect of this code is that it adds a set of roots that point into the young gen, but only for some of our GCs. There are other roots that also point into the young gen that we don't visit. For example, the non-system classes. See how collect_simple_roots use ClassLoaderDataGraph::always_strong_cld_do instead of ClassLoaderDataGraph::cld_do. I've run through tier1-7 with this removal, without any problems. I'd be interested in hearing if others have a justification for having this code in collect_simple_roots. Or a test-case showing why this is needed. There has been some brief, internal discussions that maybe we want to visit all sets of roots in the vm, both strong and weak. A quick implementation of that causes problem in testing when objects tagged by JVMTI, and JNI weak global handles, gets reported as roots. Because of that, such change requires more investigation and work than simply extending the set of roots. However, if one were to go that route the above call to CodeCache::scavenge_root_nmethods_do would be replaced with CodeCache::blobs_do, the function used when we turn off class unloading and use our weak roots as strong roots. As an example, see GenCollectedHeap::process_roots: // CMSCollector uses this to do intermediate-strength collections. // We scan the entire code cache, since CodeCache::do_unloading is not called. CodeCache::blobs_do(code_roots); Thanks, StefanK From gary.adams at oracle.com Tue Mar 12 18:07:17 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Mar 2019 14:07:17 -0400 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: References: <5C811A51.5080005@oracle.com> Message-ID: <5C87F555.2030802@oracle.com> Still need 2 more reviewers ... On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: > Gary, > > Since the 'graal' label was recently removed, I also removed "[Graal]" > from the bug synopsis. Please make sure you update your commit mesg. > > > On 3/7/19 8:19 AM, Gary Adams wrote: >> While trying to reproduce the timeout reported in >> JDK-8000669: com/sun/jdi/SimulResumerTest.java times out >> >> I was unable to reproduce the timeout failure, but I did occasionally >> see the ObjectCollectedException. The output from the test is very >> verbose >> and may be the source of the occasional timeout. I'd like to close >> JDK-8000669 >> as cannot reproduce and if it shows up again look into limiting the >> amount >> of non-essential output from the test. >> >> This is a racy test to begin with and it already is ignoring exceptions >> due to unexpected thread states. Adding the ignore for >> ObjectCollectedException >> allows the test to complete without errors. >> >> The graal label was recently removed. We should also remove it from >> the summary. >> >> Proposed changeset: >> >> >> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java >> b/test/jdk/com/sun/jdi/SimulResumerTest.java >> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java >> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -211,6 +211,8 @@ >> >> } catch (IncompatibleThreadStateException ee) { >> // ignore >> + } catch (ObjectCollectedException ee) { >> + // ignore >> } catch (VMDisconnectedException ee) { >> // This is how we stop. The debuggee runs to >> completion >> // and we get this exception. > > There should be some sort of comment explaining why it is okay to ignore > the ObjectCollectedException. When the IncompatibleThreadStateException > was ignored, there should have been a comment added for that also. > > Dan > From daniel.fuchs at oracle.com Tue Mar 12 18:22:41 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Mar 2019 18:22:41 +0000 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <9918ce41ca8bc666a1d8ab10c6d902ac728c16d4.camel@redhat.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> <9918ce41ca8bc666a1d8ab10c6d902ac728c16d4.camel@redhat.com> Message-ID: <8892ed60-e56b-cece-4c40-c6c5347fc6c9@oracle.com> Hi Severin, On 08/03/2019 13:20, Severin Gehwolf wrote: > On Fri, 2019-03-08 at 11:59 +0000, Daniel Fuchs wrote: >> - please verify on your local box if testing both plain & >> SSL with a Thread.sleep(1000) in between makes the test >> more stable. If it does, then I'd prefer we go down >> this road rather than selecting one plain vs SSL at random. > > I've tested this before. With a sleep of 1 or 2 seconds. It didn't work > reliably for me (it might have been a fastdebug JVM). fastdebug VM (sigh!) - that's a config I hadn't tested. see below... > Eventually, the > SSL version of the test would fail. Yet, the latest version of the > webrev used different sets of ports for SSL and plain so that led me to > believe it's not related to a port clash. So Thread.sleep() wouldn't > help. Good point. > Have you tried without the sleep at all and running both plain > and SSL in your test system? Yes. As in your webrev.04 below - Works fine with regular VM. > This is what I have tried: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/ > > If you think we should try this one. That's fine with me. I have now also tested webrev.04 with a test config that uses the fastdebug VM and observed many intermittent failures. The logs let me think that maybe the JMX agent needed to be given more time to come up: So I am now experimenting with your webrev.04 above - but with the following additional change to JMXAgentInterfaceBinding.java: private static final int WAIT_FOR_JMX_AGENT_TIMEOUT_MS = 20000; So far the result are looking better, but tests are still running. I wonder whether the same change would also reduce the number of intermittent failures on your box? best regards, -- daniel > > Thanks, > Severin > From daniil.x.titov at oracle.com Tue Mar 12 18:22:10 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 12 Mar 2019 11:22:10 -0700 Subject: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <3FA57971-E051-47FD-9520-464DE515A5ED@oracle.com> References: <5C811A51.5080005@oracle.com> <3FA57971-E051-47FD-9520-464DE515A5ED@oracle.com> Message-ID: Hi Gary, The fix looks good. However, since there are only two references (debuggeeThread1 and debuggeeThread2) the test checks, an alternative to catching and ignoring ObjectCollectedException could be just calling disableCollection() on these two thread references when a breakpoint handle is called (lines 130 and 135). Thanks! Best regards, Daniil ?On 3/12/19, 11:05 AM, "serviceability-dev on behalf of Gary Adams" wrote: Still need 2 more reviewers ... On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: > Gary, > > Since the 'graal' label was recently removed, I also removed "[Graal]" > from the bug synopsis. Please make sure you update your commit mesg. > > > On 3/7/19 8:19 AM, Gary Adams wrote: >> While trying to reproduce the timeout reported in >> JDK-8000669: com/sun/jdi/SimulResumerTest.java times out >> >> I was unable to reproduce the timeout failure, but I did occasionally >> see the ObjectCollectedException. The output from the test is very >> verbose >> and may be the source of the occasional timeout. I'd like to close >> JDK-8000669 >> as cannot reproduce and if it shows up again look into limiting the >> amount >> of non-essential output from the test. >> >> This is a racy test to begin with and it already is ignoring exceptions >> due to unexpected thread states. Adding the ignore for >> ObjectCollectedException >> allows the test to complete without errors. >> >> The graal label was recently removed. We should also remove it from >> the summary. >> >> Proposed changeset: >> >> >> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java >> b/test/jdk/com/sun/jdi/SimulResumerTest.java >> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java >> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -211,6 +211,8 @@ >> >> } catch (IncompatibleThreadStateException ee) { >> // ignore >> + } catch (ObjectCollectedException ee) { >> + // ignore >> } catch (VMDisconnectedException ee) { >> // This is how we stop. The debuggee runs to >> completion >> // and we get this exception. > > There should be some sort of comment explaining why it is okay to ignore > the ObjectCollectedException. When the IncompatibleThreadStateException > was ignored, there should have been a comment added for that also. > > Dan > From dean.long at oracle.com Tue Mar 12 20:43:16 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 12 Mar 2019 13:43:16 -0700 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C87F555.2030802@oracle.com> References: <5C811A51.5080005@oracle.com> <5C87F555.2030802@oracle.com> Message-ID: Looks good to me. dl On 3/12/19 11:07 AM, Gary Adams wrote: > Still need 2 more reviewers ... > > On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: >> Gary, >> >> Since the 'graal' label was recently removed, I also removed "[Graal]" >> from the bug synopsis. Please make sure you update your commit mesg. >> >> >> On 3/7/19 8:19 AM, Gary Adams wrote: >>> While trying to reproduce the timeout reported in >>> ? JDK-8000669: com/sun/jdi/SimulResumerTest.java times out >>> >>> I was unable to reproduce the timeout failure, but I did occasionally >>> see the ObjectCollectedException. The output from the test is very >>> verbose >>> and may be the source of the occasional timeout. I'd like to close >>> JDK-8000669 >>> as cannot reproduce and if it shows up again look into limiting the >>> amount >>> of non-essential output from the test. >>> >>> This is a racy test to begin with and it already is ignoring exceptions >>> due to unexpected thread states. Adding the ignore for >>> ObjectCollectedException >>> allows the test to complete without errors. >>> >>> The graal label was recently removed. We should also remove it from >>> the summary. >>> >>> Proposed changeset: >>> >>> >>> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java >>> b/test/jdk/com/sun/jdi/SimulResumerTest.java >>> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java >>> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java >>> @@ -1,5 +1,5 @@ >>> ?/* >>> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ? * >>> ? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -211,6 +211,8 @@ >>> >>> ???????????? } catch (IncompatibleThreadStateException ee) { >>> ???????????????? // ignore >>> +??????????? } catch (ObjectCollectedException ee) { >>> +??????????????? // ignore >>> ???????????? } catch (VMDisconnectedException ee) { >>> ???????????????? // This is how we stop.? The debuggee runs to >>> completion >>> ???????????????? // and we get this exception. >> >> There should be some sort of comment explaining why it is okay to ignore >> the ObjectCollectedException. When the IncompatibleThreadStateException >> was ignored, there should have been a comment added for that also. >> >> Dan >> > From serguei.spitsyn at oracle.com Tue Mar 12 21:50:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Mar 2019 14:50:05 -0700 Subject: RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots In-Reply-To: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> References: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> Message-ID: Hi Stefan, The fix looks good to me. Testing the tiers 1-7 for different GC's has to be good enough. Thanks, Serguei On 3/12/19 8:19 AM, Stefan Karlsson wrote: > Hi all, > > Please review and/or comment on this change to remove > CodeCache::scavenge_root_nmehods_do from > VM_HeapWalkOperation::collect_simple_roots. > > http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8220342 > > VM_HeapWalkOperation::collect_simple_roots is used to implement the > following JVMTI functionality: > ?IterateOverReachableObjects > ?IterateOverObjectsReachableFromObject > ?FollowReferences > > From: > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#FollowReferences > > > "This function initiates a traversal over the objects that are > directly and indirectly reachable from the specified object or, if > initial_object is not specified, all objects reachable from the heap > roots. The heap root are the set of system classes, JNI globals, > references from thread stacks, and other objects used as roots for the > purposes of garbage collection." > > The set of roots in collect_simple_roots matches this, and mostly > visits the set of roots that one of our class unloading enabled GCs > would visit. > > There are some roots missing. For example: > ?Management::oops_do > ?JvmtiExport::oops_do > ?AOTLoader::oops_do > > And there's one set of roots that is present in collect_simple_roots, > that is not visited by our unloading GCs: > ?CodeCache::scavenge_root_nmethods_do > > As an example, in PSMarkSweep we have the following comment in the > root scanning code: > ? // Do not treat nmethods as strong roots for mark/sweep, since we > can unload them. > ? //CodeCache::scavenge_root_nmethods_do(...); > > The CodeCache::scavenge_root_nmethods_do is only used by Serial, > Parallel, and CMS, to scan pointers into young gen. Other GCs don't > use it at all, and if we run with G1 this call does nothing at all. > > CodeCache::scavenge_root_nmethods_do is an GC implementation detail > that I want to confine with the following RFE: > ?https://bugs.openjdk.java.net/browse/JDK-8220343 > ?"Move scavenge_root_nmethods from shared code" > > and this is the only external usage of it. > > Note also that the only effect of this code is that it adds a set of > roots that point into the young gen, but only for some of our GCs. > There are other roots that also point into the young gen that we don't > visit. For example, the non-system classes. See how > collect_simple_roots use ClassLoaderDataGraph::always_strong_cld_do > instead of ClassLoaderDataGraph::cld_do. > > I've run through tier1-7 with this removal, without any problems. > > I'd be interested in hearing if others have a justification for having > this code in collect_simple_roots. Or a test-case showing why this is > needed. > > There has been some brief, internal discussions that maybe we want to > visit all sets of roots in the vm, both strong and weak. A quick > implementation of that causes problem in testing when objects tagged > by JVMTI, and JNI weak global handles, gets reported as roots. Because > of that, such change requires more investigation and work than simply > extending the set of roots. However, if one were to go that route the > above call to CodeCache::scavenge_root_nmethods_do would be replaced > with CodeCache::blobs_do, the function used when we turn off class > unloading and use our weak roots as strong roots. As an example, see > GenCollectedHeap::process_roots: > > ????? // CMSCollector uses this to do intermediate-strength collections. > ????? // We scan the entire code cache, since CodeCache::do_unloading > is not called. > ????? CodeCache::blobs_do(code_roots); > > Thanks, > StefanK From coleen.phillimore at oracle.com Tue Mar 12 22:07:10 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 12 Mar 2019 18:07:10 -0400 Subject: [11] [12] RFR 8210457: JVM crash in ResolvedMethodTable::add_method(Handle) Message-ID: <72a11bd5-163a-5348-8e53-c745b2e4b20a@oracle.com> Summary: Add a function to call NSME in ResolvedMethodTable to replace deleted methods. Please review a backport of this bug to JDK 11 and 12.? The JDK 12 backport required some manual merging in ResolvedMethodTable::adjust_method_entries to account for some preceding cleanup in the original.? The JDK 11 backport patched cleanly from the 12 backport except for the copyright on Unsafe.java. The JDK 13 patch: http://hg.openjdk.java.net/jdk/jdk/rev/09cba396916f JDK 12 webrev: http://cr.openjdk.java.net/~coleenp/2019/8210457.01.12/webrev JDK 11 webrev: http://cr.openjdk.java.net/~coleenp/2019/8210457.01.11/webrev I only have approval for JDK 11 at the moment. These patches passed mach5 tier1 and 2, and the jvmti and java/lang/instrument redefinition jtreg tests. Thanks, Coleen From jcbeyler at google.com Tue Mar 12 22:59:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 12 Mar 2019 15:59:19 -0700 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: References: <5C811A51.5080005@oracle.com> <5C87F555.2030802@oracle.com> Message-ID: Looks good to me as well Gary, Jc On Tue, Mar 12, 2019 at 1:46 PM wrote: > Looks good to me. > > dl > > > On 3/12/19 11:07 AM, Gary Adams wrote: > > Still need 2 more reviewers ... > > > > On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: > >> Gary, > >> > >> Since the 'graal' label was recently removed, I also removed "[Graal]" > >> from the bug synopsis. Please make sure you update your commit mesg. > >> > >> > >> On 3/7/19 8:19 AM, Gary Adams wrote: > >>> While trying to reproduce the timeout reported in > >>> JDK-8000669: com/sun/jdi/SimulResumerTest.java times out > >>> > >>> I was unable to reproduce the timeout failure, but I did occasionally > >>> see the ObjectCollectedException. The output from the test is very > >>> verbose > >>> and may be the source of the occasional timeout. I'd like to close > >>> JDK-8000669 > >>> as cannot reproduce and if it shows up again look into limiting the > >>> amount > >>> of non-essential output from the test. > >>> > >>> This is a racy test to begin with and it already is ignoring exceptions > >>> due to unexpected thread states. Adding the ignore for > >>> ObjectCollectedException > >>> allows the test to complete without errors. > >>> > >>> The graal label was recently removed. We should also remove it from > >>> the summary. > >>> > >>> Proposed changeset: > >>> > >>> > >>> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > >>> b/test/jdk/com/sun/jdi/SimulResumerTest.java > >>> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > >>> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > >>> @@ -1,5 +1,5 @@ > >>> /* > >>> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All > >>> rights reserved. > >>> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All > >>> rights reserved. > >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >>> * > >>> * This code is free software; you can redistribute it and/or > >>> modify it > >>> @@ -211,6 +211,8 @@ > >>> > >>> } catch (IncompatibleThreadStateException ee) { > >>> // ignore > >>> + } catch (ObjectCollectedException ee) { > >>> + // ignore > >>> } catch (VMDisconnectedException ee) { > >>> // This is how we stop. The debuggee runs to > >>> completion > >>> // and we get this exception. > >> > >> There should be some sort of comment explaining why it is okay to ignore > >> the ObjectCollectedException. When the IncompatibleThreadStateException > >> was ignored, there should have been a comment added for that also. > >> > >> Dan > >> > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Mar 12 23:14:34 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 12 Mar 2019 16:14:34 -0700 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: <4d2407d4-7d51-e1b9-6adb-f7d3242137c7@oracle.com> References: <4d2407d4-7d51-e1b9-6adb-f7d3242137c7@oracle.com> Message-ID: <56CEFF7D-EF3C-42CB-83CC-5659711A8A3E@oracle.com> Hi Daniel, Since you have reviewed the first version of the webrev, just wanted to check with you that you are OK with the new version of the fix. Please note that a new enhancement [3] was created to cover the work related with hiding JVMCI compiler (and probably some other) threads. References ---------------- [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 Thanks, Daniil ?On 3/11/19, 9:22 PM, "dean.long at oracle.com" wrote: This is consistent with how other system threads are handled, so it looks good to me. dl On 3/11/19 4:32 PM, Daniil Titov wrote: > Hi Dean, JC and Daniel, > > Thank you for reviewing this change. Based on the overall output it seems as the common consensus is that the broader discussions is required to decide what would be a proper way to optionally hide/mute JVMCI compiler threads (and probably some other ?system? Java threads) from JVMTI clients. Thus, my suggestion is to move this discussion in a new enhancement [3] and limit the current issue just to the fixing the test itself. > > Please review a new version of the webrev that adds JVMCI compiler and "HotSpotGraalManagement Bean Registration" threads to the list of the threads the tests must ignore. > > > Reference: > -------------- > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 > > Thanks, > Daniil > > From: > Organization: Oracle Corporation > Date: Thursday, March 7, 2019 at 12:19 PM > To: Daniil Titov , OpenJDK Serviceability > Subject: Re: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed > > There are other places where is_hidden_from_external_view() is used. Should is_hidden_from_external_view() also check the new capability? If so, then you can simplify your changes. I'm not sure the new capability is the best choice, however. There is still no way to control whether compiler threads can post events, hit breakpoints, single-step, etc. And "compiler thread" might be too specific. There might be other types of "system thread" that we want to ignore. Since this is a JVMTI spec change, I think it deserves more discussion. For example, an alternative would be a way to set "can debug"/"visible"/"can post events"/etc flags on individual threads. > > dl > On 3/7/19 9:54 AM, Daniil Titov wrote: > Please review a change that fixes this test. > > The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. > > The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > Thanks! > -Daniil > > > > > From daniil.x.titov at oracle.com Tue Mar 12 23:46:18 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 12 Mar 2019 16:46:18 -0700 Subject: RFR: 8220244: vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003 hasn't been un-problemlisted Message-ID: Please review a trivial change that removes test vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003, recently fixed in 8218167, from ProblemList-graal.txt Webrev: http://cr.openjdk.java.net/~dtitov/8220244/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8220244 Thanks! --Daniil From dean.long at oracle.com Tue Mar 12 23:58:37 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 12 Mar 2019 16:58:37 -0700 Subject: RFR: 8220244: vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003 hasn't been un-problemlisted In-Reply-To: References: Message-ID: <07915dc5-6ec6-2c4c-a771-81b419fe06db@oracle.com> Looks good and trivial. dl On 3/12/19 4:46 PM, Daniil Titov wrote: > Please review a trivial change that removes test vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003, recently fixed in 8218167, from ProblemList-graal.txt > > Webrev: http://cr.openjdk.java.net/~dtitov/8220244/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8220244 > > Thanks! > --Daniil > > > From daniil.x.titov at oracle.com Wed Mar 13 03:38:58 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 12 Mar 2019 20:38:58 -0700 Subject: 8220244: vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003 hasn't been un-problemlisted In-Reply-To: <2E0AE16A-37CE-4DA1-A4B8-D54C3E8AC3B8@oracle.com> References: <2E0AE16A-37CE-4DA1-A4B8-D54C3E8AC3B8@oracle.com> Message-ID: <367AD5DB-17BC-4E7E-83E0-B8FCB9AA7434@oracle.com> Thank you, Dean, for reviewing this change. --Daniil ?On 3/12/19, 5:00 PM, "serviceability-dev-bounces at openjdk.java.net on behalf of dean.long at oracle.com" wrote: Looks good and trivial. dl On 3/12/19 4:46 PM, Daniil Titov wrote: > Please review a trivial change that removes test vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003, recently fixed in 8218167, from ProblemList-graal.txt > > Webrev: http://cr.openjdk.java.net/~dtitov/8220244/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8220244 > > Thanks! > --Daniil > > > From chris.plummer at oracle.com Wed Mar 13 06:28:18 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 12 Mar 2019 23:28:18 -0700 Subject: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle Message-ID: Hi, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8220352 http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/ The possible use of an invalid jni handle is being avoided by not deleting the globalrefs as the test exits. This is the same fix that was applied to JDK-8172995 when the same situation turned up there. Before the fix I was able to reproduce the issue after 700 runs. I did 1100 after the fix and did not see any problems. thanks, Chris From gary.adams at oracle.com Wed Mar 13 10:31:48 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 13 Mar 2019 06:31:48 -0400 Subject: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle In-Reply-To: References: Message-ID: Looks good to me. On 3/13/19 2:28 AM, Chris Plummer wrote: > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8220352 > http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/ > > The possible use of an invalid jni handle is being avoided by not > deleting the globalrefs as the test exits. This is the same fix that > was applied to JDK-8172995 when the same situation turned up there. > > Before the fix I was able to reproduce the issue after 700 runs. I did > 1100 after the fix and did not see any problems. > > thanks, > > Chris From gary.adams at oracle.com Wed Mar 13 11:49:07 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 13 Mar 2019 07:49:07 -0400 Subject: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: References: <5C811A51.5080005@oracle.com> <3FA57971-E051-47FD-9520-464DE515A5ED@oracle.com> Message-ID: <5C88EE33.8090408@oracle.com> There is a caution in the disableCollection() docs that it should be used sparingly, because the behavior between debug and non-debug runs could differ. I actually prefer leaving the test in it's racy configuration. The collection of the object is not central to what the test is actually trying to observe. Ignoring the exception if it does occur allows the test to complete the work it intends to cover. On 3/12/19, 2:22 PM, Daniil Titov wrote: > Hi Gary, > > The fix looks good. However, since there are only two references (debuggeeThread1 and debuggeeThread2) the test checks, an alternative to catching and ignoring ObjectCollectedException could be just calling disableCollection() on these two thread references when a breakpoint handle is called (lines 130 and 135). > > Thanks! > > Best regards, > Daniil > > > > ?On 3/12/19, 11:05 AM, "serviceability-dev on behalf of Gary Adams" wrote: > > Still need 2 more reviewers ... > > On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: > > Gary, > > > > Since the 'graal' label was recently removed, I also removed "[Graal]" > > from the bug synopsis. Please make sure you update your commit mesg. > > > > > > On 3/7/19 8:19 AM, Gary Adams wrote: > >> While trying to reproduce the timeout reported in > >> JDK-8000669: com/sun/jdi/SimulResumerTest.java times out > >> > >> I was unable to reproduce the timeout failure, but I did occasionally > >> see the ObjectCollectedException. The output from the test is very > >> verbose > >> and may be the source of the occasional timeout. I'd like to close > >> JDK-8000669 > >> as cannot reproduce and if it shows up again look into limiting the > >> amount > >> of non-essential output from the test. > >> > >> This is a racy test to begin with and it already is ignoring exceptions > >> due to unexpected thread states. Adding the ignore for > >> ObjectCollectedException > >> allows the test to complete without errors. > >> > >> The graal label was recently removed. We should also remove it from > >> the summary. > >> > >> Proposed changeset: > >> > >> > >> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > >> b/test/jdk/com/sun/jdi/SimulResumerTest.java > >> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > >> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > >> @@ -1,5 +1,5 @@ > >> /* > >> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All > >> rights reserved. > >> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All > >> rights reserved. > >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >> * > >> * This code is free software; you can redistribute it and/or modify it > >> @@ -211,6 +211,8 @@ > >> > >> } catch (IncompatibleThreadStateException ee) { > >> // ignore > >> + } catch (ObjectCollectedException ee) { > >> + // ignore > >> } catch (VMDisconnectedException ee) { > >> // This is how we stop. The debuggee runs to > >> completion > >> // and we get this exception. > > > > There should be some sort of comment explaining why it is okay to ignore > > the ObjectCollectedException. When the IncompatibleThreadStateException > > was ignored, there should have been a comment added for that also. > > > > Dan > > > > > > > From netbeans at post.cz Wed Mar 13 07:32:29 2019 From: netbeans at post.cz (netbeans at post.cz) Date: Wed, 13 Mar 2019 08:32:29 +0100 (CET) Subject: Fwd: Re: JMX References: <5L8.3VYTM.5Bqg4rlewje.1SQypV@seznam.cz> Message-ID: ---------- P?vodn? e-mail ---------- Od: Daniel Fuchs Komu: netbeans at post.cz, jdk-dev at openjdk.java.net Datum: 19. 2. 2019 19:56:19 P?edm?t: Re: JMX "Hi, JMX related issues are mostly discussed on the serviceability-dev mailing list these days. On 19/02/2019 09:31, netbeans at post.cz wrote: > > Dear Dev. > > 1) MXBeans > > I would like to recommend you simplify MXBeans as currently it is not so > easy to use. > > E.g. If you need Map where even Serializable can be > simple open types, so like dynamical for dirent key. MXBeans are used to map model-specific interfaces to generic openmbeans types. If your model consists of a map with dynamic key value pairs - as opposed to an interface that has a number of specific getters - then MXBeans may not be what you should use. For instance, you can achieve what you describe by reverting to using an OpenMBean directly, and expose your map as a CompositeData instead. See: https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/ management/package-summary.html https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/ management/MXBean.html and https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/ management/openmbean/package-summary.html [...] > Additionally there is Date, but why it is not there new java.time objects. JMX was added in Java 5. java.time in Java 8. Extending the set of open types supported by MXBeans would offer interesting challenges as to maintaining interoperability with applications running on previous version of the JVM. In other words: that might be hard. > Or maybe MXBeans should be deprecated at all. MXBeans work very well for their intended target usage. They do have their limitations, but so have other types of MBeans. It's a trade-off. You can read about the different types of MBeans here: https://docs.oracle.com/en/java/javase/11/docs/api/java.management/javax/ management/package-summary.html > 2) Maps vs MBean > > As you my know there is use e.g. what ever type parameter you choose there > is get(Object) and similar to other methods. > > So if you would like to use it as MBean Proxy you need to create new > interface extending e.g. Map (even target does it) and you > have to explicitly create get(String). > > If you do not do it. I am not sure I have understood all your concerns, but I believe OpenMBeans and CompositeData is what might correspond to your needs. best regards, -- daniel " -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Mar 13 15:27:20 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 08:27:20 -0700 Subject: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle In-Reply-To: References: Message-ID: Looks good to me as well :). I was going to ask a question but got the answer in the bug comment you put :), thanks for being thorough in the explanation there! Jc On Wed, Mar 13, 2019 at 3:34 AM gary.adams at oracle.com wrote: > Looks good to me. > > On 3/13/19 2:28 AM, Chris Plummer wrote: > > Hi, > > > > Please review the following: > > > > https://bugs.openjdk.java.net/browse/JDK-8220352 > > http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/ > > > > The possible use of an invalid jni handle is being avoided by not > > deleting the globalrefs as the test exits. This is the same fix that > > was applied to JDK-8172995 when the same situation turned up there. > > > > Before the fix I was able to reproduce the issue after 700 runs. I did > > 1100 after the fix and did not see any problems. > > > > thanks, > > > > Chris > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Mar 13 15:54:24 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 13 Mar 2019 11:54:24 -0400 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C811A51.5080005@oracle.com> References: <5C811A51.5080005@oracle.com> Message-ID: <5C8927B0.9000704@oracle.com> One last set of diffs ... - added comments on the ignored exceptions - commented out excessive diagnostic print out (this will remove the jtreg truncated output) Ok to use dan, dean and jc as reveiwers? diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java b/test/jdk/com/sun/jdi/SimulResumerTest.java --- a/test/jdk/com/sun/jdi/SimulResumerTest.java +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -210,7 +210,9 @@ } } catch (IncompatibleThreadStateException ee) { - // ignore + // ignore checks if thread was not suspended + } catch (ObjectCollectedException ee) { + // ignore checks if thread was collected } catch (VMDisconnectedException ee) { // This is how we stop. The debuggee runs to completion // and we get this exception. @@ -249,7 +251,7 @@ public void run() { while (true) { iters++; - System.out.println("bkpts = " + bkpts + ", iters = " + iters); + // System.out.println("bkpts = " + bkpts + ", iters = " + iters); try { Thread.sleep(waitTime); check(debuggeeThread1); On 3/7/19, 8:19 AM, Gary Adams wrote: > While trying to reproduce the timeout reported in > JDK-8000669: com/sun/jdi/SimulResumerTest.java times out > > I was unable to reproduce the timeout failure, but I did occasionally > see the ObjectCollectedException. The output from the test is very > verbose > and may be the source of the occasional timeout. I'd like to close > JDK-8000669 > as cannot reproduce and if it shows up again look into limiting the > amount > of non-essential output from the test. > > This is a racy test to begin with and it already is ignoring exceptions > due to unexpected thread states. Adding the ignore for > ObjectCollectedException > allows the test to complete without errors. > > The graal label was recently removed. We should also remove it from > the summary. > > Proposed changeset: > > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > b/test/jdk/com/sun/jdi/SimulResumerTest.java > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -211,6 +211,8 @@ > > } catch (IncompatibleThreadStateException ee) { > // ignore > + } catch (ObjectCollectedException ee) { > + // ignore > } catch (VMDisconnectedException ee) { > // This is how we stop. The debuggee runs to completion > // and we get this exception. From jcbeyler at google.com Wed Mar 13 16:32:12 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 09:32:12 -0700 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C8927B0.9000704@oracle.com> References: <5C811A51.5080005@oracle.com> <5C8927B0.9000704@oracle.com> Message-ID: Yes for me :) (though I'm not a Reviewer and I don't like commented code generally, for diagnostic tests I usually just put a flag that is off by default but no need to change it for me/this :-)), Jc On Wed, Mar 13, 2019 at 8:55 AM Gary Adams wrote: > One last set of diffs ... > - added comments on the ignored exceptions > - commented out excessive diagnostic print out > (this will remove the jtreg truncated output) > > Ok to use dan, dean and jc as reveiwers? > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > b/test/jdk/com/sun/jdi/SimulResumerTest.java > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -210,7 +210,9 @@ > } > > } catch (IncompatibleThreadStateException ee) { > - // ignore > + // ignore checks if thread was not suspended > + } catch (ObjectCollectedException ee) { > + // ignore checks if thread was collected > } catch (VMDisconnectedException ee) { > // This is how we stop. The debuggee runs to completion > // and we get this exception. > @@ -249,7 +251,7 @@ > public void run() { > while (true) { > iters++; > - System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > + // System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > try { > Thread.sleep(waitTime); > check(debuggeeThread1); > > > > On 3/7/19, 8:19 AM, Gary Adams wrote: > > While trying to reproduce the timeout reported in > > JDK-8000669: com/sun/jdi/SimulResumerTest.java times out > > > > I was unable to reproduce the timeout failure, but I did occasionally > > see the ObjectCollectedException. The output from the test is very > > verbose > > and may be the source of the occasional timeout. I'd like to close > > JDK-8000669 > > as cannot reproduce and if it shows up again look into limiting the > > amount > > of non-essential output from the test. > > > > This is a racy test to begin with and it already is ignoring exceptions > > due to unexpected thread states. Adding the ignore for > > ObjectCollectedException > > allows the test to complete without errors. > > > > The graal label was recently removed. We should also remove it from > > the summary. > > > > Proposed changeset: > > > > > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > > b/test/jdk/com/sun/jdi/SimulResumerTest.java > > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > > reserved. > > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > > reserved. > > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > * > > * This code is free software; you can redistribute it and/or modify it > > @@ -211,6 +211,8 @@ > > > > } catch (IncompatibleThreadStateException ee) { > > // ignore > > + } catch (ObjectCollectedException ee) { > > + // ignore > > } catch (VMDisconnectedException ee) { > > // This is how we stop. The debuggee runs to completion > > // and we get this exception. > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Mar 13 17:48:01 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Mar 2019 10:48:01 -0700 Subject: [11] [12] RFR 8210457: JVM crash in ResolvedMethodTable::add_method(Handle) In-Reply-To: <72a11bd5-163a-5348-8e53-c745b2e4b20a@oracle.com> References: <72a11bd5-163a-5348-8e53-c745b2e4b20a@oracle.com> Message-ID: Hi Coleen, Both backports look good to me. Thanks, Serguei On 3/12/19 15:07, coleen.phillimore at oracle.com wrote: > Summary: Add a function to call NSME in ResolvedMethodTable to replace > deleted methods. > > Please review a backport of this bug to JDK 11 and 12.? The JDK 12 > backport required some manual merging in > ResolvedMethodTable::adjust_method_entries to account for some > preceding cleanup in the original.? The JDK 11 backport patched > cleanly from the 12 backport except for the copyright on Unsafe.java. > > The JDK 13 patch: http://hg.openjdk.java.net/jdk/jdk/rev/09cba396916f > > JDK 12 webrev: > http://cr.openjdk.java.net/~coleenp/2019/8210457.01.12/webrev > JDK 11 webrev: > http://cr.openjdk.java.net/~coleenp/2019/8210457.01.11/webrev > > I only have approval for JDK 11 at the moment. > > These patches passed mach5 tier1 and 2, and the jvmti and > java/lang/instrument redefinition jtreg tests. > > Thanks, > Coleen From chris.plummer at oracle.com Wed Mar 13 18:19:19 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Mar 2019 11:19:19 -0700 Subject: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Mar 13 18:38:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Mar 2019 11:38:20 -0700 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Mar 13 18:50:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Mar 2019 11:50:41 -0700 Subject: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle In-Reply-To: References: Message-ID: <05f339e5-9b7d-ecdb-5983-fdb86543ecb8@oracle.com> Hi Chris, Looks good. Thanks, Serguei On 3/12/19 23:28, Chris Plummer wrote: > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8220352 > http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/ > > The possible use of an invalid jni handle is being avoided by not > deleting the globalrefs as the test exits. This is the same fix that > was applied to JDK-8172995 when the same situation turned up there. > > Before the fix I was able to reproduce the issue after 700 runs. I did > 1100 after the fix and did not see any problems. > > thanks, > > Chris From coleen.phillimore at oracle.com Wed Mar 13 19:34:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 13 Mar 2019 15:34:33 -0400 Subject: [11] [12] RFR 8210457: JVM crash in ResolvedMethodTable::add_method(Handle) In-Reply-To: References: <72a11bd5-163a-5348-8e53-c745b2e4b20a@oracle.com> Message-ID: Thank you Serguei! Coleen On 3/13/19 1:48 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Both backports look good to me. > > Thanks, > Serguei > > > On 3/12/19 15:07, coleen.phillimore at oracle.com wrote: >> Summary: Add a function to call NSME in ResolvedMethodTable to >> replace deleted methods. >> >> Please review a backport of this bug to JDK 11 and 12.? The JDK 12 >> backport required some manual merging in >> ResolvedMethodTable::adjust_method_entries to account for some >> preceding cleanup in the original.? The JDK 11 backport patched >> cleanly from the 12 backport except for the copyright on Unsafe.java. >> >> The JDK 13 patch: http://hg.openjdk.java.net/jdk/jdk/rev/09cba396916f >> >> JDK 12 webrev: >> http://cr.openjdk.java.net/~coleenp/2019/8210457.01.12/webrev >> JDK 11 webrev: >> http://cr.openjdk.java.net/~coleenp/2019/8210457.01.11/webrev >> >> I only have approval for JDK 11 at the moment. >> >> These patches passed mach5 tier1 and 2, and the jvmti and >> java/lang/instrument redefinition jtreg tests. >> >> Thanks, >> Coleen > From dean.long at oracle.com Wed Mar 13 21:09:46 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Mar 2019 14:09:46 -0700 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C8927B0.9000704@oracle.com> References: <5C811A51.5080005@oracle.com> <5C8927B0.9000704@oracle.com> Message-ID: I don't know how to interpret "ignore checks if thread was collected", so it doesn't add much value for me. How about something like "ignore ownedMonitors() failure"? dl On 3/13/19 8:54 AM, Gary Adams wrote: > One last set of diffs ... > ? - added comments on the ignored exceptions > ? - commented out excessive diagnostic print out > ???? (this will remove the jtreg truncated output) > > Ok to use dan, dean and jc as reveiwers? > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > b/test/jdk/com/sun/jdi/SimulResumerTest.java > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -210,7 +210,9 @@ > ???????????????? } > > ???????????? } catch (IncompatibleThreadStateException ee) { > -??????????????? // ignore > +??????????????? // ignore checks if thread was not suspended > +??????????? } catch (ObjectCollectedException ee) { > +??????????????? // ignore checks if thread was collected > ???????????? } catch (VMDisconnectedException ee) { > ???????????????? // This is how we stop.? The debuggee runs to completion > ???????????????? // and we get this exception. > @@ -249,7 +251,7 @@ > ???????????????? public void run() { > ???????????????????? while (true) { > ???????????????????????? iters++; > -??????????????????????? System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > +??????????????????????? // System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > ???????????????????????? try { > ???????????????????????????? Thread.sleep(waitTime); > ???????????????????????????? check(debuggeeThread1); > > > > On 3/7/19, 8:19 AM, Gary Adams wrote: >> While trying to reproduce the timeout reported in >> ? JDK-8000669: com/sun/jdi/SimulResumerTest.java times out >> >> I was unable to reproduce the timeout failure, but I did occasionally >> see the ObjectCollectedException. The output from the test is very >> verbose >> and may be the source of the occasional timeout. I'd like to close >> JDK-8000669 >> as cannot reproduce and if it shows up again look into limiting the >> amount >> of non-essential output from the test. >> >> This is a racy test to begin with and it already is ignoring exceptions >> due to unexpected thread states. Adding the ignore for >> ObjectCollectedException >> allows the test to complete without errors. >> >> The graal label was recently removed. We should also remove it from >> the summary. >> >> Proposed changeset: >> >> >> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java >> b/test/jdk/com/sun/jdi/SimulResumerTest.java >> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java >> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -211,6 +211,8 @@ >> >> ???????????? } catch (IncompatibleThreadStateException ee) { >> ???????????????? // ignore >> +??????????? } catch (ObjectCollectedException ee) { >> +??????????????? // ignore >> ???????????? } catch (VMDisconnectedException ee) { >> ???????????????? // This is how we stop.? The debuggee runs to >> completion >> ???????????????? // and we get this exception. > From jcbeyler at google.com Wed Mar 13 23:07:28 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 16:07:28 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ Message-ID: Hi all, Could I get a review of: Bug: https://bugs.openjdk.java.net/browse/JDK-8220628 Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/ I've not tried to do anything special here to keep the review simple; in the next webrev or two, I'll move more code to more C++ style and then work on diagnostic print-outs (in C++ :-)) to figure out the issues with the bugs related to these tests. This passed testing on my dev machine and a submit repo run (which I'm not sure runs these test but still good to check). Thanks! Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Mar 13 23:58:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Mar 2019 16:58:30 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Mar 14 00:58:53 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Mar 2019 17:58:53 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ In-Reply-To: References: Message-ID: <3f759ee0-0855-c4c1-28b5-c5a211a043c2@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Mar 14 03:00:11 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 20:00:11 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ In-Reply-To: <3f759ee0-0855-c4c1-28b5-c5a211a043c2@oracle.com> References: <3f759ee0-0855-c4c1-28b5-c5a211a043c2@oracle.com> Message-ID: Hi Chris, Thanks for the review, we could debate here about reinterpret vs static (my theory/understanding was do static if all else fails (and then do C style if that fails)) but really I'm going to do new/delete right after this and so all those casts will disappear in the next webrev. So in my opinion if your Looks good can be a LGTM then we will remove the casts in the next ones. Let me know what you think. Thanks, Jc On Wed, Mar 13, 2019 at 5:59 PM Chris Plummer wrote: > Hi JC, > > Looks good. My only question is your use of reinterpret_cast instead of > static_cast. Not an area of C++ I know much about, other than having just > read some varying opinions that aren't all that good at explaining what's > going on. > > thanks, > > Chris > > On 3/13/19 4:07 PM, Jean Christophe Beyler wrote: > > Hi all, > > Could I get a review of: > Bug: https://bugs.openjdk.java.net/browse/JDK-8220628 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/ > > I've not tried to do anything special here to keep the review simple; in > the next webrev or two, I'll move more code to more C++ style and then work > on diagnostic print-outs (in C++ :-)) to figure out the issues with the > bugs related to these tests. > > This passed testing on my dev machine and a submit repo run (which I'm not > sure runs these test but still good to check). > > Thanks! > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Mar 14 03:29:21 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Mar 2019 20:29:21 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ In-Reply-To: References: <3f759ee0-0855-c4c1-28b5-c5a211a043c2@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Thu Mar 14 09:21:22 2019 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 14 Mar 2019 10:21:22 +0100 Subject: RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots In-Reply-To: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> References: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> Message-ID: <696FC6FC-45D6-4F7F-A878-517F328C26E2@oracle.com> > On 12 Mar 2019, at 16:19, Stefan Karlsson wrote: > > Hi all, Hey StefanK, > Please review and/or comment on this change to remove CodeCache::scavenge_root_nmehods_do from VM_HeapWalkOperation::collect_simple_roots. > > http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ I think this patch makes sense, removing the call CodeCache::scavenge_root_nmethods_do makes the semantics of the JVMTI operations you mentioned much more clear. Reviewed. > On 12 Mar 2019, at 16:19, Stefan Karlsson wrote: > There has been some brief, internal discussions that maybe we want to visit all sets of roots in the vm, both strong and weak. A quick > implementation of that causes problem in testing when objects tagged by JVMTI, and JNI weak global handles, gets reported as roots. > Because of that, such change requires more investigation and work than simply extending the set of roots. It would be nice if we could add a note somewhere about how HotSpot interprets ?...and other objects used as roots for the purposes of garbage collection? in the JVMTI specification. As you have highlighted, and as we discussed, this wording in the JVMTI specification is not precise enough. Different GC algorithms (and different phases of a single GC algorithm) often have different root sets, rendering the wording ??objects used as roots for the purpose of garbage collection? unclear, since the ?objects used as roots? can differ depending on GC algorithm and phase. An implementation of the JVMTI specification has to interpret this sentence and choose which objects to include in the root set for these JVMTI operations. I think it would be helpful for HotSpot JVMTI users if there is a place where we could document which objects HotSpot includes in this root set (we should preferably use the same set of root objects for all GC algorithms). Thanks, Erik From stefan.karlsson at oracle.com Thu Mar 14 09:23:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Mar 2019 10:23:29 +0100 Subject: RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots In-Reply-To: <696FC6FC-45D6-4F7F-A878-517F328C26E2@oracle.com> References: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> <696FC6FC-45D6-4F7F-A878-517F328C26E2@oracle.com> Message-ID: On 2019-03-14 10:21, Erik Helin wrote: >> On 12 Mar 2019, at 16:19, Stefan Karlsson wrote: >> >> Hi all, > > Hey StefanK, > >> Please review and/or comment on this change to remove CodeCache::scavenge_root_nmehods_do from VM_HeapWalkOperation::collect_simple_roots. >> >> http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ > > I think this patch makes sense, removing the call CodeCache::scavenge_root_nmethods_do makes the semantics of the JVMTI operations you mentioned much more clear. Reviewed. Thanks! > >> On 12 Mar 2019, at 16:19, Stefan Karlsson wrote: >> There has been some brief, internal discussions that maybe we want to visit all sets of roots in the vm, both strong and weak. A quick >> implementation of that causes problem in testing when objects tagged by JVMTI, and JNI weak global handles, gets reported as roots. >> Because of that, such change requires more investigation and work than simply extending the set of roots. > > It would be nice if we could add a note somewhere about how HotSpot interprets ?...and other objects used as roots for the purposes of garbage collection? in the JVMTI specification. As you have highlighted, and as we discussed, this wording in the JVMTI specification is not precise enough. Different GC algorithms (and different phases of a single GC algorithm) often have different root sets, rendering the wording ??objects used as roots for the purpose of garbage collection? unclear, since the ?objects used as roots? can differ depending on GC algorithm and phase. An implementation of the JVMTI specification has to interpret this sentence and choose which objects to include in the root set for these JVMTI operations. I think it would be helpful for HotSpot JVMTI users if there is a place where we could document which objects HotSpot includes in this root set (we should preferably use the same set of root objects for all GC algorithms). Should we create a hotspot/jvmti RFE for this? StefanK > > Thanks, > Erik > From stefan.karlsson at oracle.com Thu Mar 14 09:26:51 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Mar 2019 10:26:51 +0100 Subject: RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots In-Reply-To: References: <0a918530-cc1a-218a-0368-2f57404ca9b7@oracle.com> Message-ID: Thanks, Serguei! StefanK On 2019-03-12 22:50, serguei.spitsyn at oracle.com wrote: > Hi Stefan, > > The fix looks good to me. > Testing the tiers 1-7 for different GC's has to be good enough. > > Thanks, > Serguei > > > On 3/12/19 8:19 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review and/or comment on this change to remove >> CodeCache::scavenge_root_nmehods_do from >> VM_HeapWalkOperation::collect_simple_roots. >> >> http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8220342 >> >> VM_HeapWalkOperation::collect_simple_roots is used to implement the >> following JVMTI functionality: >> ?IterateOverReachableObjects >> ?IterateOverObjectsReachableFromObject >> ?FollowReferences >> >> From: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#FollowReferences >> >> >> "This function initiates a traversal over the objects that are >> directly and indirectly reachable from the specified object or, if >> initial_object is not specified, all objects reachable from the heap >> roots. The heap root are the set of system classes, JNI globals, >> references from thread stacks, and other objects used as roots for the >> purposes of garbage collection." >> >> The set of roots in collect_simple_roots matches this, and mostly >> visits the set of roots that one of our class unloading enabled GCs >> would visit. >> >> There are some roots missing. For example: >> ?Management::oops_do >> ?JvmtiExport::oops_do >> ?AOTLoader::oops_do >> >> And there's one set of roots that is present in collect_simple_roots, >> that is not visited by our unloading GCs: >> ?CodeCache::scavenge_root_nmethods_do >> >> As an example, in PSMarkSweep we have the following comment in the >> root scanning code: >> ? // Do not treat nmethods as strong roots for mark/sweep, since we >> can unload them. >> ? //CodeCache::scavenge_root_nmethods_do(...); >> >> The CodeCache::scavenge_root_nmethods_do is only used by Serial, >> Parallel, and CMS, to scan pointers into young gen. Other GCs don't >> use it at all, and if we run with G1 this call does nothing at all. >> >> CodeCache::scavenge_root_nmethods_do is an GC implementation detail >> that I want to confine with the following RFE: >> ?https://bugs.openjdk.java.net/browse/JDK-8220343 >> ?"Move scavenge_root_nmethods from shared code" >> >> and this is the only external usage of it. >> >> Note also that the only effect of this code is that it adds a set of >> roots that point into the young gen, but only for some of our GCs. >> There are other roots that also point into the young gen that we don't >> visit. For example, the non-system classes. See how >> collect_simple_roots use ClassLoaderDataGraph::always_strong_cld_do >> instead of ClassLoaderDataGraph::cld_do. >> >> I've run through tier1-7 with this removal, without any problems. >> >> I'd be interested in hearing if others have a justification for having >> this code in collect_simple_roots. Or a test-case showing why this is >> needed. >> >> There has been some brief, internal discussions that maybe we want to >> visit all sets of roots in the vm, both strong and weak. A quick >> implementation of that causes problem in testing when objects tagged >> by JVMTI, and JNI weak global handles, gets reported as roots. Because >> of that, such change requires more investigation and work than simply >> extending the set of roots. However, if one were to go that route the >> above call to CodeCache::scavenge_root_nmethods_do would be replaced >> with CodeCache::blobs_do, the function used when we turn off class >> unloading and use our weak roots as strong roots. As an example, see >> GenCollectedHeap::process_roots: >> >> ????? // CMSCollector uses this to do intermediate-strength collections. >> ????? // We scan the entire code cache, since CodeCache::do_unloading >> is not called. >> ????? CodeCache::blobs_do(code_roots); >> >> Thanks, >> StefanK > From daniel.fuchs at oracle.com Thu Mar 14 11:24:07 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Mar 2019 11:24:07 +0000 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: <8892ed60-e56b-cece-4c40-c6c5347fc6c9@oracle.com> References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> <9918ce41ca8bc666a1d8ab10c6d902ac728c16d4.camel@redhat.com> <8892ed60-e56b-cece-4c40-c6c5347fc6c9@oracle.com> Message-ID: Hi Severin, If you can update WAIT_FOR_JMX_AGENT_TIMEOUT_MS in JMXAgentInterfaceBinding.java to 20000, in you webrev.04, then I believe you should be good to go and push the changes. This seems to fix the instability I had observed with fastdebug VMs. best regards, -- daniel On 12/03/2019 18:22, Daniel Fuchs wrote: > >> This is what I have tried: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/ >> >> If you think we should try this one. That's fine with me. > > I have now also tested webrev.04 with a test config that uses > the fastdebug VM and observed many intermittent failures. > The logs let me think that maybe the JMX agent needed to be > given more time to come up: > > So I am now experimenting with your webrev.04 above - but with the > following additional change to JMXAgentInterfaceBinding.java: > > ??????? private static final int WAIT_FOR_JMX_AGENT_TIMEOUT_MS = 20000; > > So far the result are looking better, but tests are still running. > I wonder whether the same change would also reduce the number of > intermittent failures on your box? > > best regards, > > -- daniel From sgehwolf at redhat.com Thu Mar 14 12:49:17 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Mar 2019 13:49:17 +0100 Subject: RFR: 8219585: [TESTBUG] sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java passes trivially when it shouldn't In-Reply-To: References: <388d8fbb5ba2110cbb17e1ca599f537f3ac6ffa1.camel@redhat.com> <83e12309-70dd-37e7-a955-4b172af65460@oracle.com> <109f57d79590148149c0b9d3578ed68e716f99b3.camel@redhat.com> <726d3b2f-99eb-85a9-911b-867f1d0f02d7@oracle.com> <639c58b1bffe279183a69c65e16ba33ea7d91526.camel@redhat.com> <38c73439-6e88-c4b8-56d6-f2ed13a09ce5@oracle.com> <9918ce41ca8bc666a1d8ab10c6d902ac728c16d4.camel@redhat.com> <8892ed60-e56b-cece-4c40-c6c5347fc6c9@oracle.com> Message-ID: Hi Daniel, On Thu, 2019-03-14 at 11:24 +0000, Daniel Fuchs wrote: > Hi Severin, > > If you can update WAIT_FOR_JMX_AGENT_TIMEOUT_MS in > JMXAgentInterfaceBinding.java > to 20000, in you webrev.04, then I believe you should > be good to go and push the changes. > > This seems to fix the instability I had observed with > fastdebug VMs. Great! It works fine for me on my box now too. 100 iterations no failure. I'm going to push it. Thanks again for your help! Thanks, Severin > > best regards, > > -- daniel > > On 12/03/2019 18:22, Daniel Fuchs wrote: > > > This is what I have tried: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/ > > > > > > If you think we should try this one. That's fine with me. > > > > I have now also tested webrev.04 with a test config that uses > > the fastdebug VM and observed many intermittent failures. > > The logs let me think that maybe the JMX agent needed to be > > given more time to come up: > > > > So I am now experimenting with your webrev.04 above - but with the > > following additional change to JMXAgentInterfaceBinding.java: > > > > private static final int WAIT_FOR_JMX_AGENT_TIMEOUT_MS = > > 20000; > > > > So far the result are looking better, but tests are still running. > > I wonder whether the same change would also reduce the number of > > intermittent failures on your box? > > > > best regards, > > > > -- daniel From jcbeyler at google.com Thu Mar 14 16:36:45 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 14 Mar 2019 09:36:45 -0700 Subject: RFR(M): 8220628: Move the HeapMonitor library to C++ In-Reply-To: References: <3f759ee0-0855-c4c1-28b5-c5a211a043c2@oracle.com> Message-ID: Thanks both :) Jc On Wed, Mar 13, 2019 at 8:29 PM Chris Plummer wrote: > That's fine. LGMT. > > Chris > > On 3/13/19 8:00 PM, Jean Christophe Beyler wrote: > > Hi Chris, > > Thanks for the review, we could debate here about reinterpret vs static > (my theory/understanding was do static if all else fails (and then do C > style if that fails)) but really I'm going to do new/delete right after > this and so all those casts will disappear in the next webrev. So in my > opinion if your Looks good can be a LGTM then we will remove the casts in > the next ones. > > Let me know what you think. > > Thanks, > Jc > > > > On Wed, Mar 13, 2019 at 5:59 PM Chris Plummer > wrote: > >> Hi JC, >> >> Looks good. My only question is your use of reinterpret_cast instead of >> static_cast. Not an area of C++ I know much about, other than having just >> read some varying opinions that aren't all that good at explaining what's >> going on. >> >> thanks, >> >> Chris >> >> On 3/13/19 4:07 PM, Jean Christophe Beyler wrote: >> >> Hi all, >> >> Could I get a review of: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220628 >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8220628/ >> >> I've not tried to do anything special here to keep the review simple; in >> the next webrev or two, I'll move more code to more C++ style and then work >> on diagnostic print-outs (in C++ :-)) to figure out the issues with the >> bugs related to these tests. >> >> This passed testing on my dev machine and a submit repo run (which I'm >> not sure runs these test but still good to check). >> >> Thanks! >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Thu Mar 14 16:51:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Mar 2019 17:51:33 +0100 Subject: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp Message-ID: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Hi, I'm not sure what the right list for Metrics.java[1] is. Assuming it's serviceability-dev: Please review this one-liner for for SubSystem.java which currently behaves differently from the native implementation in osContainer_linux.cpp. Please see the details in the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ Testing: Manual testing of JDK-8217338 with Metrics.java support with/without this fix on Linux x86_64. Metrics tests and Docker tests continue to pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, which was fun). Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java From gary.adams at oracle.com Thu Mar 14 17:22:00 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 14 Mar 2019 13:22:00 -0400 Subject: RFR: JDK-8220678: unquarantine nsk/jdi/ThreadReference/setEnabled/setenabled003 Message-ID: <5C8A8DB8.30809@oracle.com> This trivial changeset will restore setenabled003 testing to jdk 13 where the test does not appear to be failing. The original bug JDK-8066993 will be left open in case sustaining team needs to apply changes in older releases. diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -158,7 +158,6 @@ vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java 8060733 generic-all vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 7034630 generic-all -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all From serguei.spitsyn at oracle.com Thu Mar 14 17:24:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Mar 2019 10:24:13 -0700 Subject: RFR: JDK-8220678: unquarantine nsk/jdi/ThreadReference/setEnabled/setenabled003 In-Reply-To: <5C8A8DB8.30809@oracle.com> References: <5C8A8DB8.30809@oracle.com> Message-ID: <4bd775dc-3e16-7b24-8a96-325edadee5c4@oracle.com> Okay. Thanks, Serguei On 3/14/19 10:22, Gary Adams wrote: > This trivial changeset will restore setenabled003 testing to jdk 13 > where the test does not appear to be failing. > > The original bug JDK-8066993 will be left open in case sustaining > team needs to apply changes in older releases. > > diff --git a/test/hotspot/jtreg/ProblemList.txt > b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -158,7 +158,6 @@ > ?vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java > 8060733 generic-all > > ?vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java > 7034630 generic-all > -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java > 8066993 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all From chris.plummer at oracle.com Thu Mar 14 17:29:30 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 14 Mar 2019 10:29:30 -0700 Subject: RFR: JDK-8220678: unquarantine nsk/jdi/ThreadReference/setEnabled/setenabled003 In-Reply-To: <4bd775dc-3e16-7b24-8a96-325edadee5c4@oracle.com> References: <5C8A8DB8.30809@oracle.com> <4bd775dc-3e16-7b24-8a96-325edadee5c4@oracle.com> Message-ID: <46e8bb59-1dd4-4293-497f-be0568247fe5@oracle.com> +1 On 3/14/19 10:24 AM, serguei.spitsyn at oracle.com wrote: > Okay. > > Thanks, > Serguei > > On 3/14/19 10:22, Gary Adams wrote: >> This trivial changeset will restore setenabled003 testing to jdk 13 >> where the test does not appear to be failing. >> >> The original bug JDK-8066993 will be left open in case sustaining >> team needs to apply changes in older releases. >> >> diff --git a/test/hotspot/jtreg/ProblemList.txt >> b/test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -158,7 +158,6 @@ >> ?vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock001/TestDescription.java >> 8060733 generic-all >> >> ?vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java >> 7034630 generic-all >> -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >> 8066993 generic-all >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all > From coleen.phillimore at oracle.com Thu Mar 14 17:40:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Mar 2019 13:40:49 -0400 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs Message-ID: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> Summary: Walk ICs to determine whether nmethods are dependent on redefined classes. See bug for more details.? Tested with redefinition tests: #redefinition tests. make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >&redefine.out make test TEST=open/test/jdk/java/lang/instrument >&instrument.out make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220512 Thanks, Coleen From bob.vandette at oracle.com Thu Mar 14 17:58:54 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 14 Mar 2019 13:58:54 -0400 Subject: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: The change looks good. Thanks for fixing this. I?d send this to core-libs (cc?d). Bob. > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf wrote: > > Hi, > > I'm not sure what the right list for Metrics.java[1] is. Assuming it's > serviceability-dev: > > Please review this one-liner for for SubSystem.java which currently > behaves differently from the native implementation in > osContainer_linux.cpp. Please see the details in the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > Testing: > Manual testing of JDK-8217338 with Metrics.java support with/without > this fix on Linux x86_64. Metrics tests and Docker tests continue to > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, which > was fun). > > Thoughts? > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > From sgehwolf at redhat.com Thu Mar 14 18:24:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 14 Mar 2019 19:24:58 +0100 Subject: RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: On Thu, 2019-03-14 at 13:58 -0400, Bob Vandette wrote: > The change looks good. Thanks for fixing this. Thanks for the review, Bob! Cheers, Severin > I?d send this to core-libs (cc?d). > > Bob. > > > > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf > > wrote: > > > > Hi, > > > > I'm not sure what the right list for Metrics.java[1] is. Assuming > > it's > > serviceability-dev: > > > > Please review this one-liner for for SubSystem.java which currently > > behaves differently from the native implementation in > > osContainer_linux.cpp. Please see the details in the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > > > Testing: > > Manual testing of JDK-8217338 with Metrics.java support > > with/without > > this fix on Linux x86_64. Metrics tests and Docker tests continue > > to > > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, > > which > > was fun). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] > > http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > From serguei.spitsyn at oracle.com Thu Mar 14 18:24:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Mar 2019 11:24:36 -0700 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> Message-ID: <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Mar 14 19:09:23 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Mar 2019 15:09:23 -0400 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> Message-ID: <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> On 3/14/19 2:24 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good to me. > > Just one minor suggestion: > > http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev/src/hotspot/share/classfile/metadataOnStackMark.cpp.udiff.html > - Threads::metadata_do(Metadata::mark_on_stack); > - CodeCache::metadata_do(Metadata::mark_on_stack); > + MetadataOnStackClosure mon_stack; > + Threads::metadata_do(&mon_stack); > + CodeCache::metadata_do(&mon_stack); > ?The 'mon_stack' can be associated with monitors. > ?How about to rename it to something like 'md_on_stack'? Okay, I'll change the name to md_on_stack. Thanks for the code review! Coleen > > Thanks, > Serguei > > > On 3/14/19 10:40, coleen.phillimore at oracle.com wrote: >> Summary: Walk ICs to determine whether nmethods are dependent on >> redefined classes. >> >> See bug for more details.? Tested with redefinition tests: >> >> #redefinition tests. >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >> >&redefine.out >> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >> make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out >> >> hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8220512 >> >> Thanks, >> Coleen >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Fri Mar 15 07:32:08 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 15 Mar 2019 15:32:08 +0800 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g Message-ID: <02887333-8901-c993-fc22-11d0e832571f@arm.com> Hi, Please review this very small test fix to serviceability/sa/TestHeapDumpForLargeArray.java: Bug: https://bugs.openjdk.java.net/browse/JDK-8220707 Webrev: http://cr.openjdk.java.net/~ngasson/8220707/webrev.0/ If you run this test with jtreg option -vmoption:-Xmx512m (or any value < 8g) then it will fail with: STATUS:Failed.`main' threw exception: java.io.IOException: LingeredApp terminated with non-zero exit code 1 LingeredAppWithLargeArray needs an -Xmx8g argument but this can be overriden by the -Xmx option passed to jtreg, as the default VM arguments are added after the explicit ones when creating the subprocess. It would work fine if they were added in the other order. Thanks, Nick From matthias.baesken at sap.com Fri Mar 15 09:18:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 15 Mar 2019 09:18:16 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit Message-ID: Hello, please review the following change . It enhances the error messages in libinstrument in case initialization fails . ( I found the enhanced error messages helpful when analyzing jtreg failures on one of our platforms in the java/lang/instrument/PremainClass/PremainClassTest.java ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8220355 http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Fri Mar 15 12:10:10 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 Mar 2019 13:10:10 +0100 Subject: RFR: 8220682: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fails with JDK-8214712 Message-ID: Hi, to allow for archiving objects in CDS that might not be loaded (e.g., JDK-8214712), we need to ignore objects at heap dump time that haven't actually been loaded. This patch fixes the VM heapDumper implementation, and is a mirror of a fix already done in the serviceability-agent heap dumper[1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8220682 Patch: diff -r 082cd1e3c441 src/hotspot/share/services/heapDumper.cpp --- a/src/hotspot/share/services/heapDumper.cpp Mon Dec 03 16:25:27 2018 +0100 +++ b/src/hotspot/share/services/heapDumper.cpp Fri Mar 15 13:11:28 2019 +0100 @@ -958,6 +958,11 @@ // creates HPROF_GC_INSTANCE_DUMP record for the given object void DumperSupport::dump_instance(DumpWriter* writer, oop o) { Klass* k = o->klass(); + if (k->java_mirror() == NULL) { + // Ignoring this object since the corresponding java mirror is not loaded. + // Might be a dormant archive object. + return; + } writer->write_u1(HPROF_GC_INSTANCE_DUMP); writer->write_objectID(o); Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8214756 From jcbeyler at google.com Fri Mar 15 14:47:17 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 15 Mar 2019 07:47:17 -0700 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: <02887333-8901-c993-fc22-11d0e832571f@arm.com> References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> Message-ID: Hi Nick, Not a reviewer but looks good to me :) I would perhaps put a comment above the argument creation to note that the order is important, ie something like: "// Need to add the default arguments first to have explicit -Xmx8g last, otherwise test will fail." Thanks, Jc On Fri, Mar 15, 2019 at 12:32 AM Nick Gasson wrote: > Hi, > > Please review this very small test fix to > serviceability/sa/TestHeapDumpForLargeArray.java: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220707 > Webrev: http://cr.openjdk.java.net/~ngasson/8220707/webrev.0/ > > If you run this test with jtreg option -vmoption:-Xmx512m (or any value > < 8g) then it will fail with: > > STATUS:Failed.`main' threw exception: java.io.IOException: LingeredApp > terminated with non-zero exit code 1 > > LingeredAppWithLargeArray needs an -Xmx8g argument but this can be > overriden by the -Xmx option passed to jtreg, as the default VM > arguments are added after the explicit ones when creating the > subprocess. It would work fine if they were added in the other order. > > Thanks, > Nick > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Mar 15 14:53:10 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 15 Mar 2019 07:53:10 -0700 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: Message-ID: Hi Matthias, (Not an official reviewer :-)) http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/: - I would invert the test for the environment and do: if (environment == NULL) { abortJVM(jnienv, JPLIS_ERRORMESSAGE_CANNOTSTART ", getting JPLIS environment failed"); } and then just un-indent the rest of the code that was in the original if. http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/src/java.instrument/share/native/libinstrument/JPLISAgent.c.udiff.html - Nit: the message could consistently start with upper case or lower case :-) Apart from that, looks good to me :-) Thanks, Jc On Fri, Mar 15, 2019 at 2:19 AM Baesken, Matthias wrote: > Hello, please review the following change . > > > > It enhances the error messages in libinstrument in case initialization > fails . > > > > ( I found the enhanced error messages helpful when analyzing jtreg > failures on one of our platforms in the > java/lang/instrument/PremainClass/PremainClassTest.java ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8220355 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/ > > > > > > Thanks, Matthias > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Mar 15 14:55:44 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 15 Mar 2019 07:55:44 -0700 Subject: RFR: 8220682: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fails with JDK-8214712 In-Reply-To: References: Message-ID: Hi Claes, Looks good to me. For those who would want to see the patch change done in the serviceability-agent: http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da Thanks, Jc On Fri, Mar 15, 2019 at 5:10 AM Claes Redestad wrote: > Hi, > > to allow for archiving objects in CDS that might not be loaded (e.g., > JDK-8214712), we need to ignore objects at heap dump time that haven't > actually been loaded. This patch fixes the VM heapDumper implementation, > and is a mirror of a fix already done in the serviceability-agent heap > dumper[1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220682 > Patch: > diff -r 082cd1e3c441 src/hotspot/share/services/heapDumper.cpp > --- a/src/hotspot/share/services/heapDumper.cpp Mon Dec 03 16:25:27 2018 > +0100 > +++ b/src/hotspot/share/services/heapDumper.cpp Fri Mar 15 13:11:28 2019 > +0100 > @@ -958,6 +958,11 @@ > // creates HPROF_GC_INSTANCE_DUMP record for the given object > void DumperSupport::dump_instance(DumpWriter* writer, oop o) { > Klass* k = o->klass(); > + if (k->java_mirror() == NULL) { > + // Ignoring this object since the corresponding java mirror is not > loaded. > + // Might be a dormant archive object. > + return; > + } > > writer->write_u1(HPROF_GC_INSTANCE_DUMP); > writer->write_objectID(o); > > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8214756 > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Mar 15 14:58:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 10:58:46 -0400 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> Message-ID: <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> From some offline feedback, I changed the name of has_evol_ics => has_evol_metadata and a couple of other small things.? I reran this though builds and tier1 tests. Incremental: http://cr.openjdk.java.net/~coleenp/2019/8220512.02.incr/webrev/index.html Full: http://cr.openjdk.java.net/~coleenp/2019/8220512.02/webrev/index.html Thanks, Coleen On 3/14/19 3:09 PM, coleen.phillimore at oracle.com wrote: > > > On 3/14/19 2:24 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> It looks good to me. >> >> Just one minor suggestion: >> >> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev/src/hotspot/share/classfile/metadataOnStackMark.cpp.udiff.html >> >> - Threads::metadata_do(Metadata::mark_on_stack); >> - CodeCache::metadata_do(Metadata::mark_on_stack); >> + MetadataOnStackClosure mon_stack; >> + Threads::metadata_do(&mon_stack); >> + CodeCache::metadata_do(&mon_stack); >> ?The 'mon_stack' can be associated with monitors. >> ?How about to rename it to something like 'md_on_stack'? > > Okay, I'll change the name to md_on_stack. > > Thanks for the code review! > Coleen > >> >> Thanks, >> Serguei >> >> >> On 3/14/19 10:40, coleen.phillimore at oracle.com wrote: >>> Summary: Walk ICs to determine whether nmethods are dependent on >>> redefined classes. >>> >>> See bug for more details.? Tested with redefinition tests: >>> >>> #redefinition tests. >>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>> >&redefine.out >>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>> make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out >>> >>> hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8220512 >>> >>> Thanks, >>> Coleen >>> >>> >> > From erik.osterlund at oracle.com Fri Mar 15 15:02:50 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 15 Mar 2019 16:02:50 +0100 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> Message-ID: <7f7aa7e2-a6fa-49b7-c6f4-83bafbad3d6f@oracle.com> Hi Coleen, Looks good. Thanks for doing this! /Erik On 2019-03-15 15:58, coleen.phillimore at oracle.com wrote: > > From some offline feedback, I changed the name of has_evol_ics => > has_evol_metadata and a couple of other small things.? I reran this > though builds and tier1 tests. > > Incremental: > http://cr.openjdk.java.net/~coleenp/2019/8220512.02.incr/webrev/index.html > Full: > http://cr.openjdk.java.net/~coleenp/2019/8220512.02/webrev/index.html > > Thanks, > Coleen > > On 3/14/19 3:09 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 3/14/19 2:24 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> It looks good to me. >>> >>> Just one minor suggestion: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev/src/hotspot/share/classfile/metadataOnStackMark.cpp.udiff.html >>> >>> - Threads::metadata_do(Metadata::mark_on_stack); >>> - CodeCache::metadata_do(Metadata::mark_on_stack); >>> + MetadataOnStackClosure mon_stack; >>> + Threads::metadata_do(&mon_stack); >>> + CodeCache::metadata_do(&mon_stack); >>> ?The 'mon_stack' can be associated with monitors. >>> ?How about to rename it to something like 'md_on_stack'? >> >> Okay, I'll change the name to md_on_stack. >> >> Thanks for the code review! >> Coleen >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/14/19 10:40, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk ICs to determine whether nmethods are dependent on >>>> redefined classes. >>>> >>>> See bug for more details.? Tested with redefinition tests: >>>> >>>> #redefinition tests. >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>> >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out >>>> >>>> hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220512 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From claes.redestad at oracle.com Fri Mar 15 15:13:34 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 Mar 2019 16:13:34 +0100 Subject: RFR: 8220682: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fails with JDK-8214712 In-Reply-To: References: Message-ID: Hi Jc, On 2019-03-15 15:55, Jean Christophe Beyler wrote: > Hi Claes, > > Looks good to me. thanks! /Claes > For those who would want to see the patch change done > in the serviceability-agent: > http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da From jianglizhou at google.com Fri Mar 15 15:28:08 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 15 Mar 2019 08:28:08 -0700 Subject: RFR: 8220682: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fails with JDK-8214712 In-Reply-To: References: Message-ID: +1 Thanks, Jiangli On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler wrote: > Hi Claes, > > Looks good to me. For those who would want to see the patch change done in > the serviceability-agent: > http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da > > Thanks, > Jc > > On Fri, Mar 15, 2019 at 5:10 AM Claes Redestad > wrote: > >> Hi, >> >> to allow for archiving objects in CDS that might not be loaded (e.g., >> JDK-8214712), we need to ignore objects at heap dump time that haven't >> actually been loaded. This patch fixes the VM heapDumper implementation, >> and is a mirror of a fix already done in the serviceability-agent heap >> dumper[1]. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220682 >> Patch: >> diff -r 082cd1e3c441 src/hotspot/share/services/heapDumper.cpp >> --- a/src/hotspot/share/services/heapDumper.cpp Mon Dec 03 16:25:27 2018 >> +0100 >> +++ b/src/hotspot/share/services/heapDumper.cpp Fri Mar 15 13:11:28 2019 >> +0100 >> @@ -958,6 +958,11 @@ >> // creates HPROF_GC_INSTANCE_DUMP record for the given object >> void DumperSupport::dump_instance(DumpWriter* writer, oop o) { >> Klass* k = o->klass(); >> + if (k->java_mirror() == NULL) { >> + // Ignoring this object since the corresponding java mirror is not >> loaded. >> + // Might be a dormant archive object. >> + return; >> + } >> >> writer->write_u1(HPROF_GC_INSTANCE_DUMP); >> writer->write_objectID(o); >> >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8214756 >> > > > -- > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Mar 15 15:32:41 2019 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 15 Mar 2019 15:32:41 +0000 (UTC) Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: <02887333-8901-c993-fc22-11d0e832571f@arm.com> References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> Message-ID: Hi Nick, Fix looks good. How have you tested it ? Thanks, Sharath -----Original Message----- From: Nick Gasson [mailto:nick.gasson at arm.com] Sent: Friday, March 15, 2019 1:02 PM To: serviceability-dev at openjdk.java.net Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g Hi, Please review this very small test fix to serviceability/sa/TestHeapDumpForLargeArray.java: Bug: https://bugs.openjdk.java.net/browse/JDK-8220707 Webrev: http://cr.openjdk.java.net/~ngasson/8220707/webrev.0/ If you run this test with jtreg option -vmoption:-Xmx512m (or any value < 8g) then it will fail with: STATUS:Failed.`main' threw exception: java.io.IOException: LingeredApp terminated with non-zero exit code 1 LingeredAppWithLargeArray needs an -Xmx8g argument but this can be overriden by the -Xmx option passed to jtreg, as the default VM arguments are added after the explicit ones when creating the subprocess. It would work fine if they were added in the other order. Thanks, Nick From coleen.phillimore at oracle.com Fri Mar 15 16:04:20 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 12:04:20 -0400 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <7f7aa7e2-a6fa-49b7-c6f4-83bafbad3d6f@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> <7f7aa7e2-a6fa-49b7-c6f4-83bafbad3d6f@oracle.com> Message-ID: <6813b329-5d4a-8ce2-230c-3ceaad9fe935@oracle.com> Thank you Erik! Coleen On 3/15/19 11:02 AM, Erik ?sterlund wrote: > Hi Coleen, > > Looks good. Thanks for doing this! > > /Erik > > On 2019-03-15 15:58, coleen.phillimore at oracle.com wrote: >> >> From some offline feedback, I changed the name of has_evol_ics => >> has_evol_metadata and a couple of other small things.? I reran this >> though builds and tier1 tests. >> >> Incremental: >> http://cr.openjdk.java.net/~coleenp/2019/8220512.02.incr/webrev/index.html >> Full: >> http://cr.openjdk.java.net/~coleenp/2019/8220512.02/webrev/index.html >> >> Thanks, >> Coleen >> >> On 3/14/19 3:09 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 3/14/19 2:24 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> It looks good to me. >>>> >>>> Just one minor suggestion: >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev/src/hotspot/share/classfile/metadataOnStackMark.cpp.udiff.html >>>> >>>> - Threads::metadata_do(Metadata::mark_on_stack); >>>> - CodeCache::metadata_do(Metadata::mark_on_stack); >>>> + MetadataOnStackClosure mon_stack; >>>> + Threads::metadata_do(&mon_stack); >>>> + CodeCache::metadata_do(&mon_stack); >>>> ?The 'mon_stack' can be associated with monitors. >>>> ?How about to rename it to something like 'md_on_stack'? >>> >>> Okay, I'll change the name to md_on_stack. >>> >>> Thanks for the code review! >>> Coleen >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/14/19 10:40, coleen.phillimore at oracle.com wrote: >>>>> Summary: Walk ICs to determine whether nmethods are dependent on >>>>> redefined classes. >>>>> >>>>> See bug for more details.? Tested with redefinition tests: >>>>> >>>>> #redefinition tests. >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> >&jvmti.out >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>> >&redefine.out >>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>> make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out >>>>> >>>>> hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220512 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> > From claes.redestad at oracle.com Fri Mar 15 16:26:40 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 Mar 2019 17:26:40 +0100 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: References: Message-ID: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Hi, I ran into a few additional test issues, one exposing a crash in jmap -histo:live in a test that seems to have been problem listed when I ran tests earlier. Also filtering out archived-but-not-yet-loaded classes in KlassInfoBucket::lookup makes tests exercising jmap etc work as intended in the presence of archived classes: http://cr.openjdk.java.net/~redestad/8220682/open.01/ Testing: tier1-3 with 8214712 ongoing /Claes On 2019-03-15 16:28, Jiangli Zhou wrote: > +1 > > Thanks, > Jiangli > > On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler > > wrote: > > Hi Claes, > > Looks good to me. For those who would want to see the patch change > done in the serviceability-agent: > http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da > > Thanks, > Jc > From daniel.daugherty at oracle.com Fri Mar 15 19:03:31 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2019 15:03:31 -0400 Subject: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure In-Reply-To: <5C8927B0.9000704@oracle.com> References: <5C811A51.5080005@oracle.com> <5C8927B0.9000704@oracle.com> Message-ID: On 3/13/19 11:54 AM, Gary Adams wrote: > One last set of diffs ... > ? - added comments on the ignored exceptions > ? - commented out excessive diagnostic print out > ???? (this will remove the jtreg truncated output) > > Ok to use dan, dean and jc as reveiwers? > > diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java > b/test/jdk/com/sun/jdi/SimulResumerTest.java > --- a/test/jdk/com/sun/jdi/SimulResumerTest.java > +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -210,7 +210,9 @@ > ???????????????? } > > ???????????? } catch (IncompatibleThreadStateException ee) { > -??????????????? // ignore > +??????????????? // ignore checks if thread was not suspended Perhaps: ?????????????? // If thread was not suspended then it is okay ?????????????? // to ignore this exception since we are racing. > + } catch (ObjectCollectedException ee) { > +??????????????? // ignore checks if thread was collected Perhaps: ?????????????? // If thread was not suspended then it is okay ?????????????? // to ignore this exception from ownedMonitors() ?????????????? // since we are racing. Thumbs up on the fix itself. I don't need to see another webrev for any more comment changes. Dan > } catch (VMDisconnectedException ee) { > ???????????????? // This is how we stop.? The debuggee runs to completion > ???????????????? // and we get this exception. > @@ -249,7 +251,7 @@ > ???????????????? public void run() { > ???????????????????? while (true) { > ???????????????????????? iters++; > -??????????????????????? System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > +??????????????????????? // System.out.println("bkpts = " + bkpts + ", > iters = " + iters); > ???????????????????????? try { > ???????????????????????????? Thread.sleep(waitTime); > ???????????????????????????? check(debuggeeThread1); > > > > On 3/7/19, 8:19 AM, Gary Adams wrote: >> While trying to reproduce the timeout reported in >> ? JDK-8000669: com/sun/jdi/SimulResumerTest.java times out >> >> I was unable to reproduce the timeout failure, but I did occasionally >> see the ObjectCollectedException. The output from the test is very >> verbose >> and may be the source of the occasional timeout. I'd like to close >> JDK-8000669 >> as cannot reproduce and if it shows up again look into limiting the >> amount >> of non-essential output from the test. >> >> This is a racy test to begin with and it already is ignoring exceptions >> due to unexpected thread states. Adding the ignore for >> ObjectCollectedException >> allows the test to complete without errors. >> >> The graal label was recently removed. We should also remove it from >> the summary. >> >> Proposed changeset: >> >> >> diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java >> b/test/jdk/com/sun/jdi/SimulResumerTest.java >> --- a/test/jdk/com/sun/jdi/SimulResumerTest.java >> +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -211,6 +211,8 @@ >> >> ???????????? } catch (IncompatibleThreadStateException ee) { >> ???????????????? // ignore >> +??????????? } catch (ObjectCollectedException ee) { >> +??????????????? // ignore >> ???????????? } catch (VMDisconnectedException ee) { >> ???????????????? // This is how we stop.? The debuggee runs to >> completion >> ???????????????? // and we get this exception. > From daniel.daugherty at oracle.com Fri Mar 15 19:35:58 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2019 15:35:58 -0400 Subject: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed In-Reply-To: <56CEFF7D-EF3C-42CB-83CC-5659711A8A3E@oracle.com> References: <4d2407d4-7d51-e1b9-6adb-f7d3242137c7@oracle.com> <56CEFF7D-EF3C-42CB-83CC-5659711A8A3E@oracle.com> Message-ID: <2a07d208-b47b-6d56-3243-5cf8a62d680c@oracle.com> > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp ??? L604: ??? if ((strlen(threadinfo.name) > prefixLength) && ??????? nit - you have an extra '(' ')' pair that's not needed. Thumbs up! No need for another webrev if you choose to fix the nit. Dan On 3/12/19 7:14 PM, Daniil Titov wrote: > Hi Daniel, > > Since you have reviewed the first version of the webrev, just wanted to check with you that you are OK with the new version of the fix. Please note that a new enhancement [3] was created to cover the work related with hiding JVMCI compiler (and probably some other) threads. > > References > ---------------- > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 > > Thanks, > Daniil > > ?On 3/11/19, 9:22 PM, "dean.long at oracle.com" wrote: > > This is consistent with how other system threads are handled, so it > looks good to me. > > dl > > On 3/11/19 4:32 PM, Daniil Titov wrote: > > Hi Dean, JC and Daniel, > > > > Thank you for reviewing this change. Based on the overall output it seems as the common consensus is that the broader discussions is required to decide what would be a proper way to optionally hide/mute JVMCI compiler threads (and probably some other ?system? Java threads) from JVMTI clients. Thus, my suggestion is to move this discussion in a new enhancement [3] and limit the current issue just to the fixing the test itself. > > > > Please review a new version of the webrev that adds JVMCI compiler and "HotSpotGraalManagement Bean Registration" threads to the list of the threads the tests must ignore. > > > > > > Reference: > > -------------- > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.02 > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > [3] Enhancement: https://bugs.openjdk.java.net/browse/JDK-8220468 > > > > Thanks, > > Daniil > > > > From: > > Organization: Oracle Corporation > > Date: Thursday, March 7, 2019 at 12:19 PM > > To: Daniil Titov , OpenJDK Serviceability > > Subject: Re: RFR: 8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed > > > > There are other places where is_hidden_from_external_view() is used. Should is_hidden_from_external_view() also check the new capability? If so, then you can simplify your changes. I'm not sure the new capability is the best choice, however. There is still no way to control whether compiler threads can post events, hit breakpoints, single-step, etc. And "compiler thread" might be too specific. There might be other types of "system thread" that we want to ignore. Since this is a JVMTI spec change, I think it deserves more discussion. For example, an alternative would be a way to set "can debug"/"visible"/"can post events"/etc flags on individual threads. > > > > dl > > On 3/7/19 9:54 AM, Daniil Titov wrote: > > Please review a change that fixes this test. > > > > The problem here is that the test checks the number of threads and with Graal on additional threads the test doesn't expect are started and cause the test fail. > > > > The fix introduces a new capability " can_show_compiler_threads" that affects whether Java compiler threads are retuned with JVMTI GetAllThreads call. By default this capability is off. The fix also adds " HotSpotGraalManagement Bean Registration" thread to the list of the threads the tests must ignore. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218812 > > > > Mach5 tier1, tier2 and tier3 tests successfully passed with this change. > > > > Thanks! > > -Daniil > > > > > > > > > > > > > > From daniil.x.titov at oracle.com Fri Mar 15 23:08:12 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 15 Mar 2019 16:08:12 -0700 Subject: RFR: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash Message-ID: Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! -Daniil From coleen.phillimore at oracle.com Fri Mar 15 23:14:13 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 19:14:13 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability Message-ID: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti.? Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed.? Tier1 testing is in progress. Thanks, Coleen From mikhailo.seledtsov at oracle.com Fri Mar 15 23:29:53 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 15 Mar 2019 16:29:53 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> Message-ID: <163ac643-04be-ec90-8eb9-d84ca5191f33@oracle.com> Looks good to me, (I am not a Reviewer though) Misha On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: > Summary: move tests out of runtime to jvmti/RedefineClasses > > These always belonged in serviceability/jvmti.? Also, moved a couple > tests within serviceability/jvmti to RedefineClasses also. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8220744 > > I ran these tests with make test > TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and > they passed.? Tier1 testing is in progress. > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Mar 15 23:33:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 19:33:46 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <163ac643-04be-ec90-8eb9-d84ca5191f33@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <163ac643-04be-ec90-8eb9-d84ca5191f33@oracle.com> Message-ID: Thanks Misha! Coleen On 3/15/19 7:29 PM, mikhailo.seledtsov at oracle.com wrote: > Looks good to me, > > (I am not a Reviewer though) > > Misha > > > On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >> Summary: move tests out of runtime to jvmti/RedefineClasses >> >> These always belonged in serviceability/jvmti.? Also, moved a couple >> tests within serviceability/jvmti to RedefineClasses also. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >> >> I ran these tests with make test >> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and >> they passed.? Tier1 testing is in progress. >> >> Thanks, >> Coleen > From jcbeyler at google.com Fri Mar 15 23:45:25 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 15 Mar 2019 16:45:25 -0700 Subject: RFR: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: Message-ID: Hi Daniil, Is it not possible that the VMDeath would happen later in the case of: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop002/framepop002.cpp.html For example, that callbacks are not yet disabled when we pass the new test: + if (!callbacksEnabled) { + return; + } But gets disabled right after? (this is for my own understanding of what is possible or not :-)) Thanks! Jc On Fri, Mar 15, 2019 at 4:08 PM Daniil Titov wrote: > Please review the change that fixes 3 tests that intermittently fail with > JVMTI_ERROR_WRONG_PHASE error. > > The problem here is that the callbacks these tests enable keep processing > events and perform JVMTI calls after VM is terminated. The fix makes these > test listen for VMDeath event and quick return from the callbacks after > VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > -Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Sat Mar 16 00:02:47 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2019 20:02:47 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> Message-ID: On 3/15/19 7:14 PM, coleen.phillimore at oracle.com wrote: > Summary: move tests out of runtime to jvmti/RedefineClasses > > These always belonged in serviceability/jvmti.? Also, moved a couple > tests within serviceability/jvmti to RedefineClasses also. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev test/hotspot/jtreg/TEST.groups ??? No comments. All of the rest are file renames. Thumbs up. Agree that this is trivial. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8220744 > > I ran these tests with make test > TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and > they passed.? Tier1 testing is in progress. > > Thanks, > Coleen From chris.plummer at oracle.com Sat Mar 16 00:06:46 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 15 Mar 2019 17:06:46 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> Message-ID: <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: > Summary: move tests out of runtime to jvmti/RedefineClasses > > These always belonged in serviceability/jvmti.? Also, moved a couple > tests within serviceability/jvmti to RedefineClasses also. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8220744 > > I ran these tests with make test > TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and > they passed.? Tier1 testing is in progress. > > Thanks, > Coleen From daniel.daugherty at oracle.com Sat Mar 16 00:14:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2019 20:14:04 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> Message-ID: <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> Yikes. I missed that. Here's the beginning of tier1_runtime: ? L261: tier1_runtime = \ ? L262: ? runtime/ \ and here's the beginning of tier1_serviceability: ? L324 tier1_serviceability = \ ? L325?? serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: > Hi Coleen, > > I think in TEST.groups you need to add > serviceability/jvmti/RedefineClasses to tier1_serviceability. > Otherwise the removes of specific tests isn't doing anything, and > tier1_serviceability won't run the other tests you moved from > tier1_runtime. > > thanks, > > Chris > > > On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >> Summary: move tests out of runtime to jvmti/RedefineClasses >> >> These always belonged in serviceability/jvmti.? Also, moved a couple >> tests within serviceability/jvmti to RedefineClasses also. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >> >> I ran these tests with make test >> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and >> they passed.? Tier1 testing is in progress. >> >> Thanks, >> Coleen > > > From coleen.phillimore at oracle.com Sat Mar 16 00:25:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 20:25:02 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> Message-ID: <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> Hi, Okay I see how it works now.? I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: > Yikes. I missed that. Here's the beginning of tier1_runtime: > > ? L261: tier1_runtime = \ > ? L262: ? runtime/ \ > > and here's the beginning of tier1_serviceability: > > ? L324 tier1_serviceability = \ > ? L325?? serviceability/dcmd/compiler \ > > I should not have assumed. Does anyone know why tier1_serviceability > isn't "start with everything" and then "filter out some stuff"? > > Dan > > > On 3/15/19 8:06 PM, Chris Plummer wrote: >> Hi Coleen, >> >> I think in TEST.groups you need to add >> serviceability/jvmti/RedefineClasses to tier1_serviceability. >> Otherwise the removes of specific tests isn't doing anything, and >> tier1_serviceability won't run the other tests you moved from >> tier1_runtime. >> >> thanks, >> >> Chris >> >> >> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>> Summary: move tests out of runtime to jvmti/RedefineClasses >>> >>> These always belonged in serviceability/jvmti.? Also, moved a couple >>> tests within serviceability/jvmti to RedefineClasses also. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>> >>> I ran these tests with make test >>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>> and they passed.? Tier1 testing is in progress. >>> >>> Thanks, >>> Coleen >> >> >> > From daniel.daugherty at oracle.com Sat Mar 16 00:29:31 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Mar 2019 20:29:31 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> Message-ID: <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: > > Hi, Okay I see how it works now.? I was wondering how to tell it to > ever run the tests. > > I fixed it so that the serviceability RedefineClasses tests are run in > tier1 and I'll rerun tier1. > > http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev > > Coleen > > On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >> Yikes. I missed that. Here's the beginning of tier1_runtime: >> >> ? L261: tier1_runtime = \ >> ? L262: ? runtime/ \ >> >> and here's the beginning of tier1_serviceability: >> >> ? L324 tier1_serviceability = \ >> ? L325?? serviceability/dcmd/compiler \ >> >> I should not have assumed. Does anyone know why tier1_serviceability >> isn't "start with everything" and then "filter out some stuff"? >> >> Dan >> >> >> On 3/15/19 8:06 PM, Chris Plummer wrote: >>> Hi Coleen, >>> >>> I think in TEST.groups you need to add >>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>> Otherwise the removes of specific tests isn't doing anything, and >>> tier1_serviceability won't run the other tests you moved from >>> tier1_runtime. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>> >>>> These always belonged in serviceability/jvmti.? Also, moved a >>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>> >>>> I ran these tests with make test >>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>> and they passed.? Tier1 testing is in progress. >>>> >>>> Thanks, >>>> Coleen >>> >>> >>> >> > From coleen.phillimore at oracle.com Sat Mar 16 00:32:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Mar 2019 20:32:26 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> Message-ID: Thanks Dan and Chris too. Coleen On 3/15/19 8:29 PM, Daniel D. Daugherty wrote: > Thumbs up. > > Dan > > > On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >> >> Hi, Okay I see how it works now.? I was wondering how to tell it to >> ever run the tests. >> >> I fixed it so that the serviceability RedefineClasses tests are run >> in tier1 and I'll rerun tier1. >> >> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >> >> Coleen >> >> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>> >>> ? L261: tier1_runtime = \ >>> ? L262: ? runtime/ \ >>> >>> and here's the beginning of tier1_serviceability: >>> >>> ? L324 tier1_serviceability = \ >>> ? L325?? serviceability/dcmd/compiler \ >>> >>> I should not have assumed. Does anyone know why tier1_serviceability >>> isn't "start with everything" and then "filter out some stuff"? >>> >>> Dan >>> >>> >>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>> Hi Coleen, >>>> >>>> I think in TEST.groups you need to add >>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>> Otherwise the removes of specific tests isn't doing anything, and >>>> tier1_serviceability won't run the other tests you moved from >>>> tier1_runtime. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>> >>>>> These always belonged in serviceability/jvmti.? Also, moved a >>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>> >>>>> I ran these tests with make test >>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>> and they passed.? Tier1 testing is in progress. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>>> >>> >> > From chris.plummer at oracle.com Sat Mar 16 00:42:49 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 15 Mar 2019 17:42:49 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> Message-ID: <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: > Thumbs up. > > Dan > > > On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >> >> Hi, Okay I see how it works now.? I was wondering how to tell it to >> ever run the tests. >> >> I fixed it so that the serviceability RedefineClasses tests are run >> in tier1 and I'll rerun tier1. >> >> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >> >> Coleen >> >> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>> >>> ? L261: tier1_runtime = \ >>> ? L262: ? runtime/ \ >>> >>> and here's the beginning of tier1_serviceability: >>> >>> ? L324 tier1_serviceability = \ >>> ? L325?? serviceability/dcmd/compiler \ >>> >>> I should not have assumed. Does anyone know why tier1_serviceability >>> isn't "start with everything" and then "filter out some stuff"? >>> >>> Dan >>> >>> >>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>> Hi Coleen, >>>> >>>> I think in TEST.groups you need to add >>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>> Otherwise the removes of specific tests isn't doing anything, and >>>> tier1_serviceability won't run the other tests you moved from >>>> tier1_runtime. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>> >>>>> These always belonged in serviceability/jvmti.? Also, moved a >>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>> >>>>> I ran these tests with make test >>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>> and they passed.? Tier1 testing is in progress. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>>> >>> >> > From chris.plummer at oracle.com Sat Mar 16 00:44:36 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 15 Mar 2019 17:44:36 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> Message-ID: <9ac9f12f-17c9-5aec-6a21-60a601cd8014@oracle.com> I'm not sure of the history of tier1_serviceability. It might be that only a couple of subdirs were initially included, so it was easier to do the included dirs rather than the excluded ones. Chris On 3/15/19 5:14 PM, Daniel D. Daugherty wrote: > Yikes. I missed that. Here's the beginning of tier1_runtime: > > ? L261: tier1_runtime = \ > ? L262: ? runtime/ \ > > and here's the beginning of tier1_serviceability: > > ? L324 tier1_serviceability = \ > ? L325?? serviceability/dcmd/compiler \ > > I should not have assumed. Does anyone know why tier1_serviceability > isn't "start with everything" and then "filter out some stuff"? > > Dan > > > On 3/15/19 8:06 PM, Chris Plummer wrote: >> Hi Coleen, >> >> I think in TEST.groups you need to add >> serviceability/jvmti/RedefineClasses to tier1_serviceability. >> Otherwise the removes of specific tests isn't doing anything, and >> tier1_serviceability won't run the other tests you moved from >> tier1_runtime. >> >> thanks, >> >> Chris >> >> >> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>> Summary: move tests out of runtime to jvmti/RedefineClasses >>> >>> These always belonged in serviceability/jvmti.? Also, moved a couple >>> tests within serviceability/jvmti to RedefineClasses also. >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>> >>> I ran these tests with make test >>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>> and they passed.? Tier1 testing is in progress. >>> >>> Thanks, >>> Coleen >> >> >> > From serguei.spitsyn at oracle.com Sat Mar 16 01:13:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Mar 2019 18:13:18 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> Message-ID: <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: > +1 > > On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >> Thumbs up. >> >> Dan >> >> >> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>> >>> Hi, Okay I see how it works now.? I was wondering how to tell it to >>> ever run the tests. >>> >>> I fixed it so that the serviceability RedefineClasses tests are run >>> in tier1 and I'll rerun tier1. >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>> >>> Coleen >>> >>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>> >>>> ? L261: tier1_runtime = \ >>>> ? L262: ? runtime/ \ >>>> >>>> and here's the beginning of tier1_serviceability: >>>> >>>> ? L324 tier1_serviceability = \ >>>> ? L325?? serviceability/dcmd/compiler \ >>>> >>>> I should not have assumed. Does anyone know why tier1_serviceability >>>> isn't "start with everything" and then "filter out some stuff"? >>>> >>>> Dan >>>> >>>> >>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>> Hi Coleen, >>>>> >>>>> I think in TEST.groups you need to add >>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>> Otherwise the removes of specific tests isn't doing anything, and >>>>> tier1_serviceability won't run the other tests you moved from >>>>> tier1_runtime. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>> >>>>>> These always belonged in serviceability/jvmti.? Also, moved a >>>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>>> >>>>>> open webrev at >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>> >>>>>> I ran these tests with make test >>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>> and they passed.? Tier1 testing is in progress. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> >>>>> >>>> >>> >> > > From matthias.baesken at sap.com Mon Mar 18 08:54:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Mar 2019 08:54:45 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: Message-ID: Hi JC, thanks for your comments . Second webrev , may I have a second review please ? http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ One question that came to my mind : do we still have to worry about the old-style C variable declaration order in eventHandlerVMInit after changing the test to if (environment == NULL) { ? } or is this resolved now on all platforms ? Best regards, Matthias From: Jean Christophe Beyler Sent: Freitag, 15. M?rz 2019 15:53 To: Baesken, Matthias Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit Hi Matthias, (Not an official reviewer :-)) http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/: - I would invert the test for the environment and do: if (environment == NULL) { abortJVM(jnienv, JPLIS_ERRORMESSAGE_CANNOTSTART ", getting JPLIS environment failed"); } and then just un-indent the rest of the code that was in the original if. http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/src/java.instrument/share/native/libinstrument/JPLISAgent.c.udiff.html - Nit: the message could consistently start with upper case or lower case :-) Apart from that, looks good to me :-) Thanks, Jc On Fri, Mar 15, 2019 at 2:19 AM Baesken, Matthias > wrote: Hello, please review the following change . It enhances the error messages in libinstrument in case initialization fails . ( I found the enhanced error messages helpful when analyzing jtreg failures on one of our platforms in the java/lang/instrument/PremainClass/PremainClassTest.java ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8220355 http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.0/ Thanks, Matthias -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 18 09:08:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Mar 2019 09:08:43 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: Message-ID: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> On 18/03/2019 08:54, Baesken, Matthias wrote: > > Hi JC, thanks for your comments . > > Second webrev , may I have a second review please ? > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ > I think this looks okay except I think "emergency" should be dropped from the message (and the existing comment). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Mon Mar 18 09:49:44 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 18 Mar 2019 17:49:44 +0800 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> Message-ID: <68d48655-4895-f037-80da-1f20085298b8@arm.com> Hi Jean Christophe, On 15/03/2019 22:47, Jean Christophe Beyler wrote: > > Not a reviewer but looks good to me :) I would perhaps put a comment > above the argument creation to note that the order is important, ie > something like: > "// Need to add the default arguments first to have explicit -Xmx8g > last, otherwise test will fail." Thanks. I've added this to the webrev: http://cr.openjdk.java.net/~ngasson/8220707/webrev.1/ Nick From matthias.baesken at sap.com Mon Mar 18 10:00:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Mar 2019 10:00:38 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> Message-ID: Hi Alan, thanks for the review . > I think this looks okay except I think "emergency" should be dropped from the message (and the existing comment). Are you referring to this ?emergency? : * First make our emergency fallback InternalError throwable. */ result = initializeFallbackError(jnienv); - jplis_assert(result); + jplis_assert_msg(result, "emergency fallback init failed"); If you prefer I could output just ?fallback init failed" - is this fine with you? Best regards, Matthias From: Alan Bateman Sent: Montag, 18. M?rz 2019 10:09 To: Baesken, Matthias ; Jean Christophe Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit On 18/03/2019 08:54, Baesken, Matthias wrote: Hi JC, thanks for your comments . Second webrev , may I have a second review please ? http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ I think this looks okay except I think "emergency" should be dropped from the message (and the existing comment). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Mon Mar 18 10:04:28 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 18 Mar 2019 18:04:28 +0800 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> Message-ID: <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> Hi Sharath, On 15/03/2019 23:32, Sharath Ballal wrote: > > Fix looks good. How have you tested it ? I ran the test using the "make test" target with and without JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail with that argument. Thanks, Nick From sgehwolf at redhat.com Mon Mar 18 10:06:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Mar 2019 11:06:02 +0100 Subject: [PING] RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: Hi, Could I get a review from an OpenJDK Reviewer for this, please? Bob is already OK with it. Thanks, Severin On Thu, 2019-03-14 at 13:58 -0400, Bob Vandette wrote: > The change looks good. Thanks for fixing this. > > I?d send this to core-libs (cc?d). > > Bob. > > > > On Mar 14, 2019, at 12:51 PM, Severin Gehwolf wrote: > > > > Hi, > > > > I'm not sure what the right list for Metrics.java[1] is. Assuming it's > > serviceability-dev: > > > > Please review this one-liner for for SubSystem.java which currently > > behaves differently from the native implementation in > > osContainer_linux.cpp. Please see the details in the bug. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220579 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8220579/01/webrev/ > > > > Testing: > > Manual testing of JDK-8217338 with Metrics.java support with/without > > this fix on Linux x86_64. Metrics tests and Docker tests continue to > > pass for fastdebug jvms (NOT for release jvms. see JDK-8220674, which > > was fun). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/641768acb12e/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java > > From adinn at redhat.com Mon Mar 18 10:14:56 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 18 Mar 2019 10:14:56 +0000 Subject: [PING] RFR: 8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp In-Reply-To: References: <8e1a66f748861591316e7411d4829d4096327a6d.camel@redhat.com> Message-ID: On 18/03/2019 10:06, Severin Gehwolf wrote: > Could I get a review from an OpenJDK Reviewer for this, please? Bob is > already OK with it. Yes, this is fine. Reviewed. regards, Andrew Dinn ----------- From Roger.Riggs at oracle.com Mon Mar 18 13:20:33 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 Mar 2019 09:20:33 -0400 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> Message-ID: Hi, InvocationAdapter.c: 581, remove the space after "(".? As long as that line is being changed. $.02, Roger On 03/18/2019 06:00 AM, Baesken, Matthias wrote: > > Hi Alan, thanks for the review . > > >I think this looks okay except I think "emergency" should be dropped > from the message (and the existing comment). > > Are you referring ?to? this ?emergency?? : > > ????? *? First make our emergency fallback InternalError throwable. > > ????? */ > > ???? result = initializeFallbackError(jnienv); > > - jplis_assert(result); > > + jplis_assert_msg(result, "emergency fallback init failed"); > > If you prefer I could? output? just? ?fallback init failed"?? - is > this fine with you? > > Best regards, Matthias > > *From:*Alan Bateman > *Sent:* Montag, 18. M?rz 2019 10:09 > *To:* Baesken, Matthias ; Jean Christophe > Beyler > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: 8220355: Improve assertion texts and exception > messages in eventHandlerVMInit > > > On 18/03/2019 08:54, Baesken, Matthias wrote: > > Hi JC, thanks for your comments . > > Second webrev , may I have a second review please ? > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ > > > > I think this looks okay except I think "emergency" should be dropped > from the message (and the existing comment). > > -Alan > From matthias.baesken at sap.com Mon Mar 18 14:34:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Mar 2019 14:34:35 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> Message-ID: Updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.2/ Alan + JC , may I add you as reviewers ? Thanks, Matthias From: Baesken, Matthias Sent: Montag, 18. M?rz 2019 11:01 To: 'Alan Bateman' ; Jean Christophe Beyler Cc: serviceability-dev at openjdk.java.net Subject: RE: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit Hi Alan, thanks for the review . > I think this looks okay except I think "emergency" should be dropped from the message (and the existing comment). Are you referring to this ?emergency? : * First make our emergency fallback InternalError throwable. */ result = initializeFallbackError(jnienv); - jplis_assert(result); + jplis_assert_msg(result, "emergency fallback init failed"); If you prefer I could output just ?fallback init failed" - is this fine with you? Best regards, Matthias From: Alan Bateman > Sent: Montag, 18. M?rz 2019 10:09 To: Baesken, Matthias >; Jean Christophe Beyler > Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit On 18/03/2019 08:54, Baesken, Matthias wrote: Hi JC, thanks for your comments . Second webrev , may I have a second review please ? http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ I think this looks okay except I think "emergency" should be dropped from the message (and the existing comment). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Mar 18 16:17:48 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 18 Mar 2019 09:17:48 -0700 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> Message-ID: Hi Nick, Looks good to me :) Jc On Mon, Mar 18, 2019 at 3:05 AM Nick Gasson wrote: > Hi Sharath, > > On 15/03/2019 23:32, Sharath Ballal wrote: > > > > Fix looks good. How have you tested it ? > > I ran the test using the "make test" target with and without > JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail with > that argument. > > Thanks, > Nick > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Mar 18 16:20:36 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 18 Mar 2019 09:20:36 -0700 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> Message-ID: Hi Matthias, You can add me (LGTM btw), I'm not an official reviewer (as per http://openjdk.java.net/census ) but Alan is :) Jc On Mon, Mar 18, 2019 at 7:34 AM Baesken, Matthias wrote: > Updated webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.2/ > > > > > > Alan + JC , may I add you as reviewers ? > > > > Thanks, Matthias > > > > > > *From:* Baesken, Matthias > *Sent:* Montag, 18. M?rz 2019 11:01 > *To:* 'Alan Bateman' ; Jean Christophe Beyler < > jcbeyler at google.com> > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* RE: RFR: 8220355: Improve assertion texts and exception > messages in eventHandlerVMInit > > > > Hi Alan, thanks for the review . > > > > > I think this looks okay except I think "emergency" should be dropped > from the message (and the existing comment). > > > > Are you referring to this ?emergency? : > > > > * First make our emergency fallback InternalError throwable. > > */ > > result = initializeFallbackError(jnienv); > > - jplis_assert(result); > > + jplis_assert_msg(result, "emergency fallback init failed"); > > > > > > If you prefer I could output just ?fallback init failed" - is this > fine with you? > > > > Best regards, Matthias > > > > > > *From:* Alan Bateman > *Sent:* Montag, 18. M?rz 2019 10:09 > *To:* Baesken, Matthias ; Jean Christophe > Beyler > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: 8220355: Improve assertion texts and exception > messages in eventHandlerVMInit > > > > > On 18/03/2019 08:54, Baesken, Matthias wrote: > > Hi JC, thanks for your comments . > > Second webrev , may I have a second review please ? > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.1/ > > > I think this looks okay except I think "emergency" should be dropped from > the message (and the existing comment). > > -Alan > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Mar 18 16:33:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Mar 2019 09:33:21 -0700 Subject: RFR (S) 8220512: Deoptimize redefinition functions that have dirty ICs In-Reply-To: <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> References: <00317af6-2a5f-5b32-408b-3bd888682c19@oracle.com> <15470b26-c400-1bc5-947f-985ee53cb002@oracle.com> <38cdb82d-c51e-b906-c1e4-2211715fa7b6@oracle.com> <5682cb5a-4b23-4ea5-6b3b-1471a0bc6499@oracle.com> Message-ID: Hi Coleen, Renaming looks good. Thanks, Serguei On 3/15/19 07:58, coleen.phillimore at oracle.com wrote: > > From some offline feedback, I changed the name of has_evol_ics => > has_evol_metadata and a couple of other small things.? I reran this > though builds and tier1 tests. > > Incremental: > http://cr.openjdk.java.net/~coleenp/2019/8220512.02.incr/webrev/index.html > Full: > http://cr.openjdk.java.net/~coleenp/2019/8220512.02/webrev/index.html > > Thanks, > Coleen > > On 3/14/19 3:09 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 3/14/19 2:24 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> It looks good to me. >>> >>> Just one minor suggestion: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev/src/hotspot/share/classfile/metadataOnStackMark.cpp.udiff.html >>> >>> - Threads::metadata_do(Metadata::mark_on_stack); >>> - CodeCache::metadata_do(Metadata::mark_on_stack); >>> + MetadataOnStackClosure mon_stack; >>> + Threads::metadata_do(&mon_stack); >>> + CodeCache::metadata_do(&mon_stack); >>> ?The 'mon_stack' can be associated with monitors. >>> ?How about to rename it to something like 'md_on_stack'? >> >> Okay, I'll change the name to md_on_stack. >> >> Thanks for the code review! >> Coleen >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/14/19 10:40, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk ICs to determine whether nmethods are dependent on >>>> redefined classes. >>>> >>>> See bug for more details.? Tested with redefinition tests: >>>> >>>> #redefinition tests. >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>> >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> make test TEST=open/test/jdk/com/sun/jdi >&jtreg.jdi.out >>>> >>>> hs-tier1-6 as well as java/lang/instrument tests with -Xcomp. >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8220512.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220512 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From Alan.Bateman at oracle.com Mon Mar 18 16:47:48 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Mar 2019 16:47:48 +0000 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> Message-ID: <9cfc5bf8-021f-bb45-1507-f41452a32097@oracle.com> On 18/03/2019 14:34, Baesken, Matthias wrote: > > Updated webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8220355.2/ > > Alan + JC , may I add you as reviewers ? > > Yes, looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Mar 18 16:47:23 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Mar 2019 09:47:23 -0700 Subject: RFR: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: Message-ID: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> Hi Daniil, The JVMTI phase can change in the middle of callback work after the check you added. I'd suggest to lock a raw monitor across the callbacks to make them atomic. Thank you for taking care about this issue! Thanks, Serguei On 3/15/19 16:08, Daniil Titov wrote: > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > -Daniil > > From serguei.spitsyn at oracle.com Mon Mar 18 17:13:24 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Mar 2019 10:13:24 -0700 Subject: RFR: 8220355: Improve assertion texts and exception messages in eventHandlerVMInit In-Reply-To: <9cfc5bf8-021f-bb45-1507-f41452a32097@oracle.com> References: <9edeb869-bb55-6a3b-88c9-e28e750a6be5@oracle.com> <9cfc5bf8-021f-bb45-1507-f41452a32097@oracle.com> Message-ID: <0532ee5f-1e60-a46a-64ce-d5e118df1a5b@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Mar 19 00:12:08 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 18 Mar 2019 17:12:08 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: Message-ID: <3FE3307F-9B49-4281-B14E-348540438A7A@oracle.com> Hi JC, You are right, the synchronization is required across callbacks,? otherwise JVMTI phase could change in the middle of a callback. I will send a new version of the patch soon. Thanks! --Daniil From: Jean Christophe Beyler Date: Friday, March 15, 2019 at 4:45 PM To: Daniil Titov Cc: OpenJDK Serviceability Subject: Re: RFR: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash Hi Daniil, Is it not possible that the VMDeath would happen later in the case of: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/FramePop/framepop002/framepop002.cpp.html For example, that callbacks are not yet disabled when we pass the new test: + if (!callbacksEnabled) { + return; + } But gets disabled right after? (this is for my own understanding of what is possible or not :-)) Thanks! Jc On Fri, Mar 15, 2019 at 4:08 PM Daniil Titov wrote: Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! -Daniil -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Mar 19 01:58:38 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 18 Mar 2019 18:58:38 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> Message-ID: <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> Hi Serguei and JC, Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! --Daniil ?On 3/18/19, 9:47 AM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, The JVMTI phase can change in the middle of callback work after the check you added. I'd suggest to lock a raw monitor across the callbacks to make them atomic. Thank you for taking care about this issue! Thanks, Serguei On 3/15/19 16:08, Daniil Titov wrote: > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > -Daniil > > From coleen.phillimore at oracle.com Tue Mar 19 11:39:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Mar 2019 07:39:08 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> Message-ID: <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> Sorry about this not being trivial after all.? Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > +1 > > Thank you for taking care about it! > -Serguei > > > On 3/15/19 5:42 PM, Chris Plummer wrote: >> +1 >> >> On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >>> Thumbs up. >>> >>> Dan >>> >>> >>> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi, Okay I see how it works now.? I was wondering how to tell it to >>>> ever run the tests. >>>> >>>> I fixed it so that the serviceability RedefineClasses tests are run >>>> in tier1 and I'll rerun tier1. >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>>> >>>> Coleen >>>> >>>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>>> >>>>> ? L261: tier1_runtime = \ >>>>> ? L262: ? runtime/ \ >>>>> >>>>> and here's the beginning of tier1_serviceability: >>>>> >>>>> ? L324 tier1_serviceability = \ >>>>> ? L325?? serviceability/dcmd/compiler \ >>>>> >>>>> I should not have assumed. Does anyone know why tier1_serviceability >>>>> isn't "start with everything" and then "filter out some stuff"? >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> I think in TEST.groups you need to add >>>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>>> Otherwise the removes of specific tests isn't doing anything, and >>>>>> tier1_serviceability won't run the other tests you moved from >>>>>> tier1_runtime. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>>> >>>>>>> These always belonged in serviceability/jvmti.? Also, moved a >>>>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>>> >>>>>>> I ran these tests with make test >>>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>>> and they passed.? Tier1 testing is in progress. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > From gary.adams at oracle.com Tue Mar 19 12:22:49 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 19 Mar 2019 08:22:49 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out Message-ID: <5C90DF19.3050707@oracle.com> After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++ b/test/jdk/TEST.ROOT @@ -22,7 +22,11 @@ javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote \ +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb sun/tools/jhsdb/heapconfig \ +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack sun/tools/jstat \ +com/sun/tools/attach sun/security/mscapi java/util/stream java/util/Arrays/largeMemory \ +java/util/BitSet/stream javax/rmi # Group definitions groups=TEST.groups Failures were observed in the following tests. sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts3.sh sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh sun/tools/jstatd/TestJstatdDefaults.java sun/tools/jstatd/TestJstatdServer.java sun/tools/jstatd/TestJstatdPort.java sun/tools/jstatd/TestJstatdExternalRegistry.java I'll investigate those failures some more, but I don't think they are related to the change to exclusiveAccess.dirs. Issues: https://bugs.openjdk.java.net/browse/JDK-8220295 https://bugs.openjdk.java.net/browse/JDK-8220242 At this point just looking for feedback, if this is a reasonable direction to deal with the intermittent timeouts with theses tests to reduce the concurrency with other attaching tests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Mar 19 14:02:22 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Mar 2019 10:02:22 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> Message-ID: <1e9011f8-1659-65a7-85b8-d3a39a6e060f@oracle.com> On 3/19/19 7:39 AM, coleen.phillimore at oracle.com wrote: > > Sorry about this not being trivial after all.? Two of the appcds tests > had the old pathname in them: > > http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev test/hotspot/jtreg/TEST.groups ??? No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java ??? No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java ??? L27:? * @summary Run /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to ??????? You need to update this path also. Did you grep for the old test names to make sure there are no other stale references? Dan > > Now tier1-3 pass. > > thanks, > Coleen > > On 3/15/19 9:13 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> +1 >> >> Thank you for taking care about it! >> -Serguei >> >> >> On 3/15/19 5:42 PM, Chris Plummer wrote: >>> +1 >>> >>> On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >>>> Thumbs up. >>>> >>>> Dan >>>> >>>> >>>> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> Hi, Okay I see how it works now.? I was wondering how to tell it >>>>> to ever run the tests. >>>>> >>>>> I fixed it so that the serviceability RedefineClasses tests are >>>>> run in tier1 and I'll rerun tier1. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>>>> >>>>> Coleen >>>>> >>>>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>>>> >>>>>> ? L261: tier1_runtime = \ >>>>>> ? L262: ? runtime/ \ >>>>>> >>>>>> and here's the beginning of tier1_serviceability: >>>>>> >>>>>> ? L324 tier1_serviceability = \ >>>>>> ? L325?? serviceability/dcmd/compiler \ >>>>>> >>>>>> I should not have assumed. Does anyone know why tier1_serviceability >>>>>> isn't "start with everything" and then "filter out some stuff"? >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> I think in TEST.groups you need to add >>>>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>>>> Otherwise the removes of specific tests isn't doing anything, >>>>>>> and tier1_serviceability won't run the other tests you moved >>>>>>> from tier1_runtime. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>>>> >>>>>>>> These always belonged in serviceability/jvmti. Also, moved a >>>>>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>>>> >>>>>>>> I ran these tests with make test >>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>>>> and they passed.? Tier1 testing is in progress. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From coleen.phillimore at oracle.com Tue Mar 19 14:25:55 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Mar 2019 10:25:55 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <1e9011f8-1659-65a7-85b8-d3a39a6e060f@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> <1e9011f8-1659-65a7-85b8-d3a39a6e060f@oracle.com> Message-ID: On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: > On 3/19/19 7:39 AM, coleen.phillimore at oracle.com wrote: >> >> Sorry about this not being trivial after all.? Two of the appcds >> tests had the old pathname in them: >> >> http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev > > test/hotspot/jtreg/TEST.groups > ??? No comments. > > test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java > ??? No comments. > > test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java > > ??? L27:? * @summary Run /runtime/RedefineTests/RedefineRunningMethods > in AppCDS mode to > ??????? You need to update this path also. $ grep -r RedefineTests hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This test is simplified version of runtime/RedefineTests/RedefineRunningMethods.java. hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS mode to I fixed these in comments and summary too.? Thanks! Coleen > > Did you grep for the old test names to make sure there are no > other stale references? > > Dan > > > >> >> Now tier1-3 pass. >> >> thanks, >> Coleen >> >> On 3/15/19 9:13 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> +1 >>> >>> Thank you for taking care about it! >>> -Serguei >>> >>> >>> On 3/15/19 5:42 PM, Chris Plummer wrote: >>>> +1 >>>> >>>> On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >>>>> Thumbs up. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> Hi, Okay I see how it works now.? I was wondering how to tell it >>>>>> to ever run the tests. >>>>>> >>>>>> I fixed it so that the serviceability RedefineClasses tests are >>>>>> run in tier1 and I'll rerun tier1. >>>>>> >>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>>>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>>>>> >>>>>>> ? L261: tier1_runtime = \ >>>>>>> ? L262: ? runtime/ \ >>>>>>> >>>>>>> and here's the beginning of tier1_serviceability: >>>>>>> >>>>>>> ? L324 tier1_serviceability = \ >>>>>>> ? L325?? serviceability/dcmd/compiler \ >>>>>>> >>>>>>> I should not have assumed. Does anyone know why >>>>>>> tier1_serviceability >>>>>>> isn't "start with everything" and then "filter out some stuff"? >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> I think in TEST.groups you need to add >>>>>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>>>>> Otherwise the removes of specific tests isn't doing anything, >>>>>>>> and tier1_serviceability won't run the other tests you moved >>>>>>>> from tier1_runtime. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>>>>> >>>>>>>>> These always belonged in serviceability/jvmti. Also, moved a >>>>>>>>> couple tests within serviceability/jvmti to RedefineClasses also. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>>>>> >>>>>>>>> I ran these tests with make test >>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>>>>> and they passed.? Tier1 testing is in progress. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Mar 19 16:08:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Mar 2019 09:08:12 -0700 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> <1e9011f8-1659-65a7-85b8-d3a39a6e060f@oracle.com> Message-ID: <91b89319-7932-6b1b-4632-141d333f4f31@oracle.com> Hi Coleen, I'm Okay with this update. I did not know about the appcds tests using the runtime/RedefineTest test names. Thanks, Serguei On 3/19/19 07:25, coleen.phillimore at oracle.com wrote: > > > On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: >> On 3/19/19 7:39 AM, coleen.phillimore at oracle.com wrote: >>> >>> Sorry about this not being trivial after all.? Two of the appcds >>> tests had the old pathname in them: >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev >> >> test/hotspot/jtreg/TEST.groups >> ??? No comments. >> >> test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java >> ??? No comments. >> >> test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java >> >> ??? L27:? * @summary Run >> /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to >> ??????? You need to update this path also. > > $ grep -r RedefineTests > hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This > test is simplified version of > runtime/RedefineTests/RedefineRunningMethods.java. > hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: > * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS > mode to > > I fixed these in comments and summary too.? Thanks! > > Coleen > >> >> Did you grep for the old test names to make sure there are no >> other stale references? >> >> Dan >> >> >> >>> >>> Now tier1-3 pass. >>> >>> thanks, >>> Coleen >>> >>> On 3/15/19 9:13 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> +1 >>>> >>>> Thank you for taking care about it! >>>> -Serguei >>>> >>>> >>>> On 3/15/19 5:42 PM, Chris Plummer wrote: >>>>> +1 >>>>> >>>>> On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >>>>>> Thumbs up. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> Hi, Okay I see how it works now.? I was wondering how to tell it >>>>>>> to ever run the tests. >>>>>>> >>>>>>> I fixed it so that the serviceability RedefineClasses tests are >>>>>>> run in tier1 and I'll rerun tier1. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>>>>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>>>>>> >>>>>>>> ? L261: tier1_runtime = \ >>>>>>>> ? L262: ? runtime/ \ >>>>>>>> >>>>>>>> and here's the beginning of tier1_serviceability: >>>>>>>> >>>>>>>> ? L324 tier1_serviceability = \ >>>>>>>> ? L325?? serviceability/dcmd/compiler \ >>>>>>>> >>>>>>>> I should not have assumed. Does anyone know why >>>>>>>> tier1_serviceability >>>>>>>> isn't "start with everything" and then "filter out some stuff"? >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> I think in TEST.groups you need to add >>>>>>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>>>>>> Otherwise the removes of specific tests isn't doing anything, >>>>>>>>> and tier1_serviceability won't run the other tests you moved >>>>>>>>> from tier1_runtime. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>>>>>> >>>>>>>>>> These always belonged in serviceability/jvmti. Also, moved a >>>>>>>>>> couple tests within serviceability/jvmti to RedefineClasses >>>>>>>>>> also. >>>>>>>>>> >>>>>>>>>> open webrev at >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>>>>>> >>>>>>>>>> I ran these tests with make test >>>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>>>>>> and they passed.? Tier1 testing is in progress. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Mar 19 17:03:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Mar 2019 13:03:02 -0400 Subject: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability In-Reply-To: <91b89319-7932-6b1b-4632-141d333f4f31@oracle.com> References: <8beca376-2a28-f9c9-ad05-d1bb6eadd58e@oracle.com> <6998114b-307b-face-6b23-051a3e9d6954@oracle.com> <0c558adc-23b3-c3df-3255-eff1930efc05@oracle.com> <56cd6b41-d3a2-e13a-c1a8-78cbd35b4adc@oracle.com> <9a56b409-d307-9673-5699-e781d0a5e610@oracle.com> <1c308cd9-6453-5d5c-0dd3-1a439a8a880a@oracle.com> <91630003-fa84-e012-9ed6-3b57c086ba7f@oracle.com> <58df4210-0058-e4ba-1d46-0d801ecf152c@oracle.com> <1e9011f8-1659-65a7-85b8-d3a39a6e060f@oracle.com> <91b89319-7932-6b1b-4632-141d333f4f31@oracle.com> Message-ID: <9381f257-eaed-c800-54ad-d15cebdf6c43@oracle.com> Thanks Serguei! Thanks everyone for the code reviews. Coleen On 3/19/19 12:08 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > I'm Okay with this update. > I did not know about the appcds tests using the runtime/RedefineTest > test names. > > Thanks, > Serguei > > > On 3/19/19 07:25, coleen.phillimore at oracle.com wrote: >> >> >> On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: >>> On 3/19/19 7:39 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> Sorry about this not being trivial after all.? Two of the appcds >>>> tests had the old pathname in them: >>>> >>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev >>> >>> test/hotspot/jtreg/TEST.groups >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java >>> >>> ??? L27:? * @summary Run >>> /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to >>> ??????? You need to update this path also. >> >> $ grep -r RedefineTests >> hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This >> test is simplified version of >> runtime/RedefineTests/RedefineRunningMethods.java. >> hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: >> * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS >> mode to >> >> I fixed these in comments and summary too.? Thanks! >> >> Coleen >> >>> >>> Did you grep for the old test names to make sure there are no >>> other stale references? >>> >>> Dan >>> >>> >>> >>>> >>>> Now tier1-3 pass. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 3/15/19 9:13 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen, >>>>> >>>>> +1 >>>>> >>>>> Thank you for taking care about it! >>>>> -Serguei >>>>> >>>>> >>>>> On 3/15/19 5:42 PM, Chris Plummer wrote: >>>>>> +1 >>>>>> >>>>>> On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: >>>>>>> Thumbs up. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 3/15/19 8:25 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>> Hi, Okay I see how it works now.? I was wondering how to tell >>>>>>>> it to ever run the tests. >>>>>>>> >>>>>>>> I fixed it so that the serviceability RedefineClasses tests are >>>>>>>> run in tier1 and I'll rerun tier1. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: >>>>>>>>> Yikes. I missed that. Here's the beginning of tier1_runtime: >>>>>>>>> >>>>>>>>> ? L261: tier1_runtime = \ >>>>>>>>> ? L262: ? runtime/ \ >>>>>>>>> >>>>>>>>> and here's the beginning of tier1_serviceability: >>>>>>>>> >>>>>>>>> ? L324 tier1_serviceability = \ >>>>>>>>> ? L325?? serviceability/dcmd/compiler \ >>>>>>>>> >>>>>>>>> I should not have assumed. Does anyone know why >>>>>>>>> tier1_serviceability >>>>>>>>> isn't "start with everything" and then "filter out some stuff"? >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/15/19 8:06 PM, Chris Plummer wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> I think in TEST.groups you need to add >>>>>>>>>> serviceability/jvmti/RedefineClasses to tier1_serviceability. >>>>>>>>>> Otherwise the removes of specific tests isn't doing anything, >>>>>>>>>> and tier1_serviceability won't run the other tests you moved >>>>>>>>>> from tier1_runtime. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/15/19 4:14 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> Summary: move tests out of runtime to jvmti/RedefineClasses >>>>>>>>>>> >>>>>>>>>>> These always belonged in serviceability/jvmti. Also, moved a >>>>>>>>>>> couple tests within serviceability/jvmti to RedefineClasses >>>>>>>>>>> also. >>>>>>>>>>> >>>>>>>>>>> open webrev at >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8220744 >>>>>>>>>>> >>>>>>>>>>> I ran these tests with make test >>>>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >>>>>>>>>>> and they passed.? Tier1 testing is in progress. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From gary.adams at oracle.com Tue Mar 19 18:39:07 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 19 Mar 2019 14:39:07 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <5C90DF19.3050707@oracle.com> References: <5C90DF19.3050707@oracle.com> Message-ID: <5C91374B.5060305@oracle.com> A quick follow up on the jstat test failures. On the failed runs the output looks like this : ----------messages:(3/127)---------- command: shell jstatLineCounts4.sh reason: User specified action: run shell jstatLineCounts4.sh elapsed time (seconds): 7.496 ----------System.out:(13/1261)---------- S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 The awk scripts used to check the output are not aware a dash '-' is allowed the metaspace column. Here is a quick stab to allow the dashes. Is anyone aware of recent changes in the gcutil output? diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk b/test/jdk/sun/tools/jstat/lineCounts3.awk --- a/test/jdk/sun/tools/jstat/lineCounts3.awk +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk @@ -23,7 +23,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { datalines++; } diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk b/test/jdk/sun/tools/jstat/lineCounts4.awk --- a/test/jdk/sun/tools/jstat/lineCounts4.awk +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk @@ -26,7 +26,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { if (headerlines == 2) { datalines2++; } On 3/19/19, 8:22 AM, Gary Adams wrote: > After 1000 testruns on {solaris,linux,windows,macosx} debug builds > running > test/jdk/sun/tools > test/jdk/com/sun/tools/attach > > with this change, no failures were observed in TestJps or TempDirTest. > > diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT > --- a/test/jdk/TEST.ROOT > +++ b/test/jdk/TEST.ROOT > @@ -22,7 +22,11 @@ > javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation > java/lang/ProcessHandle > > # Tests that cannot run concurrently > -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs > sun/management/jmxremote sun/tools/jstatd sun/security/mscapi > java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream > javax/rmi > +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs > sun/management/jmxremote \ > +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb > sun/tools/jhsdb/heapconfig \ > +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack > sun/tools/jstat \ > +com/sun/tools/attach sun/security/mscapi java/util/stream > java/util/Arrays/largeMemory \ > +java/util/BitSet/stream javax/rmi > # Group definitions > groups=TEST.groups > > Failures were observed in the following tests. > sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: > 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] > sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: > 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] > sun/tools/jstat/jstatLineCounts3.sh > sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: > 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] > sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: > 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] > sun/tools/jstat/jstatLineCounts4.sh > sun/tools/jstatd/TestJstatdDefaults.java > sun/tools/jstatd/TestJstatdServer.java > sun/tools/jstatd/TestJstatdPort.java > sun/tools/jstatd/TestJstatdExternalRegistry.java > > I'll investigate those failures some more, but I don't think they are > related to the change to exclusiveAccess.dirs. > > Issues: > https://bugs.openjdk.java.net/browse/JDK-8220295 > https://bugs.openjdk.java.net/browse/JDK-8220242 > > At this point just looking for feedback, if this is a reasonable direction > to deal with the intermittent timeouts with theses tests to reduce the > concurrency with other attaching tests. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Mar 19 21:30:43 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Mar 2019 14:30:43 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <5C90DF19.3050707@oracle.com> References: <5C90DF19.3050707@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Mar 19 22:07:04 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Mar 2019 15:07:04 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <5C91374B.5060305@oracle.com> References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> Message-ID: <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Mar 20 02:17:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Mar 2019 19:17:14 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> Message-ID: <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> Hi Daniil, I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. Otherwise, looks good to me. Another approachcould be to disable event notifications in VMDeath callback with: ? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); ? . . . Thanks, Serguei On 3/18/19 6:58 PM, Daniil Titov wrote: > Hi Serguei and JC, > > Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > --Daniil > > > ?On 3/18/19, 9:47 AM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > The JVMTI phase can change in the middle of callback work after the > check you added. > I'd suggest to lock a raw monitor across the callbacks to make them atomic. > > Thank you for taking care about this issue! > > Thanks, > Serguei > > > > On 3/15/19 16:08, Daniil Titov wrote: > > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > -Daniil > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Wed Mar 20 07:11:08 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 20 Mar 2019 15:11:08 +0800 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> Message-ID: <4fd91718-fee9-e46e-5d3f-38e8a4b2fd0b@arm.com> Thanks! Do I need to get any more official Reviewers to look at this before it's OK to push? Nick On 19/03/2019 00:17, Jean Christophe Beyler wrote: > Hi Nick, > > Looks good to me :) > Jc > > On Mon, Mar 18, 2019 at 3:05 AM Nick Gasson > wrote: > > Hi Sharath, > > On 15/03/2019 23:32, Sharath Ballal wrote: > > > > Fix looks good.? How have you tested it ? > > I ran the test using the "make test" target with and without > JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail with > that argument. > > Thanks, > Nick > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Wed Mar 20 12:26:51 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 20 Mar 2019 08:26:51 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> Message-ID: <5C92318B.2030507@oracle.com> I think I have found the source of the dash. sun/tools/jstat/RowClosure.java sets the NaN value to "-". That should be fine. It just means in the jstat output tests need to account for the possibility. ... On 3/19/19, 6:07 PM, Chris Plummer wrote: > The presence of the '-' sounds familiar. I recall reading about it in > a review. I know I did a review for these tests that impacted the > output, but I don't see it introducing a '-' anywhere. See > JDK-8202466. However, that bug references JDK-8199519, which caused > problems by changing a value in the output from a '-' to a 0: > > --- a/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java Wed Apr 25 17:50:32 2018 -0400 > +++ b/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java Thu Apr 26 09:45:47 2018 +0900 > @@ -74,10 +74,18 @@ > assertThat(GCT>= 0, "Incorrect time value for GCT"); > assertThat(GCT>= YGCT, "GCT< YGCT (total garbage collection time< young generation garbage collection time)"); > > - int CGC = getIntValue("CGC"); > - float CGCT = getFloatValue("CGCT"); > - assertThat(CGCT>= 0, "Incorrect time value for CGCT"); > + int CGC = 0; > + float CGCT = 0.0f; > + try { > + CGC = getIntValue("CGC"); > + } catch (NumberFormatException e) { > + if (!e.getMessage().equals("Unparseable number: \"-\"")) { > + throw e; > + } > + } > if (CGC> 0) { > + CGCT = getFloatValue("CGCT"); > + assertThat(CGCT>= 0, "Incorrect time value for CGCT"); > assertThat(CGCT> 0, "Number of concurrent GC events is " + CGC + ", but CGCT is 0"); > } > > I'm not sure if any of this is related to what you are seeing. > > Chris > > On 3/19/19 11:39 AM, Gary Adams wrote: >> A quick follow up on the jstat test failures. >> >> On the failed runs the output looks like this : >> >> ----------messages:(3/127)---------- >> command: shell jstatLineCounts4.sh >> reason: User specified action: run shell jstatLineCounts4.sh >> elapsed time (seconds): 7.496 >> ----------System.out:(13/1261)---------- >> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> >> The awk scripts used to check the output are not aware a dash '-' is >> allowed the metaspace column. >> Here is a quick stab to allow the dashes. >> Is anyone aware of recent changes in the gcutil output? >> >> diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk >> b/test/jdk/sun/tools/jstat/lineCounts3.awk >> --- a/test/jdk/sun/tools/jstat/lineCounts3.awk >> +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk >> @@ -23,7 +23,7 @@ >> headerlines++; >> } >> >> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { >> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { >> datalines++; >> } >> >> diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk >> b/test/jdk/sun/tools/jstat/lineCounts4.awk >> --- a/test/jdk/sun/tools/jstat/lineCounts4.awk >> +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk >> @@ -26,7 +26,7 @@ >> headerlines++; >> } >> >> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { >> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { >> if (headerlines == 2) { >> datalines2++; >> } >> >> >> On 3/19/19, 8:22 AM, Gary Adams wrote: >>> After 1000 testruns on {solaris,linux,windows,macosx} debug builds >>> running >>> test/jdk/sun/tools >>> test/jdk/com/sun/tools/attach >>> >>> with this change, no failures were observed in TestJps or TempDirTest. >>> >>> diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT >>> --- a/test/jdk/TEST.ROOT >>> +++ b/test/jdk/TEST.ROOT >>> @@ -22,7 +22,11 @@ >>> javax/management sun/awt sun/java2d >>> javax/xml/jaxp/testng/validation java/lang/ProcessHandle >>> >>> # Tests that cannot run concurrently >>> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi >>> java/util/stream java/util/Arrays/largeMemory >>> java/util/BitSet/stream javax/rmi >>> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>> sun/management/jmxremote \ >>> +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb >>> sun/tools/jhsdb/heapconfig \ >>> +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack >>> sun/tools/jstat \ >>> +com/sun/tools/attach sun/security/mscapi java/util/stream >>> java/util/Arrays/largeMemory \ >>> +java/util/BitSet/stream javax/rmi >>> # Group definitions >>> groups=TEST.groups >>> >>> Failures were observed in the following tests. >>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>> sun/tools/jstat/jstatLineCounts3.sh >>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>> sun/tools/jstat/jstatLineCounts4.sh >>> sun/tools/jstatd/TestJstatdDefaults.java >>> sun/tools/jstatd/TestJstatdServer.java >>> sun/tools/jstatd/TestJstatdPort.java >>> sun/tools/jstatd/TestJstatdExternalRegistry.java >>> >>> I'll investigate those failures some more, but I don't think they are >>> related to the change to exclusiveAccess.dirs. >>> >>> Issues: >>> https://bugs.openjdk.java.net/browse/JDK-8220295 >>> https://bugs.openjdk.java.net/browse/JDK-8220242 >>> >>> At this point just looking for feedback, if this is a reasonable >>> direction >>> to deal with the intermittent timeouts with theses tests to reduce the >>> concurrency with other attaching tests. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Wed Mar 20 21:58:48 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 20 Mar 2019 14:58:48 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> Message-ID: Hi Serguei, I think that just disabling event notifications inside VMDeath callback still leaves a small window for VMDeath callback being called after the classload callback is called (or about being called) but before it enters a raw monitor. Thus I decided to follow your original suggestion and restore volatile modifier for callbacksEnabled. Please review a new version of the patch. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03/ Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! Best regards, Daniil From: Organization: Oracle Corporation Date: Tuesday, March 19, 2019 at 7:17 PM To: Daniil Titov , OpenJDK Serviceability , Jean Christophe Beyler Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash Hi Daniil, I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. Otherwise, looks good to me. Another approach could be to disable event notifications in VMDeath callback with: ? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); ? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); ? . . . Thanks, Serguei On 3/18/19 6:58 PM, Daniil Titov wrote: Hi Serguei and JC, Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! --Daniil ?On 3/18/19, 9:47 AM, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: Hi Daniil, The JVMTI phase can change in the middle of callback work after the check you added. I'd suggest to lock a raw monitor across the callbacks to make them atomic. Thank you for taking care about this issue! Thanks, Serguei On 3/15/19 16:08, Daniil Titov wrote: > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > -Daniil > > From serguei.spitsyn at oracle.com Wed Mar 20 22:39:54 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Mar 2019 15:39:54 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> Message-ID: <2cf4b4a6-b699-6fd9-5169-34b5fc707356@oracle.com> Hi Daniil, No chance for it if you lock a raw monitor in the event callbacks. Thanks, Serguei On 3/20/19 14:58, Daniil Titov wrote: > Hi Serguei, > > I think that just disabling event notifications inside VMDeath callback still leaves a small window for VMDeath callback being called after the classload callback is called (or about being called) but before it enters a raw monitor. Thus I decided to follow your original suggestion and restore volatile modifier for callbacksEnabled. Please review a new version of the patch. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03/ > Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > > Best regards, > Daniil > > > > From: > Organization: Oracle Corporation > Date: Tuesday, March 19, 2019 at 7:17 PM > To: Daniil Titov , OpenJDK Serviceability , Jean Christophe Beyler > Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash > > Hi Daniil, > > I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. > Otherwise, looks good to me. > > > Another approach could be to disable event notifications in VMDeath callback with: > ? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); > ? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); > ? . . . > > Thanks, > Serguei > > On 3/18/19 6:58 PM, Daniil Titov wrote: > Hi Serguei and JC, > > Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > --Daniil > > > ?On 3/18/19, 9:47 AM, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > The JVMTI phase can change in the middle of callback work after the > check you added. > I'd suggest to lock a raw monitor across the callbacks to make them atomic. > > Thank you for taking care about this issue! > > Thanks, > Serguei > > > > On 3/15/19 16:08, Daniil Titov wrote: > > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > -Daniil > > > > > > > > > > > > From daniil.x.titov at oracle.com Wed Mar 20 23:35:57 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 20 Mar 2019 16:35:57 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: <2cf4b4a6-b699-6fd9-5169-34b5fc707356@oracle.com> References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> <2cf4b4a6-b699-6fd9-5169-34b5fc707356@oracle.com> Message-ID: Hi Serguei, I could be missing something but as I understood the suggested alternative approach was to not introduce the callbacksEnabled flag and instead just unregister other callbacks inside VMDeath callback. My concern was the case when one thread is on line 1302 (it is going to call a class loaded callback), while another thread just entered VMDeath callback. Without callbacksEnabled flag the first thread will enter the callback and wait on the raw monitor acquired by VMDeath callback thread, after that it will continue and call JVMTI API that might throw WRONG_PHASE error if by this time the second thread already returned from the VMDeath callback and changed the JVMTI phase. 1277 void JvmtiExport::post_class_load(JavaThread *thread, Klass* klass) { 1278 if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { 1279 return; 1280 } 1281 HandleMark hm(thread); 1282 1283 EVT_TRIG_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Trg Class Load triggered", 1284 JvmtiTrace::safe_get_thread_name(thread))); 1285 JvmtiThreadState* state = thread->jvmti_thread_state(); 1286 if (state == NULL) { 1287 return; 1288 } 1289 JvmtiEnvThreadStateIterator it(state); 1290 for (JvmtiEnvThreadState* ets = it.first(); ets != NULL; ets = it.next(ets)) { 1291 if (ets->is_enabled(JVMTI_EVENT_CLASS_LOAD)) { 1292 JvmtiEnv *env = ets->get_env(); 1293 if (env->phase() == JVMTI_PHASE_PRIMORDIAL) { 1294 continue; 1295 } 1296 EVT_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Evt Class Load sent %s", 1297 JvmtiTrace::safe_get_thread_name(thread), 1298 klass==NULL? "NULL" : klass->external_name() )); 1299 JvmtiClassEventMark jem(thread, klass); 1300 JvmtiJavaThreadEventTransition jet(thread); 1301 jvmtiEventClassLoad callback = env->callbacks()->ClassLoad; 1302 if (callback != NULL) { 1303 (*callback)(env->jvmti_external(), jem.jni_env(), jem.jni_thread(), jem.jni_class()); 1304 } 1305 } 1306 } 1307 } Thanks! --Daniil ?On 3/20/19, 3:40 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, No chance for it if you lock a raw monitor in the event callbacks. Thanks, Serguei On 3/20/19 14:58, Daniil Titov wrote: > Hi Serguei, > > I think that just disabling event notifications inside VMDeath callback still leaves a small window for VMDeath callback being called after the classload callback is called (or about being called) but before it enters a raw monitor. Thus I decided to follow your original suggestion and restore volatile modifier for callbacksEnabled. Please review a new version of the patch. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03/ > Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > > Best regards, > Daniil > > > > From: > Organization: Oracle Corporation > Date: Tuesday, March 19, 2019 at 7:17 PM > To: Daniil Titov , OpenJDK Serviceability , Jean Christophe Beyler > Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash > > Hi Daniil, > > I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. > Otherwise, looks good to me. > > > Another approach could be to disable event notifications in VMDeath callback with: > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); > . . . > > Thanks, > Serguei > > On 3/18/19 6:58 PM, Daniil Titov wrote: > Hi Serguei and JC, > > Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > --Daniil > > > ?On 3/18/19, 9:47 AM, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > The JVMTI phase can change in the middle of callback work after the > check you added. > I'd suggest to lock a raw monitor across the callbacks to make them atomic. > > Thank you for taking care about this issue! > > Thanks, > Serguei > > > > On 3/15/19 16:08, Daniil Titov wrote: > > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > -Daniil > > > > > > > > > > > > From serguei.spitsyn at oracle.com Wed Mar 20 23:50:49 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Mar 2019 16:50:49 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> <2cf4b4a6-b699-6fd9-5169-34b5fc707356@oracle.com> Message-ID: <8a6ebfa4-4750-cdf7-86f8-cd1f54a8f2c7@oracle.com> Hi Daniil, You are right, there is a hole for this. It can be easily fixed if the callbacks check phase at the beginning. But I don't think this would be simpler than your current fix. As I already mentioned, I'm Okay with the fix you have now. I'm still thinking on how to fix this on the JVMTI level. Thanks, Serguei On 3/20/19 16:35, Daniil Titov wrote: > Hi Serguei, > > I could be missing something but as I understood the suggested alternative approach was to not introduce the callbacksEnabled flag and instead just unregister other callbacks inside VMDeath callback. My concern was the case when one thread is on line 1302 (it is going to call a class loaded callback), while another thread just entered VMDeath callback. Without callbacksEnabled flag the first thread will enter the callback and wait on the raw monitor acquired by VMDeath callback thread, after that it will continue and call JVMTI API that might throw WRONG_PHASE error if by this time the second thread already returned from the VMDeath callback and changed the JVMTI phase. > > 1277 void JvmtiExport::post_class_load(JavaThread *thread, Klass* klass) { > 1278 if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { > 1279 return; > 1280 } > 1281 HandleMark hm(thread); > 1282 > 1283 EVT_TRIG_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Trg Class Load triggered", > 1284 JvmtiTrace::safe_get_thread_name(thread))); > 1285 JvmtiThreadState* state = thread->jvmti_thread_state(); > 1286 if (state == NULL) { > 1287 return; > 1288 } > 1289 JvmtiEnvThreadStateIterator it(state); > 1290 for (JvmtiEnvThreadState* ets = it.first(); ets != NULL; ets = it.next(ets)) { > 1291 if (ets->is_enabled(JVMTI_EVENT_CLASS_LOAD)) { > 1292 JvmtiEnv *env = ets->get_env(); > 1293 if (env->phase() == JVMTI_PHASE_PRIMORDIAL) { > 1294 continue; > 1295 } > 1296 EVT_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Evt Class Load sent %s", > 1297 JvmtiTrace::safe_get_thread_name(thread), > 1298 klass==NULL? "NULL" : klass->external_name() )); > 1299 JvmtiClassEventMark jem(thread, klass); > 1300 JvmtiJavaThreadEventTransition jet(thread); > 1301 jvmtiEventClassLoad callback = env->callbacks()->ClassLoad; > 1302 if (callback != NULL) { > 1303 (*callback)(env->jvmti_external(), jem.jni_env(), jem.jni_thread(), jem.jni_class()); > 1304 } > 1305 } > 1306 } > 1307 } > > Thanks! > > --Daniil > > ?On 3/20/19, 3:40 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > No chance for it if you lock a raw monitor in the event callbacks. > > Thanks, > Serguei > > On 3/20/19 14:58, Daniil Titov wrote: > > Hi Serguei, > > > > I think that just disabling event notifications inside VMDeath callback still leaves a small window for VMDeath callback being called after the classload callback is called (or about being called) but before it enters a raw monitor. Thus I decided to follow your original suggestion and restore volatile modifier for callbacksEnabled. Please review a new version of the patch. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03/ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > From: > > Organization: Oracle Corporation > > Date: Tuesday, March 19, 2019 at 7:17 PM > > To: Daniil Titov , OpenJDK Serviceability , Jean Christophe Beyler > > Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash > > > > Hi Daniil, > > > > I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. > > Otherwise, looks good to me. > > > > > > Another approach could be to disable event notifications in VMDeath callback with: > > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); > > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); > > . . . > > > > Thanks, > > Serguei > > > > On 3/18/19 6:58 PM, Daniil Titov wrote: > > Hi Serguei and JC, > > > > Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > --Daniil > > > > > > ?On 3/18/19, 9:47 AM, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: > > > > Hi Daniil, > > > > The JVMTI phase can change in the middle of callback work after the > > check you added. > > I'd suggest to lock a raw monitor across the callbacks to make them atomic. > > > > Thank you for taking care about this issue! > > > > Thanks, > > Serguei > > > > > > > > On 3/15/19 16:08, Daniil Titov wrote: > > > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > > > > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > > > Thanks! > > > -Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > From nick.gasson at arm.com Thu Mar 21 06:58:17 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 21 Mar 2019 14:58:17 +0800 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" Message-ID: Hi, Please review this small fix to a bug that causes the following tests to fail when run with jtreg -timeoutFactor > 10 after the changes in 8207367: vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 This test creates a debugee process that sleeps for 5 * timeoutFactor * 10000 ms or until it is signalled to stop, and the parent sleeps for 5 * timeoutFactor * 1000 ms then signals the child and checks no unexpected events were received in that time. However the jtreg timeout factor is not passed from parent to debugee so the debugee uses the default value 1.0. So if the jtreg timeout factor is 12 the parent will sleep for 5 * 12 * 1000 = 60000 ms and the debugee will sleep for 5 * 1 * 10000 = 50000 ms and exit before the parent wakes up. The debugee exiting causes an unexpected event and the test fails. Fix by passing the timeout factor system property to the debugee. Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". Thanks, Nick From daniel.daugherty at oracle.com Thu Mar 21 16:17:40 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Mar 2019 12:17:40 -0400 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: On 3/21/19 2:58 AM, Nick Gasson wrote: > Hi, > > Please review this small fix to a bug that causes the following tests > to fail when run with jtreg -timeoutFactor > 10 after the changes in > 8207367: > > vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java > vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 > Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java ??? No comments. test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java ??? No comments. Thumbs up. You should wait to hear from someone on the current Serviceability team for your second review. JDK-8220451 tracks the failure in EventQueue/remove/remove004. JDK-8220456 tracks the failure in EventQueue/remove_l/remove_l004. You can list both bug IDs in the same changeset like this: 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" or you can use 8220451 and close 8220456 as a duplicate of 8220451. Thanks for fixing this issue. Dan > > This test creates a debugee process that sleeps for 5 * timeoutFactor > * 10000 ms or until it is signalled to stop, and the parent sleeps for > 5 * timeoutFactor * 1000 ms then signals the child and checks no > unexpected events were received in that time. However the jtreg > timeout factor is not passed from parent to debugee so the debugee > uses the default value 1.0. So if the jtreg timeout factor is 12 the > parent will sleep for 5 * 12 * 1000 = 60000 ms and the debugee will > sleep for 5 * 1 * 10000 = 50000 ms and exit before the parent wakes > up. The debugee exiting causes an unexpected event and the test fails. > > Fix by passing the timeout factor system property to the debugee. > > Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" > JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". > > Thanks, > Nick > From bob.vandette at oracle.com Thu Mar 21 17:12:04 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 21 Mar 2019 13:12:04 -0400 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs Message-ID: Please review this fix for a container test that fails on some Linux distributions. The test fails to see the Memory Fail count metric value increase. This is caused by the fact that we are allowing ergonomics to select the amount of Heap size. This size varies depending on the amount of free memory that?s available on different docker implementations. The fix is to force the VM to always set the heap size to the size of the containers memory. This change also stops allocating once it sees the fail count increase. This is needed to keep the container from getting killed by the out of memory killer. The fix has been verified by the submitter along with a local run of the container tests. BUG: https://bugs.openjdk.java.net/browse/JDK-8220674 WEBREV: http://cr.openjdk.java.net/~bobv/8220674/webrev/ Bob. From daniil.x.titov at oracle.com Thu Mar 21 17:17:23 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 21 Mar 2019 10:17:23 -0700 Subject: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash In-Reply-To: References: <14178926-0691-c66a-26f8-057ab15ca3f0@oracle.com> <4082C887-A281-4C2F-8CC6-E9827386CE8A@oracle.com> <7accee97-c69c-7814-d467-8f3149649b7e@oracle.com> <2cf4b4a6-b699-6fd9-5169-34b5fc707356@oracle.com> <8a6ebfa4-4750-cdf7-86f8-cd1f54a8f2c7@oracle.com> <073DDE3A-15AB-4B61-B6A3-5557269AE52E@oracle.com> Message-ID: Thank you, JC and Serguei, for reviewing this change. Best regards, Daniil From: Jean Christophe Beyler Date: Thursday, March 21, 2019 at 9:29 AM To: Daniil Titov Subject: Re: FW: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash Hi Daniil, Sorry yes it looks great to me :-) My only nit would be : "callbacksEnabled" is camel backed and should probably be callbacks_enabled for c++ code, but that's a nit ;-) Jc On Thu, Mar 21, 2019 at 9:26 AM Daniil Titov wrote: Hi JC, Just wanted to check with you that you are also OK with this version of the fix. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03 Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! --Daniil ?On 3/20/19, 4:50 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, You are right, there is a hole for this. It can be easily fixed if the callbacks check phase at the beginning. But I don't think this would be simpler than your current fix. As I already mentioned, I'm Okay with the fix you have now. I'm still thinking on how to fix this on the JVMTI level. Thanks, Serguei On 3/20/19 16:35, Daniil Titov wrote: > Hi Serguei, > > I could be missing something but as I understood the suggested alternative approach was to not introduce the callbacksEnabled flag and instead just unregister other callbacks inside VMDeath callback. My concern was the case when one thread is on line 1302 (it is going to call a class loaded callback), while another thread just entered VMDeath callback. Without callbacksEnabled flag the first thread will enter the callback and wait on the raw monitor acquired by VMDeath callback thread, after that it will continue and call JVMTI API that might throw WRONG_PHASE error if by this time the second thread already returned from the VMDeath callback and changed the JVMTI phase. > > 1277 void JvmtiExport::post_class_load(JavaThread *thread, Klass* klass) { > 1278 if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { > 1279 return; > 1280 } > 1281 HandleMark hm(thread); > 1282 > 1283 EVT_TRIG_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Trg Class Load triggered", > 1284 JvmtiTrace::safe_get_thread_name(thread))); > 1285 JvmtiThreadState* state = thread->jvmti_thread_state(); > 1286 if (state == NULL) { > 1287 return; > 1288 } > 1289 JvmtiEnvThreadStateIterator it(state); > 1290 for (JvmtiEnvThreadState* ets = it.first(); ets != NULL; ets = it.next(ets)) { > 1291 if (ets->is_enabled(JVMTI_EVENT_CLASS_LOAD)) { > 1292 JvmtiEnv *env = ets->get_env(); > 1293 if (env->phase() == JVMTI_PHASE_PRIMORDIAL) { > 1294 continue; > 1295 } > 1296 EVT_TRACE(JVMTI_EVENT_CLASS_LOAD, ("[%s] Evt Class Load sent %s", > 1297 JvmtiTrace::safe_get_thread_name(thread), > 1298 klass==NULL? "NULL" : klass->external_name() )); > 1299 JvmtiClassEventMark jem(thread, klass); > 1300 JvmtiJavaThreadEventTransition jet(thread); > 1301 jvmtiEventClassLoad callback = env->callbacks()->ClassLoad; > 1302 if (callback != NULL) { > 1303 (*callback)(env->jvmti_external(), jem.jni_env(), jem.jni_thread(), jem.jni_class()); > 1304 } > 1305 } > 1306 } > 1307 } > > Thanks! > > --Daniil > > ?On 3/20/19, 3:40 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > No chance for it if you lock a raw monitor in the event callbacks. > > Thanks, > Serguei > > On 3/20/19 14:58, Daniil Titov wrote: > > Hi Serguei, > > > > I think that just disabling event notifications inside VMDeath callback still leaves a small window for VMDeath callback being called after the classload callback is called (or about being called) but before it enters a raw monitor. Thus I decided to follow your original suggestion and restore volatile modifier for callbacksEnabled. Please review a new version of the patch. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.03/ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > From: > > Organization: Oracle Corporation > > Date: Tuesday, March 19, 2019 at 7:17 PM > > To: Daniil Titov , OpenJDK Serviceability , Jean Christophe Beyler > > Subject: Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash > > > > Hi Daniil, > > > > I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. > > Otherwise, looks good to me. > > > > > > Another approach could be to disable event notifications in VMDeath callback with: > > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); > > SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); > > . . . > > > > Thanks, > > Serguei > > > > On 3/18/19 6:58 PM, Daniil Titov wrote: > > Hi Serguei and JC, > > > > Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > Thanks! > > --Daniil > > > > > > ?On 3/18/19, 9:47 AM, mailto:serguei.spitsyn at oracle.com mailto:serguei.spitsyn at oracle.com wrote: > > > > Hi Daniil, > > > > The JVMTI phase can change in the middle of callback work after the > > check you added. > > I'd suggest to lock a raw monitor across the callbacks to make them atomic. > > > > Thank you for taking care about this issue! > > > > Thanks, > > Serguei > > > > > > > > On 3/15/19 16:08, Daniil Titov wrote: > > > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > > > > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > > > > > Thanks! > > > -Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Thu Mar 21 17:19:33 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 21 Mar 2019 20:19:33 +0300 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time Message-ID: Hi all, please review the fix it disables caching for types when signature is not provided as described in the bug (this is one of the proposed solutions in the bug). https://bugs.openjdk.java.net/browse/JDK-8146986 http://cr.openjdk.java.net/~eushakov/8146986/webrev.00/ Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From sgehwolf at redhat.com Thu Mar 21 17:54:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Mar 2019 18:54:50 +0100 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs In-Reply-To: References: Message-ID: Hi Bob, On Thu, 2019-03-21 at 13:12 -0400, Bob Vandette wrote: > WEBREV: > > http://cr.openjdk.java.net/~bobv/8220674/webrev/ This looks good to me. Thanks for fixing it! I'm not a Reviewer, though. Cheers, Severin From serguei.spitsyn at oracle.com Thu Mar 21 17:56:39 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Mar 2019 10:56:39 -0700 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: <8273a0ab-aeaa-dff0-ad98-83fb9dafd1c1@oracle.com> Hi Nick, The fix looks good to me. Thank you for taking care about it! Thanks, Serguei On 3/20/19 23:58, Nick Gasson wrote: > Hi, > > Please review this small fix to a bug that causes the following tests > to fail when run with jtreg -timeoutFactor > 10 after the changes in > 8207367: > > vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java > vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 > Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 > > This test creates a debugee process that sleeps for 5 * timeoutFactor > * 10000 ms or until it is signalled to stop, and the parent sleeps for > 5 * timeoutFactor * 1000 ms then signals the child and checks no > unexpected events were received in that time. However the jtreg > timeout factor is not passed from parent to debugee so the debugee > uses the default value 1.0. So if the jtreg timeout factor is 12 the > parent will sleep for 5 * 12 * 1000 = 60000 ms and the debugee will > sleep for 5 * 1 * 10000 = 50000 ms and exit before the parent wakes > up. The debugee exiting causes an unexpected event and the test fails. > > Fix by passing the timeout factor system property to the debugee. > > Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" > JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". > > Thanks, > Nick From serguei.spitsyn at oracle.com Thu Mar 21 18:02:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Mar 2019 11:02:11 -0700 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: On 3/21/19 09:17, Daniel D. Daugherty wrote: > On 3/21/19 2:58 AM, Nick Gasson wrote: >> Hi, >> >> Please review this small fix to a bug that causes the following tests >> to fail when run with jtreg -timeoutFactor > 10 after the changes in >> 8207367: >> >> vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java >> vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 >> Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 > > test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java > > ??? No comments. > > test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java > > ??? No comments. > > Thumbs up. You should wait to hear from someone on the current > Serviceability team for your second review. > > JDK-8220451 tracks the failure in EventQueue/remove/remove004. > JDK-8220456 tracks the failure in EventQueue/remove_l/remove_l004. > > You can list both bug IDs in the same changeset like this: > > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" > 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT > while waiting for event" > > or you can use 8220451 and close 8220456 as a duplicate of 8220451. The 8220456 is assigned to Gary. We can leave it up to Gary to close this issue (or not). Also, I've checked that both bugs are not problem listed. Thanks, Serguei > > Thanks for fixing this issue. > > Dan > > >> >> This test creates a debugee process that sleeps for 5 * timeoutFactor >> * 10000 ms or until it is signalled to stop, and the parent sleeps >> for 5 * timeoutFactor * 1000 ms then signals the child and checks no >> unexpected events were received in that time. However the jtreg >> timeout factor is not passed from parent to debugee so the debugee >> uses the default value 1.0. So if the jtreg timeout factor is 12 the >> parent will sleep for 5 * 12 * 1000 = 60000 ms and the debugee will >> sleep for 5 * 1 * 10000 = 50000 ms and exit before the parent wakes >> up. The debugee exiting causes an unexpected event and the test fails. >> >> Fix by passing the timeout factor system property to the debugee. >> >> Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" >> JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". >> >> Thanks, >> Nick >> > From serguei.spitsyn at oracle.com Thu Mar 21 18:10:24 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Mar 2019 11:10:24 -0700 Subject: RFR: 8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs In-Reply-To: References: Message-ID: <70f2d8c6-e3e6-7676-e4fb-6928588f0704@oracle.com> Hi Bob, It looks good to me. Thanks, Serguei On 3/21/19 10:12, Bob Vandette wrote: > Please review this fix for a container test that fails on some Linux distributions. > > The test fails to see the Memory Fail count metric value increase. This is caused by > the fact that we are allowing ergonomics to select the amount of Heap size. This > size varies depending on the amount of free memory that?s available on different > docker implementations. > > The fix is to force the VM to always set the heap size to the size of the containers > memory. This change also stops allocating once it sees the fail count increase. > This is needed to keep the container from getting killed by the out of memory > killer. > > The fix has been verified by the submitter along with a local run of the container tests. > > BUG: > > https://bugs.openjdk.java.net/browse/JDK-8220674 > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8220674/webrev/ > > Bob. > > From serguei.spitsyn at oracle.com Thu Mar 21 18:28:25 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Mar 2019 11:28:25 -0700 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: References: Message-ID: Hi Egor, The fix looks good to me. Thank you for taking care about it! I've targeted this enhancement to 13. How do you test it? It would be safe to run all JDI tests to make sure no new timeouts are observed. Thanks, Serguei On 3/21/19 10:19, Egor Ushakov wrote: > Hi all, please review the fix > > it disables caching for types when signature is not provided as > described in the bug (this is one of the proposed solutions in the bug). > > https://bugs.openjdk.java.net/browse/JDK-8146986 > http://cr.openjdk.java.net/~eushakov/8146986/webrev.00/ > > Thanks! > From daniel.daugherty at oracle.com Thu Mar 21 18:29:03 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Mar 2019 14:29:03 -0400 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: On 3/21/19 2:02 PM, serguei.spitsyn at oracle.com wrote: > On 3/21/19 09:17, Daniel D. Daugherty wrote: >> On 3/21/19 2:58 AM, Nick Gasson wrote: >>> Hi, >>> >>> Please review this small fix to a bug that causes the following >>> tests to fail when run with jtreg -timeoutFactor > 10 after the >>> changes in 8207367: >>> >>> vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java >>> vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 >>> Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 >> >> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java >> >> ??? No comments. >> >> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java >> >> ??? No comments. >> >> Thumbs up. You should wait to hear from someone on the current >> Serviceability team for your second review. >> >> JDK-8220451 tracks the failure in EventQueue/remove/remove004. >> JDK-8220456 tracks the failure in EventQueue/remove_l/remove_l004. >> >> You can list both bug IDs in the same changeset like this: >> >> 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: >> thread2 is not alive" >> 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT >> while waiting for event" >> >> or you can use 8220451 and close 8220456 as a duplicate of 8220451. > > > The 8220456 is assigned to Gary. Yup. > We can leave it up to Gary to close this issue (or not). The reason we have two bugs is that the failure modes are different so the same root cause is not obvious to the casual log reader. I do recommend listing both bugs in same changeset so both bugs show up as fixed. > > Also, I've checked that both bugs are not problem listed. Correct. I filed these based on testing in my lab. I don't anyone doing CI analysis has spotted them (other than me). Dan > > Thanks, > Serguei > > >> >> Thanks for fixing this issue. >> >> Dan >> >> >>> >>> This test creates a debugee process that sleeps for 5 * >>> timeoutFactor * 10000 ms or until it is signalled to stop, and the >>> parent sleeps for 5 * timeoutFactor * 1000 ms then signals the child >>> and checks no unexpected events were received in that time. However >>> the jtreg timeout factor is not passed from parent to debugee so the >>> debugee uses the default value 1.0. So if the jtreg timeout factor >>> is 12 the parent will sleep for 5 * 12 * 1000 = 60000 ms and the >>> debugee will sleep for 5 * 1 * 10000 = 50000 ms and exit before the >>> parent wakes up. The debugee exiting causes an unexpected event and >>> the test fails. >>> >>> Fix by passing the timeout factor system property to the debugee. >>> >>> Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" >>> JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". >>> >>> Thanks, >>> Nick >>> >> > From gary.adams at oracle.com Thu Mar 21 18:42:38 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 21 Mar 2019 14:42:38 -0400 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: <0e06aa9f-682e-1dec-b3e3-b32d8912be38@oracle.com> I'm fine with Nick's solution. I can help with the bug resolution after the changes are pushed. The only thought I'd add is that someday we should revisit all these time based mechanisms. It would be a lot cleaner to have the debugger always single the debuggee when it is time to quit. There have been quite few edge cases closed lately that are based on imprecise exit timing. On 3/21/19 2:02 PM, serguei.spitsyn at oracle.com wrote: > On 3/21/19 09:17, Daniel D. Daugherty wrote: >> On 3/21/19 2:58 AM, Nick Gasson wrote: >>> Hi, >>> >>> Please review this small fix to a bug that causes the following >>> tests to fail when run with jtreg -timeoutFactor > 10 after the >>> changes in 8207367: >>> >>> vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java >>> vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220451 >>> Webrev: http://cr.openjdk.java.net/~ngasson/8220451/webrev.0 >> >> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java >> >> ??? No comments. >> >> test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java >> >> ??? No comments. >> >> Thumbs up. You should wait to hear from someone on the current >> Serviceability team for your second review. >> >> JDK-8220451 tracks the failure in EventQueue/remove/remove004. >> JDK-8220456 tracks the failure in EventQueue/remove_l/remove_l004. >> >> You can list both bug IDs in the same changeset like this: >> >> 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: >> thread2 is not alive" >> 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT >> while waiting for event" >> >> or you can use 8220451 and close 8220456 as a duplicate of 8220451. > > > The 8220456 is assigned to Gary. > We can leave it up to Gary to close this issue (or not). > > Also, I've checked that both bugs are not problem listed. > > Thanks, > Serguei > > >> >> Thanks for fixing this issue. >> >> Dan >> >> >>> >>> This test creates a debugee process that sleeps for 5 * >>> timeoutFactor * 10000 ms or until it is signalled to stop, and the >>> parent sleeps for 5 * timeoutFactor * 1000 ms then signals the child >>> and checks no unexpected events were received in that time. However >>> the jtreg timeout factor is not passed from parent to debugee so the >>> debugee uses the default value 1.0. So if the jtreg timeout factor >>> is 12 the parent will sleep for 5 * 12 * 1000 = 60000 ms and the >>> debugee will sleep for 5 * 1 * 10000 = 50000 ms and exit before the >>> parent wakes up. The debugee exiting causes an unexpected event and >>> the test fails. >>> >>> Fix by passing the timeout factor system property to the debugee. >>> >>> Tested with `make test TEST="vmTestbase/nsk/jdi/EventQueue" >>> JTREG="TIMEOUT_FACTOR=12"' and JTREG="TIMEOUT_FACTOR=4". >>> >>> Thanks, >>> Nick >>> >> > From gary.adams at oracle.com Thu Mar 21 18:47:41 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 21 Mar 2019 14:47:41 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <5C92318B.2030507@oracle.com> References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> <5C92318B.2030507@oracle.com> Message-ID: <4ccd53b1-321d-e767-166f-34e2e865b4d4@oracle.com> The jstatd failures look like the server remote endpoint was GC'd after it was bound. A strong reference should prevent the NoSuchObjectException (JDK-8203026). Was seeing 1 failure every 50 testruns. Currently through 400 test runs with no failures with this proposed fix. diff --git a/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java b/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java --- a/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java +++ b/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2004, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -45,6 +45,7 @@ ???? private static Registry registry; ???? private static int port = -1; ???? private static boolean startRegistry = true; +??? private static RemoteHostImpl remoteHost; ???? private static void printUsage() { ???????? System.err.println("usage: jstatd [-nr] [-p port] [-n rminame]\n" + @@ -138,7 +139,7 @@ ???????? try { ???????????? // use 1.5.0 dynamically generated subs. System.setProperty("java.rmi.server.ignoreSubClasses", "true"); -??????????? RemoteHostImpl remoteHost = new RemoteHostImpl(); +??????????? remoteHost = new RemoteHostImpl(); ???????????? RemoteHost stub = (RemoteHost) UnicastRemoteObject.exportObject( ???????????????????? remoteHost, 0); ???????????? bind(name.toString(), remoteHost); diff --git a/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java b/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java --- a/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java +++ b/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -50,6 +50,7 @@ ???? private MonitoredHost monitoredHost; ???? private Set activeVms; +??? private static RemoteVmImpl rvm; ???? public RemoteHostImpl() throws MonitorException { ???????? try { @@ -76,7 +77,7 @@ ???????? try { ???????????? VmIdentifier vmid = new VmIdentifier(vmidStr); ???????????? MonitoredVm mvm = monitoredHost.getMonitoredVm(vmid); -??????????? RemoteVmImpl rvm = new RemoteVmImpl((BufferedMonitoredVm)mvm); +??????????? rvm = new RemoteVmImpl((BufferedMonitoredVm)mvm); ???????????? stub = (RemoteVm) UnicastRemoteObject.exportObject(rvm, 0); ???????? } ???????? catch (URISyntaxException e) { On 3/20/19, 8:26 AM, Gary Adams wrote: > I think I have found the source of the dash. > ?sun/tools/jstat/RowClosure.java > sets the NaN value to "-". > > That should be fine. > > It just means in the jstat output tests need to account for the > possibility. > > ... > > On 3/19/19, 6:07 PM, Chris Plummer wrote: >> The presence of the '-' sounds familiar. I recall reading about it in >> a review. I know I did a review for these tests that impacted the >> output, but I don't see it introducing a '-' anywhere. See >> JDK-8202466. However, that bug references JDK-8199519, which caused >> problems by changing a value in the output from a '-' to a 0: >> >> --- >> a/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java >> Wed Apr 25 17:50:32 2018 -0400 >> +++ >> b/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java >> Thu Apr 26 09:45:47 2018 +0900 >> @@ -74,10 +74,18 @@ >> assertThat(GCT >= 0, "Incorrect time value for GCT"); >> assertThat(GCT >= YGCT, "GCT < YGCT (total garbage collection time < >> young generation garbage collection time)"); >> >> - int CGC = getIntValue("CGC"); >> - float CGCT = getFloatValue("CGCT"); >> - assertThat(CGCT >= 0, "Incorrect time value for CGCT"); >> + int CGC = 0; >> + float CGCT = 0.0f; >> + try { >> + CGC = getIntValue("CGC"); >> + } catch (NumberFormatException e) { >> + if (!e.getMessage().equals("Unparseable number: \"-\"")) { >> + throw e; >> + } >> + } >> if (CGC > 0) { >> + CGCT = getFloatValue("CGCT"); >> + assertThat(CGCT >= 0, "Incorrect time value for CGCT"); >> assertThat(CGCT > 0, "Number of concurrent GC events is " + CGC + ", >> but CGCT is 0"); >> } >> I'm not sure if any of this is related to what you are seeing. Chris >> >> On 3/19/19 11:39 AM, Gary Adams wrote: >>> A quick follow up on the jstat test failures. >>> >>> On the failed runs the output looks like this : >>> >>> ----------messages:(3/127)---------- >>> command: shell jstatLineCounts4.sh >>> reason: User specified action: run shell jstatLineCounts4.sh >>> elapsed time (seconds): 7.496 >>> ----------System.out:(13/1261)---------- >>> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>> 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 >>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>> >>> The awk scripts used to check the output are not aware a dash '-' is >>> allowed the metaspace column. >>> Here is a quick stab to allow the dashes. >>> Is anyone aware of recent changes in the gcutil output? >>> >>> diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk >>> b/test/jdk/sun/tools/jstat/lineCounts3.awk >>> --- a/test/jdk/sun/tools/jstat/lineCounts3.awk >>> +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk >>> @@ -23,7 +23,7 @@ >>> ???? ??? headerlines++; >>> ???? } >>> >>> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>> ???? ??? datalines++; >>> ???? } >>> >>> diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk >>> b/test/jdk/sun/tools/jstat/lineCounts4.awk >>> --- a/test/jdk/sun/tools/jstat/lineCounts4.awk >>> +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk >>> @@ -26,7 +26,7 @@ >>> ???? ??? headerlines++; >>> ???? } >>> >>> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>> ???? ??? if (headerlines == 2) { >>> ???? ??????? datalines2++; >>> ???? ??? } >>> >>> >>> On 3/19/19, 8:22 AM, Gary Adams wrote: >>>> After 1000 testruns on {solaris,linux,windows,macosx} debug builds >>>> running >>>> ? test/jdk/sun/tools >>>> ? test/jdk/com/sun/tools/attach >>>> >>>> with this change, no failures were observed in TestJps or TempDirTest. >>>> >>>> diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT >>>> --- a/test/jdk/TEST.ROOT >>>> +++ b/test/jdk/TEST.ROOT >>>> @@ -22,7 +22,11 @@ >>>> ?javax/management sun/awt sun/java2d >>>> javax/xml/jaxp/testng/validation java/lang/ProcessHandle >>>> >>>> ?# Tests that cannot run concurrently >>>> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>>> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi >>>> java/util/stream java/util/Arrays/largeMemory >>>> java/util/BitSet/stream javax/rmi >>>> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>>> sun/management/jmxremote \ >>>> +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb >>>> sun/tools/jhsdb/heapconfig \ >>>> +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack >>>> sun/tools/jstat \ >>>> +com/sun/tools/attach sun/security/mscapi java/util/stream >>>> java/util/Arrays/largeMemory \ >>>> +java/util/BitSet/stream javax/rmi >>>> ?# Group definitions >>>> ?groups=TEST.groups >>>> >>>> Failures were observed in the following tests. >>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] ? >>>> sun/tools/jstat/jstatLineCounts3.sh >>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] ? >>>> sun/tools/jstat/jstatLineCounts4.sh >>>> sun/tools/jstatd/TestJstatdDefaults.java >>>> ? sun/tools/jstatd/TestJstatdServer.java >>>> ? sun/tools/jstatd/TestJstatdPort.java >>>> ? sun/tools/jstatd/TestJstatdExternalRegistry.java >>>> >>>> I'll investigate those failures some more, but I don't think they are >>>> related to the change to exclusiveAccess.dirs. >>>> >>>> Issues: >>>> https://bugs.openjdk.java.net/browse/JDK-8220295 >>>> https://bugs.openjdk.java.net/browse/JDK-8220242 >>>> >>>> At this point just looking for feedback, if this is a reasonable >>>> direction >>>> to deal with the intermittent timeouts with theses tests to reduce the >>>> concurrency with other attaching tests. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Mar 21 19:39:36 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 21 Mar 2019 12:39:36 -0700 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: References: Message-ID: Hi Egor, Looks good to me as well, nit would be that the rest of the file does not add a new-line for a else if: if () { } else if () { } instead of what you added: if () { } else if () { } (Not a Reviewer) Thanks, Jc On Thu, Mar 21, 2019 at 11:31 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Egor, > > The fix looks good to me. > > Thank you for taking care about it! > I've targeted this enhancement to 13. > > How do you test it? > It would be safe to run all JDI tests to make sure no new timeouts are > observed. > > Thanks, > Serguei > > > On 3/21/19 10:19, Egor Ushakov wrote: > > Hi all, please review the fix > > > > it disables caching for types when signature is not provided as > > described in the bug (this is one of the proposed solutions in the bug). > > > > https://bugs.openjdk.java.net/browse/JDK-8146986 > > http://cr.openjdk.java.net/~eushakov/8146986/webrev.00/ > > > > Thanks! > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Mar 21 22:53:41 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 21 Mar 2019 15:53:41 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <4ccd53b1-321d-e767-166f-34e2e865b4d4@oracle.com> References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> <5C92318B.2030507@oracle.com> <4ccd53b1-321d-e767-166f-34e2e865b4d4@oracle.com> Message-ID: <6afa7b1e-fc2a-32f7-2f63-9185f34170db@oracle.com> An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Mar 21 23:29:47 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 21 Mar 2019 19:29:47 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <6afa7b1e-fc2a-32f7-2f63-9185f34170db@oracle.com> References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> <5C92318B.2030507@oracle.com> <4ccd53b1-321d-e767-166f-34e2e865b4d4@oracle.com> <6afa7b1e-fc2a-32f7-2f63-9185f34170db@oracle.com> Message-ID: I've been talking with Roger about the RMI issue I plan to cross post the RFR to serviceability-dev and core-libs. The fix needs reviews from both groups. That being said, the responsibility for keeping the strong reference is specified to be the callers responsibility. It's part of the distributed garbage collection foundation. I'll start cleaning up the jstat RFRs tomorrow. The good news is all the tests are passing with the fixes discussed in this thread. On 3/21/19 6:53 PM, Chris Plummer wrote: > Hi Gary, > > I admittedly know next to nothing about how jstat and jstatd interact, > and also know little about RMI, but after reading the bug I can't help > but think that your fix might just be hiding a bug else (like in RMI). > For example, should UnicastRemoteObject.exportObject() be keeping the > remoteHost object live? > > thanks, > > Chris > > On 3/21/19 11:47 AM, Gary Adams wrote: >> The jstatd failures look like the server remote endpoint was GC'd >> after it was bound. >> A strong reference should prevent the NoSuchObjectException >> (JDK-8203026). >> Was seeing 1 failure every 50 testruns. Currently through 400 test >> runs with >> no failures with this proposed fix. >> >> diff --git >> a/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java >> b/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java >> --- a/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java >> +++ b/src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2004, 2018, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -45,6 +45,7 @@ >> ???? private static Registry registry; >> ???? private static int port = -1; >> ???? private static boolean startRegistry = true; >> +??? private static RemoteHostImpl remoteHost; >> >> ???? private static void printUsage() { >> ???????? System.err.println("usage: jstatd [-nr] [-p port] [-n >> rminame]\n" + >> @@ -138,7 +139,7 @@ >> ???????? try { >> ???????????? // use 1.5.0 dynamically generated subs. >> System.setProperty("java.rmi.server.ignoreSubClasses", "true"); >> -??????????? RemoteHostImpl remoteHost = new RemoteHostImpl(); >> +??????????? remoteHost = new RemoteHostImpl(); >> ???????????? RemoteHost stub = (RemoteHost) >> UnicastRemoteObject.exportObject( >> ???????????????????? remoteHost, 0); >> ???????????? bind(name.toString(), remoteHost); >> >> diff --git >> a/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java >> b/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java >> --- a/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java >> +++ b/src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2004, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2004, 2019, Oracle and/or its affiliates. All >> rights reserved. >> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> ? * >> ? * This code is free software; you can redistribute it and/or modify it >> @@ -50,6 +50,7 @@ >> >> ???? private MonitoredHost monitoredHost; >> ???? private Set activeVms; >> +??? private static RemoteVmImpl rvm; >> >> ???? public RemoteHostImpl() throws MonitorException { >> ???????? try { >> @@ -76,7 +77,7 @@ >> ???????? try { >> ???????????? VmIdentifier vmid = new VmIdentifier(vmidStr); >> ???????????? MonitoredVm mvm = monitoredHost.getMonitoredVm(vmid); >> -??????????? RemoteVmImpl rvm = new >> RemoteVmImpl((BufferedMonitoredVm)mvm); >> +??????????? rvm = new RemoteVmImpl((BufferedMonitoredVm)mvm); >> ???????????? stub = (RemoteVm) UnicastRemoteObject.exportObject(rvm, 0); >> ???????? } >> ???????? catch (URISyntaxException e) { >> >> >> On 3/20/19, 8:26 AM, Gary Adams wrote: >>> I think I have found the source of the dash. >>> ?sun/tools/jstat/RowClosure.java >>> sets the NaN value to "-". >>> >>> That should be fine. >>> >>> It just means in the jstat output tests need to account for the >>> possibility. >>> >>> ... >>> >>> On 3/19/19, 6:07 PM, Chris Plummer wrote: >>>> The presence of the '-' sounds familiar. I recall reading about it >>>> in a review. I know I did a review for these tests that impacted >>>> the output, but I don't see it introducing a '-' anywhere. See >>>> JDK-8202466. However, that bug references JDK-8199519, which caused >>>> problems by changing a value in the output from a '-' to a 0: >>>> >>>> --- >>>> a/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java >>>> Wed Apr 25 17:50:32 2018 -0400 >>>> +++ >>>> b/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java >>>> Thu Apr 26 09:45:47 2018 +0900 >>>> @@ -74,10 +74,18 @@ >>>> assertThat(GCT >= 0, "Incorrect time value for GCT"); >>>> assertThat(GCT >= YGCT, "GCT < YGCT (total garbage collection time >>>> < young generation garbage collection time)"); >>>> >>>> - int CGC = getIntValue("CGC"); >>>> - float CGCT = getFloatValue("CGCT"); >>>> - assertThat(CGCT >= 0, "Incorrect time value for CGCT"); >>>> + int CGC = 0; >>>> + float CGCT = 0.0f; >>>> + try { >>>> + CGC = getIntValue("CGC"); >>>> + } catch (NumberFormatException e) { >>>> + if (!e.getMessage().equals("Unparseable number: \"-\"")) { >>>> + throw e; >>>> + } >>>> + } >>>> if (CGC > 0) { >>>> + CGCT = getFloatValue("CGCT"); >>>> + assertThat(CGCT >= 0, "Incorrect time value for CGCT"); >>>> assertThat(CGCT > 0, "Number of concurrent GC events is " + CGC + >>>> ", but CGCT is 0"); >>>> } >>>> I'm not sure if any of this is related to what you are seeing. Chris >>>> >>>> On 3/19/19 11:39 AM, Gary Adams wrote: >>>>> A quick follow up on the jstat test failures. >>>>> >>>>> On the failed runs the output looks like this : >>>>> >>>>> ----------messages:(3/127)---------- >>>>> command: shell jstatLineCounts4.sh >>>>> reason: User specified action: run shell jstatLineCounts4.sh >>>>> elapsed time (seconds): 7.496 >>>>> ----------System.out:(13/1261)---------- >>>>> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >>>>> 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 >>>>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>>>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>>>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>>>> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >>>>> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >>>>> >>>>> The awk scripts used to check the output are not aware a dash '-' >>>>> is allowed the metaspace column. >>>>> Here is a quick stab to allow the dashes. >>>>> Is anyone aware of recent changes in the gcutil output? >>>>> >>>>> diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk >>>>> b/test/jdk/sun/tools/jstat/lineCounts3.awk >>>>> --- a/test/jdk/sun/tools/jstat/lineCounts3.awk >>>>> +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk >>>>> @@ -23,7 +23,7 @@ >>>>> ???? ??? headerlines++; >>>>> ???? } >>>>> >>>>> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ >>>>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>>>> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >>>>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>>>> ???? ??? datalines++; >>>>> ???? } >>>>> >>>>> diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk >>>>> b/test/jdk/sun/tools/jstat/lineCounts4.awk >>>>> --- a/test/jdk/sun/tools/jstat/lineCounts4.awk >>>>> +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk >>>>> @@ -26,7 +26,7 @@ >>>>> ???? ??? headerlines++; >>>>> ???? } >>>>> >>>>> -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ >>>>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>>>> +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ >>>>> ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ >>>>> ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { >>>>> ???? ??? if (headerlines == 2) { >>>>> ???? ??????? datalines2++; >>>>> ???? ??? } >>>>> >>>>> >>>>> On 3/19/19, 8:22 AM, Gary Adams wrote: >>>>>> After 1000 testruns on {solaris,linux,windows,macosx} debug builds >>>>>> running >>>>>> ? test/jdk/sun/tools >>>>>> ? test/jdk/com/sun/tools/attach >>>>>> >>>>>> with this change, no failures were observed in TestJps or >>>>>> TempDirTest. >>>>>> >>>>>> diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT >>>>>> --- a/test/jdk/TEST.ROOT >>>>>> +++ b/test/jdk/TEST.ROOT >>>>>> @@ -22,7 +22,11 @@ >>>>>> ?javax/management sun/awt sun/java2d >>>>>> javax/xml/jaxp/testng/validation java/lang/ProcessHandle >>>>>> >>>>>> ?# Tests that cannot run concurrently >>>>>> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>>>>> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi >>>>>> java/util/stream java/util/Arrays/largeMemory >>>>>> java/util/BitSet/stream javax/rmi >>>>>> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs >>>>>> sun/management/jmxremote \ >>>>>> +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb >>>>>> sun/tools/jhsdb/heapconfig \ >>>>>> +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack >>>>>> sun/tools/jstat \ >>>>>> +com/sun/tools/attach sun/security/mscapi java/util/stream >>>>>> java/util/Arrays/largeMemory \ >>>>>> +java/util/BitSet/stream javax/rmi >>>>>> ?# Group definitions >>>>>> ?groups=TEST.groups >>>>>> >>>>>> Failures were observed in the following tests. >>>>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>>>> sun/tools/jstat/jstatLineCounts3.sh >>>>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>>>> sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: >>>>>> 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] >>>>>> sun/tools/jstat/jstatLineCounts4.sh >>>>>> sun/tools/jstatd/TestJstatdDefaults.java >>>>>> ? sun/tools/jstatd/TestJstatdServer.java >>>>>> ? sun/tools/jstatd/TestJstatdPort.java >>>>>> ? sun/tools/jstatd/TestJstatdExternalRegistry.java >>>>>> >>>>>> I'll investigate those failures some more, but I don't think they are >>>>>> related to the change to exclusiveAccess.dirs. >>>>>> >>>>>> Issues: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8220295 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8220242 >>>>>> >>>>>> At this point just looking for feedback, if this is a reasonable >>>>>> direction >>>>>> to deal with the intermittent timeouts with theses tests to >>>>>> reduce the >>>>>> concurrency with other attaching tests. >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Mar 22 01:32:28 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 21 Mar 2019 18:32:28 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <5C90DF19.3050707@oracle.com> <5C91374B.5060305@oracle.com> <319d97f1-e8fa-721a-e8a4-c3570a3bddc0@oracle.com> <5C92318B.2030507@oracle.com> <4ccd53b1-321d-e767-166f-34e2e865b4d4@oracle.com> <6afa7b1e-fc2a-32f7-2f63-9185f34170db@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Fri Mar 22 07:11:52 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 22 Mar 2019 15:11:52 +0800 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: On 22/03/2019 00:17, Daniel D. Daugherty wrote: > > You can list both bug IDs in the same changeset like this: > > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" > 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT > while waiting for event" Thanks everyone for the reviews. I've updated the commit message to match the above: http://hg.openjdk.java.net/jdk/jdk/rev/ed34367d4e9f Nick From gary.adams at oracle.com Fri Mar 22 08:05:32 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 04:05:32 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table Message-ID: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> Here's a proposed fix for the intermittent jstatd test failure. By moving the exported object from a local method variable to a static class variable a strong reference is held so the object will not be garbage collected prematurely. ? Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 The test is currently filed as a core-libs/java.rmi, but it probably should be core-svc/tools with label=jstatd. It is the callers responsibility to ensure the strong reference to prevent the premature garbage collection, so this is a test failure rather than a need to change the underlying rmi behavior. From gary.adams at oracle.com Fri Mar 22 08:18:02 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 04:18:02 -0400 Subject: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs Message-ID: The M and CCS columns from jstat output can present a dash("-") for NaN values, such as : ----------System.out:(13/1261)---------- S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 This proposed fix updates the awk scripts which are checking output lines. For the M and CCS columns, allow either a floating point value or a dash. e.g. "([0-9]+\.[0-9]+|-)" ? Webrev: http://cr.openjdk.java.net/~gadams/8221164/webrev/ ? Issue:? https://bugs.openjdk.java.net/browse/JDK-8221164 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Mar 22 08:38:47 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 04:38:47 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out Message-ID: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> This proposed change will configure the sun/tools/j* and com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs so the java attaching tests are not run concurrently. There is only annecdotal observations that multiple tools are running when these tests are timing out. 1000s of test runs have succeeded with this change in place. More investigation can be done to find the root cause of these failures, but for now it's best to make the tests run more reliably without timing out. ? Issues: ??? https://bugs.openjdk.java.net/browse/JDK-8220242 ??? https://bugs.openjdk.java.net/browse/JDK-8220295 ? Webrev: ??? http://cr.openjdk.java.net/~gadams/8220295/webrev/ From sgehwolf at redhat.com Fri Mar 22 10:43:47 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Mar 2019 11:43:47 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support Message-ID: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Hi, Please review this change which improves container detection support tin the JVM. While docker container detection works quite well the results for systemd slices with memory limits are mixed and depend on the Linux kernel version in use. With newer kernel versions becoming more widely used we should improve JVMs memory limit detection support as well. This should be entirely backwards compatible as the hierarchical limit will only be used if everything else is unlimited. Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace with systemd slices on affected Linux distributions: Fedora 29, recent Ubuntu (18-10). Existing docker tests pass. I'm currently also running this through jdk/submit. Thoughts? Thanks, Severin From Roger.Riggs at oracle.com Fri Mar 22 13:56:21 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 Mar 2019 09:56:21 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table In-Reply-To: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> References: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> Message-ID: <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> Hi Gary, Holding a static reference to the implementation solves the problem. But I noticed that the object that is bound in the registry is the RemoteHostImpl and it should be the RemoteHost stub. Line 145: should be: bind(name.toString(), stub); That is likely to solve the problem as well, because the distributed garbage collector will correctly cause a hard reference to be retained to the implementation. Roger On 03/22/2019 04:05 AM, gary.adams at oracle.com wrote: > Here's a proposed fix for the intermittent jstatd test failure. > By moving the exported object from a local method variable to a > static class variable a strong reference is held so the object > will not be garbage collected prematurely. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 > > The test is currently filed as a core-libs/java.rmi, but it probably > should be core-svc/tools with label=jstatd. It is the callers > responsibility to ensure the strong reference to prevent > the premature garbage collection, so this is a test failure > rather than a need to change the underlying rmi behavior. From jcbeyler at google.com Fri Mar 22 15:58:50 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 22 Mar 2019 08:58:50 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> Message-ID: Hi Gary, Looks good to me :) Jc On Fri, Mar 22, 2019 at 1:41 AM gary.adams at oracle.com wrote: > This proposed change will configure the sun/tools/j* and > com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs > so the java attaching tests are not run concurrently. > > There is only annecdotal observations that multiple > tools are running when these tests are timing out. > 1000s of test runs have succeeded with this change in place. > > More investigation can be done to find the root cause > of these failures, but for now it's best to make the tests > run more reliably without timing out. > > Issues: > https://bugs.openjdk.java.net/browse/JDK-8220242 > https://bugs.openjdk.java.net/browse/JDK-8220295 > > Webrev: > http://cr.openjdk.java.net/~gadams/8220295/webrev/ > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Mar 22 16:12:55 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 22 Mar 2019 09:12:55 -0700 Subject: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs In-Reply-To: References: Message-ID: Hi Gary, Looks good to me though there's an itch to try to make the regex easier to read/maintain :) Jc On Fri, Mar 22, 2019 at 1:18 AM gary.adams at oracle.com wrote: > The M and CCS columns from jstat output can present a dash("-") > for NaN values, such as : > > ----------System.out:(13/1261)---------- > S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 > 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 > 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 > 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 > 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 > > > This proposed fix updates the awk scripts which are checking output lines. > For the M and CCS columns, allow either a floating point value or a dash. > e.g. "([0-9]+\.[0-9]+|-)" > > Webrev: http://cr.openjdk.java.net/~gadams/8221164/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8221164 > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.vandette at oracle.com Fri Mar 22 18:25:50 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 22 Mar 2019 14:25:50 -0400 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: Is there ever a situation where the memory.limit_in_bytes could be unlimited but the hierarchical_memory_limit is not? Could you maybe combine subsystem_file_contents with subsystem_file_line_contents by adding an additional argument? BTW: I found another problem with the mountinfo/cgroup parsing that impacts the container tests. I don?t know why it only caused a failure on one of my systems. I?m going to file another bug. You might want to test with these changes to make sure your looking at the correct subsystem files. diff --git a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java @@ -60,7 +60,7 @@ path = mountPoint; } else { - if (root.indexOf(cgroupPath) == 0) { + if (cgroupPath.indexOf(root) == 0) { if (cgroupPath.length() > root.length()) { String cgroupSubstr = cgroupPath.substring(root.length()); path = mountPoint + cgroupSubstr; diff --git a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java --- a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java +++ b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java @@ -85,7 +85,7 @@ String mountPoint = paths[1]; if (root != null && cgroupPath != null) { if (root.equals("/")) { - if (cgroupPath.equals("/")) { + if (!cgroupPath.equals("/")) { finalPath = mountPoint + cgroupPath; } else { finalPath = mountPoint; @@ -94,7 +94,7 @@ if (root.equals(cgroupPath)) { finalPath = mountPoint; } else { - if (root.indexOf(cgroupPath) == 0) { + if (cgroupPath.indexOf(root) == 0) { if (cgroupPath.length() > root.length()) { String cgroupSubstr = cgroupPath.substring(root.length()); finalPath = mountPoint + cgroupSubstr; @@ -103,7 +103,7 @@ } } } - subSystemPaths.put(subSystem, new String[]{finalPath}); + subSystemPaths.put(subSystem, new String[]{finalPath, mountPoint}); } } } Bob. > On Mar 22, 2019, at 6:43 AM, Severin Gehwolf wrote: > > Hi, > > Please review this change which improves container detection support > tin the JVM. While docker container detection works quite well the > results for systemd slices with memory limits are mixed and depend on > the Linux kernel version in use. With newer kernel versions becoming > more widely used we should improve JVMs memory limit detection support > as well. This should be entirely backwards compatible as the > hierarchical limit will only be used if everything else is unlimited. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ > > Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace > with systemd slices on affected Linux distributions: Fedora 29, > recent Ubuntu (18-10). Existing docker tests pass. I'm currently also > running this through jdk/submit. > > Thoughts? > > Thanks, > Severin > From egor.ushakov at jetbrains.com Fri Mar 22 18:51:15 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 22 Mar 2019 21:51:15 +0300 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: References: Message-ID: <77f28581-16fa-38ec-ed8d-fd37c8b6f1ce@jetbrains.com> Thanks for your comments, some jdi test were really failing :( As we switched from TreeSet to HashSet we have to explicitly set signature now. Please review the updated fix: http://cr.openjdk.java.net/~eushakov/8146986/webrev.01/ On 21-Mar-19 22:39, Jean Christophe Beyler wrote: > Hi Egor, > > Looks good to me as well, nit would be that the rest of the file does > not add a new-line for a else if: > > if () { > } else if () { > } > > instead of what you added: > > if () { > } > else if () { > } > > (Not a Reviewer) > > Thanks, > Jc > > > On Thu, Mar 21, 2019 at 11:31 AM serguei.spitsyn at oracle.com > > wrote: > > Hi Egor, > > The fix looks good to me. > > Thank you for taking care about it! > I've targeted this enhancement to 13. > > How do you test it? > It would be safe to run all JDI tests to make sure no new timeouts > are > observed. > > Thanks, > Serguei > > > On 3/21/19 10:19, Egor Ushakov wrote: > > Hi all, please review the fix > > > > it disables caching for types when signature is not provided as > > described in the bug (this is one of the proposed solutions in > the bug). > > > > https://bugs.openjdk.java.net/browse/JDK-8146986 > > http://cr.openjdk.java.net/~eushakov/8146986/webrev.00/ > > > > Thanks! > > > > > > -- > > Thanks, > Jc -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Mar 22 19:29:03 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 12:29:03 -0700 Subject: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs In-Reply-To: References: Message-ID: <4f453747-6d09-9ad9-22a1-62f3f1e0d9c8@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Mar 22 19:32:03 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 12:32:03 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> Message-ID: <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> Hi Gary, The changes look fine, but are you going to file the CRs I suggested (one for jtreg exclusiveAccess.dirs help text and one to further look into this issue)? thanks, Chris On 3/22/19 1:38 AM, gary.adams at oracle.com wrote: > This proposed change will configure the sun/tools/j* and > com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs > so the java attaching tests are not run concurrently. > > There is only annecdotal observations that multiple > tools are running when these tests are timing out. > 1000s of test runs have succeeded with this change in place. > > More investigation can be done to find the root cause > of these failures, but for now it's best to make the tests > run more reliably without timing out. > > ? Issues: > ??? https://bugs.openjdk.java.net/browse/JDK-8220242 > ??? https://bugs.openjdk.java.net/browse/JDK-8220295 > > ? Webrev: > ??? http://cr.openjdk.java.net/~gadams/8220295/webrev/ From serguei.spitsyn at oracle.com Fri Mar 22 20:25:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 22 Mar 2019 13:25:37 -0700 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: <77f28581-16fa-38ec-ed8d-fd37c8b6f1ce@jetbrains.com> References: <77f28581-16fa-38ec-ed8d-fd37c8b6f1ce@jetbrains.com> Message-ID: <2b701c72-5380-b110-bf49-53f851051f08@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Mar 22 20:53:15 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 22 Mar 2019 13:53:15 -0700 Subject: RFR: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing Message-ID: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> Please review the change that fixes the failure of the test when running with Graal. The problem here is that the test consumes all memory before JVMCI runtime is fully initialized. As a result the call to JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). The fix increases the maximum heap size the test uses and adds a delay to ensure the JVMCI Runtime is fully initialized before proceeding with provoking OutOfMemoryError. Before the change the test failure rate in Mach5 builds was about 25% . With this change after 900 rounds in Mach5 no failure was detected. The test execution time with the change is 50 second. Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 Thanks! --Daniil From chris.plummer at oracle.com Fri Mar 22 21:08:50 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 14:08:50 -0700 Subject: RFR: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> Message-ID: Hi Daniil, What triggers the JVMCI initialization, what (in general) is done during the initialization, and how did you come up with the 10k iterations and a 10s sleep to ensure that initialization is complete? What was the reason for the heap size increase? Does the OOME happen before 10k iterations if you don't increase the heap size? thanks, Chris On 3/22/19 1:53 PM, Daniil Titov wrote: > Please review the change that fixes the failure of the test when running with Graal. > > The problem here is that the test consumes all memory before JVMCI runtime is fully initialized. As a result the call to JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). > > The fix increases the maximum heap size the test uses and adds a delay to ensure the JVMCI Runtime is fully initialized before proceeding with provoking OutOfMemoryError. > > Before the change the test failure rate in Mach5 builds was about 25% . With this change after 900 rounds in Mach5 no failure was detected. The test execution time with the change is 50 second. > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Fri Mar 22 23:02:19 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 22 Mar 2019 16:02:19 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> Message-ID: <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> Hi Chris, Addind -XX:+PrintCompilation flag shows that the first compiled method is java.lang.Object::. Max heap size and parameter for the warmup stage (10K iterations) were found a posteriori, to ensure that JVMCI initialization is kicked but without throwing OutOfMemoryError. The heap increase is required otherwise a second OOME is thrown in the main thread after line 75 and in some cases even after line 86. It seems as JVMCI eats out all 8Mb of the heap. 75 System.gc(); 76 if ( ! Helper.checkResult("creating " + count + " objects") ) 77 return Consts.TEST_FAILED; 78 79 return Consts.TEST_PASSED; 80 } 81 82 public static void main(String[] args) { 83 args = nsk.share.jvmti.JVMTITest.commonInit(args); 84 85 int result = run(args, System.out); 86 System.out.println(result == Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); 87 System.exit(result + Consts.JCK_STATUS_BASE); 88 } Best regards, Daniil ?On 3/22/19, 2:09 PM, "Chris Plummer" wrote: Hi Daniil, What triggers the JVMCI initialization, what (in general) is done during the initialization, and how did you come up with the 10k iterations and a 10s sleep to ensure that initialization is complete? What was the reason for the heap size increase? Does the OOME happen before 10k iterations if you don't increase the heap size? thanks, Chris On 3/22/19 1:53 PM, Daniil Titov wrote: > Please review the change that fixes the failure of the test when running with Graal. > > The problem here is that the test consumes all memory before JVMCI runtime is fully initialized. As a result the call to JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). > > The fix increases the maximum heap size the test uses and adds a delay to ensure the JVMCI Runtime is fully initialized before proceeding with provoking OutOfMemoryError. > > Before the change the test failure rate in Mach5 builds was about 25% . With this change after 900 rounds in Mach5 no failure was detected. The test execution time with the change is 50 second. > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > Thanks! > --Daniil > > From gary.adams at oracle.com Fri Mar 22 23:01:16 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 19:01:16 -0400 Subject: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs In-Reply-To: <4f453747-6d09-9ad9-22a1-62f3f1e0d9c8@oracle.com> References: <4f453747-6d09-9ad9-22a1-62f3f1e0d9c8@oracle.com> Message-ID: <6fa60048-5b22-0ad3-6717-251e39d9ecc1@oracle.com> Yes. I just made it clearer. On 3/22/19 3:29 PM, Chris Plummer wrote: > Hi Gary, > > It looks like there was already "-" support for the CCS column. Was it > not working, or did you add the parens just to make it clearer to the > reader what it is matching on? > > thanks, > > Chris > > On 3/22/19 1:18 AM, gary.adams at oracle.com wrote: >> The M and CCS columns from jstat output can present a dash("-") >> for NaN values, such as : >> >> ----------System.out:(13/1261)---------- >> S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 >> 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 >> >> This proposed fix updates the awk scripts which are checking output >> lines. >> For the M and CCS columns, allow either a floating point value or a dash. >> e.g. "([0-9]+\.[0-9]+|-)" >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8221164/webrev/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8221164 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Mar 22 23:07:46 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 22 Mar 2019 19:07:46 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> Message-ID: Yes, there will be more follow up after the patch is pushed. I started a thread on jtreg-dev to discuss the current implementation and possibly an enhancement to meet the need of the vmTestbase tests that may have the wrong expectation of the current feature. e.g. the previous test harness had a nonconcurrent option. Filing a bug against jtreg will be cleaner after a bit more discussion there. You had also suggested creating a stress test to see if we can capture the jps hang. That may take a bit more time to consider and is not as urgent as some other work items in progress. On 3/22/19 3:32 PM, Chris Plummer wrote: > Hi Gary, > > The changes look fine, but are you going to file the CRs I suggested > (one for jtreg exclusiveAccess.dirs help text and one to further look > into this issue)? > > thanks, > > Chris > > On 3/22/19 1:38 AM, gary.adams at oracle.com wrote: >> This proposed change will configure the sun/tools/j* and >> com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs >> so the java attaching tests are not run concurrently. >> >> There is only annecdotal observations that multiple >> tools are running when these tests are timing out. >> 1000s of test runs have succeeded with this change in place. >> >> More investigation can be done to find the root cause >> of these failures, but for now it's best to make the tests >> run more reliably without timing out. >> >> ? Issues: >> ??? https://bugs.openjdk.java.net/browse/JDK-8220242 >> ??? https://bugs.openjdk.java.net/browse/JDK-8220295 >> >> ? Webrev: >> ??? http://cr.openjdk.java.net/~gadams/8220295/webrev/ > > > From chris.plummer at oracle.com Sat Mar 23 02:37:29 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 19:37:29 -0700 Subject: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs In-Reply-To: <6fa60048-5b22-0ad3-6717-251e39d9ecc1@oracle.com> References: <4f453747-6d09-9ad9-22a1-62f3f1e0d9c8@oracle.com> <6fa60048-5b22-0ad3-6717-251e39d9ecc1@oracle.com> Message-ID: <20e329d7-7105-c5fb-3cb8-de05f4d98155@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Mar 23 02:59:48 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 19:59:48 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> Message-ID: <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> Hi Daniil, So 8mb is enough to do at least 10,000 iterations and trigger JVMCI initialization, but the amount of memory needed after the System.gc() is more than the memory used by the loop (and then freed)? I wonder if more compilation is being triggered after the System.gc() call, and that uses a lot of memory. Also, I'm not comfortable with this concept of considering JVMCI to be initialized. You're making assumptions on the internal state of JVMCI. Other compilations could require other allocations that could end up failing. You also don't know how JVMCI behavior might change in the future, causing this test to fail again. Perhaps it is best not to run these ResourceExhausted tests with JVMCI. Their reliability is dubious enough already. thanks, Chris On 3/22/19 4:02 PM, Daniil Titov wrote: > Hi Chris, > > Addind -XX:+PrintCompilation flag shows that the first compiled method is java.lang.Object::. > > Max heap size and parameter for the warmup stage (10K iterations) were found a posteriori, to ensure that JVMCI initialization is kicked but without throwing OutOfMemoryError. > > The heap increase is required otherwise a second OOME is thrown in the main thread after line 75 and in some cases even after line 86. It seems as JVMCI eats out all 8Mb of the heap. > > 75 System.gc(); > 76 if ( ! Helper.checkResult("creating " + count + " objects") ) > 77 return Consts.TEST_FAILED; > 78 > 79 return Consts.TEST_PASSED; > 80 } > 81 > 82 public static void main(String[] args) { > 83 args = nsk.share.jvmti.JVMTITest.commonInit(args); > 84 > 85 int result = run(args, System.out); > 86 System.out.println(result == Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); > 87 System.exit(result + Consts.JCK_STATUS_BASE); > 88 } > > Best regards, > Daniil > > ?On 3/22/19, 2:09 PM, "Chris Plummer" wrote: > > Hi Daniil, > > What triggers the JVMCI initialization, what (in general) is done during > the initialization, and how did you come up with the 10k iterations and > a 10s sleep to ensure that initialization is complete? > > What was the reason for the heap size increase? Does the OOME happen > before 10k iterations if you don't increase the heap size? > > thanks, > > Chris > > On 3/22/19 1:53 PM, Daniil Titov wrote: > > Please review the change that fixes the failure of the test when running with Graal. > > > > The problem here is that the test consumes all memory before JVMCI runtime is fully initialized. As a result the call to JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) > > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). > > > > The fix increases the maximum heap size the test uses and adds a delay to ensure the JVMCI Runtime is fully initialized before proceeding with provoking OutOfMemoryError. > > > > Before the change the test failure rate in Mach5 builds was about 25% . With this change after 900 rounds in Mach5 no failure was detected. The test execution time with the change is 50 second. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > > > Thanks! > > --Daniil > > > > > > > > From chris.plummer at oracle.com Sat Mar 23 03:00:56 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 20:00:56 -0700 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> Message-ID: Ok. No need to write the stress test now, just file the CR. thanks, Chris On 3/22/19 4:07 PM, gary.adams at oracle.com wrote: > Yes, there will be more follow up after the patch is pushed. > > I started a thread on jtreg-dev to discuss the current implementation > and possibly an enhancement to meet the need of the vmTestbase > tests that may have the wrong expectation of the current feature. > e.g. the previous test harness had a nonconcurrent option. > > Filing a bug against jtreg will be cleaner after a bit more discussion > there. > > You had also suggested creating a stress test to see if we can > capture the jps hang. That may take a bit more time to consider > and is not as urgent as some other work items in progress. > > On 3/22/19 3:32 PM, Chris Plummer wrote: >> Hi Gary, >> >> The changes look fine, but are you going to file the CRs I suggested >> (one for jtreg exclusiveAccess.dirs help text and one to further look >> into this issue)? >> >> thanks, >> >> Chris >> >> On 3/22/19 1:38 AM, gary.adams at oracle.com wrote: >>> This proposed change will configure the sun/tools/j* and >>> com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs >>> so the java attaching tests are not run concurrently. >>> >>> There is only annecdotal observations that multiple >>> tools are running when these tests are timing out. >>> 1000s of test runs have succeeded with this change in place. >>> >>> More investigation can be done to find the root cause >>> of these failures, but for now it's best to make the tests >>> run more reliably without timing out. >>> >>> ? Issues: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8220242 >>> ??? https://bugs.openjdk.java.net/browse/JDK-8220295 >>> >>> ? Webrev: >>> ??? http://cr.openjdk.java.net/~gadams/8220295/webrev/ >> >> >> > From daniil.x.titov at oracle.com Sat Mar 23 03:23:35 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 22 Mar 2019 20:23:35 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> Message-ID: <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> Thank you, Chris! Please review a new version of the change that makes the test ignored if Graal is enabled. Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 Best regards, Daniil ?On 3/22/19, 7:59 PM, "Chris Plummer" wrote: Hi Daniil, So 8mb is enough to do at least 10,000 iterations and trigger JVMCI initialization, but the amount of memory needed after the System.gc() is more than the memory used by the loop (and then freed)? I wonder if more compilation is being triggered after the System.gc() call, and that uses a lot of memory. Also, I'm not comfortable with this concept of considering JVMCI to be initialized. You're making assumptions on the internal state of JVMCI. Other compilations could require other allocations that could end up failing. You also don't know how JVMCI behavior might change in the future, causing this test to fail again. Perhaps it is best not to run these ResourceExhausted tests with JVMCI. Their reliability is dubious enough already. thanks, Chris On 3/22/19 4:02 PM, Daniil Titov wrote: > Hi Chris, > > Addind -XX:+PrintCompilation flag shows that the first compiled method is java.lang.Object::. > > Max heap size and parameter for the warmup stage (10K iterations) were found a posteriori, to ensure that JVMCI initialization is kicked but without throwing OutOfMemoryError. > > The heap increase is required otherwise a second OOME is thrown in the main thread after line 75 and in some cases even after line 86. It seems as JVMCI eats out all 8Mb of the heap. > > 75 System.gc(); > 76 if ( ! Helper.checkResult("creating " + count + " objects") ) > 77 return Consts.TEST_FAILED; > 78 > 79 return Consts.TEST_PASSED; > 80 } > 81 > 82 public static void main(String[] args) { > 83 args = nsk.share.jvmti.JVMTITest.commonInit(args); > 84 > 85 int result = run(args, System.out); > 86 System.out.println(result == Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); > 87 System.exit(result + Consts.JCK_STATUS_BASE); > 88 } > > Best regards, > Daniil > > ?On 3/22/19, 2:09 PM, "Chris Plummer" wrote: > > Hi Daniil, > > What triggers the JVMCI initialization, what (in general) is done during > the initialization, and how did you come up with the 10k iterations and > a 10s sleep to ensure that initialization is complete? > > What was the reason for the heap size increase? Does the OOME happen > before 10k iterations if you don't increase the heap size? > > thanks, > > Chris > > On 3/22/19 1:53 PM, Daniil Titov wrote: > > Please review the change that fixes the failure of the test when running with Graal. > > > > The problem here is that the test consumes all memory before JVMCI runtime is fully initialized. As a result the call to JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) > > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). > > > > The fix increases the maximum heap size the test uses and adds a delay to ensure the JVMCI Runtime is fully initialized before proceeding with provoking OutOfMemoryError. > > > > Before the change the test failure rate in Mach5 builds was about 25% . With this change after 900 rounds in Mach5 no failure was detected. The test execution time with the change is 50 second. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > > > Thanks! > > --Daniil > > > > > > > > From jcbeyler at google.com Sat Mar 23 03:42:55 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 22 Mar 2019 20:42:55 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> Message-ID: For what it's worth Daniil, Webrev.02 LGTM :-) I do believe at some point we go seem to go back and forth about JVMCI testing and what we should do or not. I understand it should be a case by case in a lot of spots but perhaps we should document somewhere our stance for JVMCI test-bugs? Just food for thought? Thanks, Jc On Fri, Mar 22, 2019 at 8:26 PM Daniil Titov wrote: > Thank you, Chris! > > Please review a new version of the change that makes the test ignored if > Graal is enabled. > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > Best regards, > Daniil > > > > ?On 3/22/19, 7:59 PM, "Chris Plummer" wrote: > > Hi Daniil, > > So 8mb is enough to do at least 10,000 iterations and trigger JVMCI > initialization, but the amount of memory needed after the System.gc() > is > more than the memory used by the loop (and then freed)? I wonder if > more > compilation is being triggered after the System.gc() call, and that > uses > a lot of memory. > > Also, I'm not comfortable with this concept of considering JVMCI to be > initialized. You're making assumptions on the internal state of JVMCI. > Other compilations could require other allocations that could end up > failing. You also don't know how JVMCI behavior might change in the > future, causing this test to fail again. Perhaps it is best not to run > these ResourceExhausted tests with JVMCI. Their reliability is dubious > enough already. > > thanks, > > Chris > > On 3/22/19 4:02 PM, Daniil Titov wrote: > > Hi Chris, > > > > Addind -XX:+PrintCompilation flag shows that the first compiled > method is java.lang.Object::. > > > > Max heap size and parameter for the warmup stage (10K iterations) > were found a posteriori, to ensure that JVMCI initialization is kicked but > without throwing OutOfMemoryError. > > > > The heap increase is required otherwise a second OOME is thrown in > the main thread after line 75 and in some cases even after line 86. It > seems as JVMCI eats out all 8Mb of the heap. > > > > 75 System.gc(); > > 76 if ( ! Helper.checkResult("creating " + count + " > objects") ) > > 77 return Consts.TEST_FAILED; > > 78 > > 79 return Consts.TEST_PASSED; > > 80 } > > 81 > > 82 public static void main(String[] args) { > > 83 args = nsk.share.jvmti.JVMTITest.commonInit(args); > > 84 > > 85 int result = run(args, System.out); > > 86 System.out.println(result == Consts.TEST_PASSED ? > "TEST PASSED" : "TEST FAILED"); > > 87 System.exit(result + Consts.JCK_STATUS_BASE); > > 88 } > > > > Best regards, > > Daniil > > > > ?On 3/22/19, 2:09 PM, "Chris Plummer" > wrote: > > > > Hi Daniil, > > > > What triggers the JVMCI initialization, what (in general) is > done during > > the initialization, and how did you come up with the 10k > iterations and > > a 10s sleep to ensure that initialization is complete? > > > > What was the reason for the heap size increase? Does the OOME > happen > > before 10k iterations if you don't increase the heap size? > > > > thanks, > > > > Chris > > > > On 3/22/19 1:53 PM, Daniil Titov wrote: > > > Please review the change that fixes the failure of the test > when running with Graal. > > > > > > The problem here is that the test consumes all memory before > JVMCI runtime is fully initialized. As a result the call to > JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) > > > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 throws > OutOfmemoryError that is caught by CHECK_EXIT macro that in turn calls > JVMCICompiler::exit_on_pending_exception that performs vm_exit(-1). > > > > > > The fix increases the maximum heap size the test uses and > adds a delay to ensure the JVMCI Runtime is fully initialized before > proceeding with provoking OutOfMemoryError. > > > > > > Before the change the test failure rate in Mach5 builds was > about 25% . With this change after 900 rounds in Mach5 no failure was > detected. The test execution time with the change is 50 second. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Mar 23 05:57:58 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Mar 2019 22:57:58 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> Message-ID: <437dce4f-2cd0-bef5-b247-7edbeefb4fa3@oracle.com> An HTML attachment was scrubbed... URL: From hohensee at amazon.com Sat Mar 23 17:08:04 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 23 Mar 2019 17:08:04 +0000 Subject: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs Message-ID: <0BE3409B-A61B-478C-9D52-863579DAE453@amazon.com> +1. Paul From: serviceability-dev on behalf of Chris Plummer Date: Friday, March 22, 2019 at 7:38 PM To: "gary.adams at oracle.com" , OpenJDK Serviceability Subject: Re: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs Ok. The fix looks good to me. thanks, Chris On 3/22/19 4:01 PM, gary.adams at oracle.com wrote: Yes. I just made it clearer. On 3/22/19 3:29 PM, Chris Plummer wrote: Hi Gary, It looks like there was already "-" support for the CCS column. Was it not working, or did you add the parens just to make it clearer to the reader what it is matching on? thanks, Chris On 3/22/19 1:18 AM, gary.adams at oracle.com wrote: The M and CCS columns from jstat output can present a dash("-") for NaN values, such as : ----------System.out:(13/1261)---------- S0 S1 E O M CCS YGC YGCT FGC FGCT CGC CGCT GCT 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - - 0 0.000 0 0.000 0 0.000 0.000 0.00 0.00 0.00 0.00 - 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 0.00 100.00 0.00 14.85 31.29 28.19 1 0.571 0 0.000 0 0.000 0.571 This proposed fix updates the awk scripts which are checking output lines. For the M and CCS columns, allow either a floating point value or a dash. e.g. "([0-9]+\.[0-9]+|-)" Webrev: http://cr.openjdk.java.net/~gadams/8221164/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8221164 -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Sun Mar 24 05:41:54 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Sun, 24 Mar 2019 08:41:54 +0300 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: <2b701c72-5380-b110-bf49-53f851051f08@oracle.com> References: <77f28581-16fa-38ec-ed8d-fd37c8b6f1ce@jetbrains.com> <2b701c72-5380-b110-bf49-53f851051f08@oracle.com> Message-ID: <5d435195-a2f2-3ebf-4ff9-7ae971384770@jetbrains.com> Yes, the latest fix passed these test. Serguei, can you please sponsor the fix? On 22-Mar-19 23:25, serguei.spitsyn at oracle.com wrote: > Hi Egor, > > It looks Okay to me. > > Just want to make sure all important JDI tests are run. > There are two major JDI test suites: > ? jdk/com/sun/jdi and hotspot/jtreg/vmTestbase/nsk/jdi > > Thanks, > Serguei > > > On 3/22/19 11:51, Egor Ushakov wrote: >> >> Thanks for your comments, >> >> some jdi test were really failing :( >> As we switched from TreeSet to HashSet we have to explicitly set >> signature now. >> >> Please review the updated fix: >> http://cr.openjdk.java.net/~eushakov/8146986/webrev.01/ >> >> On 21-Mar-19 22:39, Jean Christophe Beyler wrote: >>> Hi Egor, >>> >>> Looks good to me as well, nit would be that the rest of the file >>> does not add a new-line for a else if: >>> >>> if () { >>> } else if () { >>> } >>> >>> instead of what you added: >>> >>> if () { >>> } >>> else if () { >>> } >>> >>> (Not a Reviewer) >>> >>> Thanks, >>> Jc >>> >>> >>> On Thu, Mar 21, 2019 at 11:31 AM serguei.spitsyn at oracle.com >>> >> > wrote: >>> >>> Hi Egor, >>> >>> The fix looks good to me. >>> >>> Thank you for taking care about it! >>> I've targeted this enhancement to 13. >>> >>> How do you test it? >>> It would be safe to run all JDI tests to make sure no new >>> timeouts are >>> observed. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/21/19 10:19, Egor Ushakov wrote: >>> > Hi all, please review the fix >>> > >>> > it disables caching for types when signature is not provided as >>> > described in the bug (this is one of the proposed solutions in >>> the bug). >>> > >>> > https://bugs.openjdk.java.net/browse/JDK-8146986 >>> > http://cr.openjdk.java.net/~eushakov/8146986/webrev.00/ >>> > >>> > Thanks! >>> > >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Mar 25 00:49:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 10:49:02 +1000 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <437dce4f-2cd0-bef5-b247-7edbeefb4fa3@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> <437dce4f-2cd0-bef5-b247-7edbeefb4fa3@oracle.com> Message-ID: <6d01f017-95af-f3ae-d0d4-311ef2124ce8@oracle.com> +2 VM components written in Java (of which JVMCI/Graal is the first) can simply not be anticipated by the existing JVM TI tests. David On 23/03/2019 3:57 pm, Chris Plummer wrote: > +1 > > Chris > > On 3/22/19 8:42 PM, Jean Christophe Beyler wrote: >> For what it's worth Daniil, >> >> Webrev.02 LGTM :-) >> >> I do believe at some point we go seem to go back and forth about JVMCI >> testing and what we should do or not. I understand it should be a case >> by case in a lot of spots but perhaps we should document somewhere our >> stance for JVMCI test-bugs? Just food for?thought? >> >> Thanks, >> Jc >> >> On Fri, Mar 22, 2019 at 8:26 PM Daniil Titov >> > wrote: >> >> Thank you, Chris! >> >> Please review a new version of the change that makes the test >> ignored if Graal is enabled. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >> >> Best regards, >> Daniil >> >> >> >> ?On 3/22/19, 7:59 PM, "Chris Plummer" > > wrote: >> >> ? ? Hi Daniil, >> >> ? ? So 8mb is enough to do at least 10,000 iterations and trigger >> JVMCI >> ? ? initialization, but the amount of memory needed after the >> System.gc() is >> ? ? more than the memory used by the loop (and then freed)? I >> wonder if more >> ? ? compilation is being triggered after the System.gc() call, and >> that uses >> ? ? a lot of memory. >> >> ? ? Also, I'm not comfortable with this concept of considering >> JVMCI to be >> ? ? initialized. You're making assumptions on the internal state >> of JVMCI. >> ? ? Other compilations could require other allocations that could >> end up >> ? ? failing. You also don't know how JVMCI behavior might change >> in the >> ? ? future, causing this test to fail again. Perhaps it is best >> not to run >> ? ? these ResourceExhausted tests with JVMCI. Their reliability is >> dubious >> ? ? enough already. >> >> ? ? thanks, >> >> ? ? Chris >> >> ? ? On 3/22/19 4:02 PM, Daniil Titov wrote: >> ? ? > Hi Chris, >> ? ? > >> ? ? > Addind -XX:+PrintCompilation flag shows that the first >> compiled method is java.lang.Object::. >> ? ? > >> ? ? > Max heap size and parameter for the warmup stage (10K >> iterations) were found a posteriori, to ensure that JVMCI >> initialization is kicked but without throwing OutOfMemoryError. >> ? ? > >> ? ? > The heap increase is required otherwise a second OOME is >> thrown in the main thread after line 75 and in some cases even >> after line 86. It seems as JVMCI eats out all 8Mb of the heap. >> ? ? > >> ? ? >? ? 75? ? ? ? ?System.gc(); >> ? ? >? ? 76? ? ? ? ?if ( ! Helper.checkResult("creating " + count >> + " objects") ) >> ? ? >? ? 77? ? ? ? ? ? ?return Consts.TEST_FAILED; >> ? ? >? ? 78 >> ? ? >? ? 79? ? ? ? ?return Consts.TEST_PASSED; >> ? ? >? ? 80? ? ?} >> ? ? >? ? 81 >> ? ? >? ? 82? ? ?public static void main(String[] args) { >> ? ? >? ? 83? ? ? ? ?args = nsk.share.jvmti.JVMTITest.commonInit(args); >> ? ? >? ? 84 >> ? ? >? ? 85? ? ? ? ?int result = run(args, System.out); >> ? ? >? ? 86? ? ? ? ?System.out.println(result == >> Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); >> ? ? >? ? 87? ? ? ? ?System.exit(result + Consts.JCK_STATUS_BASE); >> ? ? >? ? 88? ? ?} >> ? ? > >> ? ? > Best regards, >> ? ? > Daniil >> ? ? > >> ? ? > ?On 3/22/19, 2:09 PM, "Chris Plummer" >> > wrote: >> ? ? > >> ? ? >? ? ? Hi Daniil, >> ? ? > >> ? ? >? ? ? What triggers the JVMCI initialization, what (in >> general) is done during >> ? ? >? ? ? the initialization, and how did you come up with the >> 10k iterations and >> ? ? >? ? ? a 10s sleep to ensure that initialization is complete? >> ? ? > >> ? ? >? ? ? What was the reason for the heap size increase? Does >> the OOME happen >> ? ? >? ? ? before 10k iterations if you don't increase the heap size? >> ? ? > >> ? ? >? ? ? thanks, >> ? ? > >> ? ? >? ? ? Chris >> ? ? > >> ? ? >? ? ? On 3/22/19 1:53 PM, Daniil Titov wrote: >> ? ? >? ? ? > Please review the change that fixes the failure of >> the test when running with Graal. >> ? ? >? ? ? > >> ? ? >? ? ? > The problem here is that the test consumes all memory >> before JVMCI runtime is fully initialized. As a result the call to >> JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) >> ? ? >? ? ? > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 >> throws OutOfmemoryError that is caught by CHECK_EXIT macro that in >> turn calls JVMCICompiler::exit_on_pending_exception that performs >> vm_exit(-1). >> ? ? >? ? ? > >> ? ? >? ? ? > The fix increases the maximum heap size the test uses >> and adds a delay to ensure the JVMCI Runtime is fully initialized >> before proceeding with provoking OutOfMemoryError. >> ? ? >? ? ? > >> ? ? >? ? ? > Before the change? the test failure rate in Mach5 >> builds was about 25% . With this change after 900 rounds in Mach5 >> no failure was detected. The test execution time with the change >> is 50 second. >> ? ? >? ? ? > >> ? ? >? ? ? > Webrev: >> http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ >> ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >> ? ? >? ? ? > >> ? ? >? ? ? > Thanks! >> ? ? >? ? ? > --Daniil >> ? ? >? ? ? > >> ? ? >? ? ? > >> ? ? > >> ? ? > >> ? ? > >> ? ? > >> >> >> >> >> >> >> >> -- >> >> Thanks, >> Jc > > From david.holmes at oracle.com Mon Mar 25 01:09:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 11:09:17 +1000 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> Message-ID: Just an aside, but it seems that other tests that happen to use this functionality can also run into these transient timeout issues and likely for the same underlying reasons. See for example: JDK-8217347: [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out So it would be good to get to the bottom of the underlying problem here. Cheers, David On 23/03/2019 1:00 pm, Chris Plummer wrote: > Ok. No need to write the stress test now, just file the CR. > > thanks, > > Chris > > On 3/22/19 4:07 PM, gary.adams at oracle.com wrote: >> Yes, there will be more follow up after the patch is pushed. >> >> I started a thread on jtreg-dev to discuss the current implementation >> and possibly an enhancement to meet the need of the vmTestbase >> tests that may have the wrong expectation of the current feature. >> e.g. the previous test harness had a nonconcurrent option. >> >> Filing a bug against jtreg will be cleaner after a bit more discussion >> there. >> >> You had also suggested creating a stress test to see if we can >> capture the jps hang. That may take a bit more time to consider >> and is not as urgent as some other work items in progress. >> >> On 3/22/19 3:32 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> The changes look fine, but are you going to file the CRs I suggested >>> (one for jtreg exclusiveAccess.dirs help text and one to further look >>> into this issue)? >>> >>> thanks, >>> >>> Chris >>> >>> On 3/22/19 1:38 AM, gary.adams at oracle.com wrote: >>>> This proposed change will configure the sun/tools/j* and >>>> com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs >>>> so the java attaching tests are not run concurrently. >>>> >>>> There is only annecdotal observations that multiple >>>> tools are running when these tests are timing out. >>>> 1000s of test runs have succeeded with this change in place. >>>> >>>> More investigation can be done to find the root cause >>>> of these failures, but for now it's best to make the tests >>>> run more reliably without timing out. >>>> >>>> ? Issues: >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8220242 >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8220295 >>>> >>>> ? Webrev: >>>> ??? http://cr.openjdk.java.net/~gadams/8220295/webrev/ >>> >>> >>> >> > > From ioi.lam at oracle.com Mon Mar 25 03:46:50 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 24 Mar 2019 20:46:50 -0700 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out Message-ID: https://bugs.openjdk.java.net/browse/JDK-8217347 http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ This test case used VirtualMachine.list() to find the pid of the the child process. However, as David Holmes commented in the bug report, it's suspected that this call may lead to timeout. In any case, since Process.pid() has been added since JDK 9, it's better to call this API directly. That way, we can avoid unnecessary dependency on VirtualMachine.list(). Tested with tiers{1,2,3}. Also removed some unnecessary @module and import lines. Thanks - Ioi From david.holmes at oracle.com Mon Mar 25 04:14:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 14:14:11 +1000 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: References: Message-ID: Hi Ioi, On 25/03/2019 1:46 pm, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8217347 > http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ > > > This test case used VirtualMachine.list() to find the pid of the the child > process. However, as David Holmes commented in the bug report, it's > suspected that this call may lead to timeout. > > In any case, since Process.pid() has been added since JDK 9, it's better > to call this > API directly. That way, we can avoid unnecessary dependency on > VirtualMachine.list(). In so far as I can see how you replaced the VM.list() with Process.pid() this seems okay. I'm having trouble actually understanding the handshake being used to control things though. I would have expected the target VM to create the flagfile to indicate it is ready for attaching, then it would wait for the flagfile to be deleted. Thanks, David > Tested with tiers{1,2,3}. Also removed some unnecessary @module and > import lines. > > Thanks > - Ioi From ioi.lam at oracle.com Mon Mar 25 05:06:34 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 24 Mar 2019 22:06:34 -0700 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: References: Message-ID: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> On 3/24/19 9:14 PM, David Holmes wrote: > Hi Ioi, > > On 25/03/2019 1:46 pm, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8217347 >> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ >> >> >> This test case used VirtualMachine.list() to find the pid of the the >> child >> process. However, as David Holmes commented in the bug report, it's >> suspected that this call may lead to timeout. >> >> In any case, since Process.pid() has been added since JDK 9, it's >> better to call this >> API directly. That way, we can avoid unnecessary dependency on >> VirtualMachine.list(). > > In so far as I can see how you replaced the VM.list() with > Process.pid() this seems okay. I'm having trouble actually > understanding the handshake being used to control things though. I > would have expected the target VM to create the flagfile to indicate > it is ready for attaching, then it would wait for the flagfile to be > deleted. > Hi David, As far as I can tell, the handshake is this: the main test process creates the flag file and passes the name of the flag file to the child process (whose main class is InstrumentationApp). The child process will wait until the main process deletes the flag file. After the child process is launched, the main process attaches to it (using the child's pid), and then deletes the flag file. At that point, the child will resume execution. BTW, I found this comment to be out-dated so I changed it: -??????? // At this point, the child process is not yet launched. Note that -??????? // TestCommon.exec() and OutputAnalyzer.OutputAnalyzer() both block -??????? // until the child process has finished. -??????? // -??????? // So, we will launch a AgentAttachThread which will poll the system -??????? // until the child process is launched, and then do the attachment. -??????? // The child process is uniquely identified by having flagFile in its -??????? // command-line -- see AgentAttachThread.getPid(). +??????? // At this point, the child process is not yet launched. +??????? // We will launch a AgentAttachThread which will wait until +??????? // the child process's pid is known, and then do the attachment. ???????? AgentAttachThread t = new AgentAttachThread(flagFile, agentJar); ???????? t.start(); ???????? return t; Thanks - Ioi > Thanks, > David > >> Tested with tiers{1,2,3}. Also removed some unnecessary @module and >> import lines. >> >> Thanks >> - Ioi From chris.plummer at oracle.com Mon Mar 25 05:14:34 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 24 Mar 2019 22:14:34 -0700 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <6d01f017-95af-f3ae-d0d4-311ef2124ce8@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> <437dce4f-2cd0-bef5-b247-7edbeefb4fa3@oracle.com> <6d01f017-95af-f3ae-d0d4-311ef2124ce8@oracle.com> Message-ID: <7ecd4661-628a-28de-26a7-2460dc16e490@oracle.com> Using that logic, we may at some point not be able to reliably run the JVMTI tests since Graal may always be present. Chris On 3/24/19 5:49 PM, David Holmes wrote: > +2 > > VM components written in Java (of which JVMCI/Graal is the first) can > simply not be anticipated by the existing JVM TI tests. > > David > > On 23/03/2019 3:57 pm, Chris Plummer wrote: >> +1 >> >> Chris >> >> On 3/22/19 8:42 PM, Jean Christophe Beyler wrote: >>> For what it's worth Daniil, >>> >>> Webrev.02 LGTM :-) >>> >>> I do believe at some point we go seem to go back and forth about >>> JVMCI testing and what we should do or not. I understand it should >>> be a case by case in a lot of spots but perhaps we should document >>> somewhere our stance for JVMCI test-bugs? Just food for?thought? >>> >>> Thanks, >>> Jc >>> >>> On Fri, Mar 22, 2019 at 8:26 PM Daniil Titov >>> > wrote: >>> >>> ??? Thank you, Chris! >>> >>> ??? Please review a new version of the change that makes the test >>> ??? ignored if Graal is enabled. >>> >>> ??? Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/ >>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >>> >>> ??? Best regards, >>> ??? Daniil >>> >>> >>> >>> ??? ?On 3/22/19, 7:59 PM, "Chris Plummer" >> ??? > wrote: >>> >>> ??? ? ? Hi Daniil, >>> >>> ??? ? ? So 8mb is enough to do at least 10,000 iterations and trigger >>> ??? JVMCI >>> ??? ? ? initialization, but the amount of memory needed after the >>> ??? System.gc() is >>> ??? ? ? more than the memory used by the loop (and then freed)? I >>> ??? wonder if more >>> ??? ? ? compilation is being triggered after the System.gc() call, and >>> ??? that uses >>> ??? ? ? a lot of memory. >>> >>> ??? ? ? Also, I'm not comfortable with this concept of considering >>> ??? JVMCI to be >>> ??? ? ? initialized. You're making assumptions on the internal state >>> ??? of JVMCI. >>> ??? ? ? Other compilations could require other allocations that could >>> ??? end up >>> ??? ? ? failing. You also don't know how JVMCI behavior might change >>> ??? in the >>> ??? ? ? future, causing this test to fail again. Perhaps it is best >>> ??? not to run >>> ??? ? ? these ResourceExhausted tests with JVMCI. Their reliability is >>> ??? dubious >>> ??? ? ? enough already. >>> >>> ??? ? ? thanks, >>> >>> ??? ? ? Chris >>> >>> ??? ? ? On 3/22/19 4:02 PM, Daniil Titov wrote: >>> ??? ? ? > Hi Chris, >>> ??? ? ? > >>> ??? ? ? > Addind -XX:+PrintCompilation flag shows that the first >>> ??? compiled method is java.lang.Object::. >>> ??? ? ? > >>> ??? ? ? > Max heap size and parameter for the warmup stage (10K >>> ??? iterations) were found a posteriori, to ensure that JVMCI >>> ??? initialization is kicked but without throwing OutOfMemoryError. >>> ??? ? ? > >>> ??? ? ? > The heap increase is required otherwise a second OOME is >>> ??? thrown in the main thread after line 75 and in some cases even >>> ??? after line 86. It seems as JVMCI eats out all 8Mb of the heap. >>> ??? ? ? > >>> ??? ? ? >? ? 75? ? ? ? ?System.gc(); >>> ??? ? ? >? ? 76? ? ? ? ?if ( ! Helper.checkResult("creating " + count >>> ??? + " objects") ) >>> ??? ? ? >? ? 77? ? ? ? ? ? ?return Consts.TEST_FAILED; >>> ??? ? ? >? ? 78 >>> ??? ? ? >? ? 79? ? ? ? ?return Consts.TEST_PASSED; >>> ??? ? ? >? ? 80? ? ?} >>> ??? ? ? >? ? 81 >>> ??? ? ? >? ? 82? ? ?public static void main(String[] args) { >>> ??? ? ? >? ? 83? ? ? ? ?args = >>> nsk.share.jvmti.JVMTITest.commonInit(args); >>> ??? ? ? >? ? 84 >>> ??? ? ? >? ? 85? ? ? ? ?int result = run(args, System.out); >>> ??? ? ? >? ? 86? ? ? ? ?System.out.println(result == >>> ??? Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); >>> ??? ? ? >? ? 87? ? ? ? ?System.exit(result + Consts.JCK_STATUS_BASE); >>> ??? ? ? >? ? 88? ? ?} >>> ??? ? ? > >>> ??? ? ? > Best regards, >>> ??? ? ? > Daniil >>> ??? ? ? > >>> ??? ? ? > ?On 3/22/19, 2:09 PM, "Chris Plummer" >>> ??? > wrote: >>> ??? ? ? > >>> ??? ? ? >? ? ? Hi Daniil, >>> ??? ? ? > >>> ??? ? ? >? ? ? What triggers the JVMCI initialization, what (in >>> ??? general) is done during >>> ??? ? ? >? ? ? the initialization, and how did you come up with the >>> ??? 10k iterations and >>> ??? ? ? >? ? ? a 10s sleep to ensure that initialization is complete? >>> ??? ? ? > >>> ??? ? ? >? ? ? What was the reason for the heap size increase? Does >>> ??? the OOME happen >>> ??? ? ? >? ? ? before 10k iterations if you don't increase the heap >>> size? >>> ??? ? ? > >>> ??? ? ? >? ? ? thanks, >>> ??? ? ? > >>> ??? ? ? >? ? ? Chris >>> ??? ? ? > >>> ??? ? ? >? ? ? On 3/22/19 1:53 PM, Daniil Titov wrote: >>> ??? ? ? >? ? ? > Please review the change that fixes the failure of >>> ??? the test when running with Graal. >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > The problem here is that the test consumes all memory >>> ??? before JVMCI runtime is fully initialized. As a result the call to >>> ??? JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) >>> ??? ? ? >? ? ? > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 >>> ??? throws OutOfmemoryError that is caught by CHECK_EXIT macro that in >>> ??? turn calls JVMCICompiler::exit_on_pending_exception that performs >>> ??? vm_exit(-1). >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > The fix increases the maximum heap size the test uses >>> ??? and adds a delay to ensure the JVMCI Runtime is fully initialized >>> ??? before proceeding with provoking OutOfMemoryError. >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > Before the change? the test failure rate in Mach5 >>> ??? builds was about 25% . With this change after 900 rounds in Mach5 >>> ??? no failure was detected. The test execution time with the change >>> ??? is 50 second. >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > Webrev: >>> ??? http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ >>> ??? ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > Thanks! >>> ??? ? ? >? ? ? > --Daniil >>> ??? ? ? >? ? ? > >>> ??? ? ? >? ? ? > >>> ??? ? ? > >>> ??? ? ? > >>> ??? ? ? > >>> ??? ? ? > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> From david.holmes at oracle.com Mon Mar 25 05:28:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 15:28:03 +1000 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> References: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> Message-ID: <2134a4ab-a731-2b71-4963-8f5f83c11a04@oracle.com> On 25/03/2019 3:06 pm, Ioi Lam wrote: > > > On 3/24/19 9:14 PM, David Holmes wrote: >> Hi Ioi, >> >> On 25/03/2019 1:46 pm, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8217347 >>> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ >>> >>> >>> This test case used VirtualMachine.list() to find the pid of the the >>> child >>> process. However, as David Holmes commented in the bug report, it's >>> suspected that this call may lead to timeout. >>> >>> In any case, since Process.pid() has been added since JDK 9, it's >>> better to call this >>> API directly. That way, we can avoid unnecessary dependency on >>> VirtualMachine.list(). >> >> In so far as I can see how you replaced the VM.list() with >> Process.pid() this seems okay. I'm having trouble actually >> understanding the handshake being used to control things though. I >> would have expected the target VM to create the flagfile to indicate >> it is ready for attaching, then it would wait for the flagfile to be >> deleted. >> > > Hi David, > > As far as I can tell, the handshake is this: the main test process > creates the flag file and passes the name of the flag file to the child > process (whose main class is InstrumentationApp). The child process will > wait until the main process deletes the flag file. > > After the child process is launched, the main process attaches to it > (using the child's pid), and then deletes the flag file. At that point, > the child will resume execution. Okay but the problem is that the main process can try to attach to the child process before the child is ready to be attached to. This is a day one limitation of the attach-on-demand process. If the child process created the flags file (using the name supplied by the main process) the main process could wait until it sees it to do the attach. Anyway this is not directly related to your fix, just be aware this test can fail in obscure ways as the child process may silently disappear if the SIGQUIT used to attach-on-demand arrives too soon. > > BTW, I found this comment to be out-dated so I changed it: > > -??????? // At this point, the child process is not yet launched. Note that > -??????? // TestCommon.exec() and OutputAnalyzer.OutputAnalyzer() both > block > -??????? // until the child process has finished. > -??????? // > -??????? // So, we will launch a AgentAttachThread which will poll the > system > -??????? // until the child process is launched, and then do the > attachment. > -??????? // The child process is uniquely identified by having flagFile > in its > -??????? // command-line -- see AgentAttachThread.getPid(). > > +??????? // At this point, the child process is not yet launched. > +??????? // We will launch a AgentAttachThread which will wait until > +??????? // the child process's pid is known, and then do the attachment. Okay but the comment is out of date because you now return the process directly, which means you no longer need the AgentAttachThread at all, you can do the attach logic directly from the main thread. Cheers, David ----- > ???????? AgentAttachThread t = new AgentAttachThread(flagFile, agentJar); > ???????? t.start(); > ???????? return t; > > Thanks > - Ioi > >> Thanks, >> David >> >>> Tested with tiers{1,2,3}. Also removed some unnecessary @module and >>> import lines. >>> >>> Thanks >>> - Ioi > From david.holmes at oracle.com Mon Mar 25 06:28:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 16:28:04 +1000 Subject: 8217827: [Graal] Some vmTestbase/nsk/jvmti/ResourceExhausted tests failing In-Reply-To: <7ecd4661-628a-28de-26a7-2460dc16e490@oracle.com> References: <031ACBCC-36C1-446F-B249-246511E8DEA3@oracle.com> <91D65BD7-817B-4375-895F-1EADEFBE362F@oracle.com> <4cf67d13-27ae-9b8c-b156-9a0290103aa5@oracle.com> <184B10C5-BDF6-4FDC-B5DA-F4F7797831FB@oracle.com> <437dce4f-2cd0-bef5-b247-7edbeefb4fa3@oracle.com> <6d01f017-95af-f3ae-d0d4-311ef2124ce8@oracle.com> <7ecd4661-628a-28de-26a7-2460dc16e490@oracle.com> Message-ID: On 25/03/2019 3:14 pm, Chris Plummer wrote: > Using that logic, we may at some point not be able to reliably run the > JVMTI tests since Graal may always be present. We can't reliably run a lot of them now with JVMCI/Graal. We either need to modify all the affected tests, or we need to change how JVMCI/Graal interacts with JVM TI - which is currently under discussion. Some tests, like these resource exhaustion tests, may never be reliable in an execution environment where the VM components can encounter the resource exhaustion rather than the application/test code. David > Chris > > On 3/24/19 5:49 PM, David Holmes wrote: >> +2 >> >> VM components written in Java (of which JVMCI/Graal is the first) can >> simply not be anticipated by the existing JVM TI tests. >> >> David >> >> On 23/03/2019 3:57 pm, Chris Plummer wrote: >>> +1 >>> >>> Chris >>> >>> On 3/22/19 8:42 PM, Jean Christophe Beyler wrote: >>>> For what it's worth Daniil, >>>> >>>> Webrev.02 LGTM :-) >>>> >>>> I do believe at some point we go seem to go back and forth about >>>> JVMCI testing and what we should do or not. I understand it should >>>> be a case by case in a lot of spots but perhaps we should document >>>> somewhere our stance for JVMCI test-bugs? Just food for?thought? >>>> >>>> Thanks, >>>> Jc >>>> >>>> On Fri, Mar 22, 2019 at 8:26 PM Daniil Titov >>>> > wrote: >>>> >>>> ??? Thank you, Chris! >>>> >>>> ??? Please review a new version of the change that makes the test >>>> ??? ignored if Graal is enabled. >>>> >>>> ??? Webrev: http://cr.openjdk.java.net/~dtitov/8217827/webrev.02/ >>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >>>> >>>> ??? Best regards, >>>> ??? Daniil >>>> >>>> >>>> >>>> ??? ?On 3/22/19, 7:59 PM, "Chris Plummer" >>> ??? > wrote: >>>> >>>> ??? ? ? Hi Daniil, >>>> >>>> ??? ? ? So 8mb is enough to do at least 10,000 iterations and trigger >>>> ??? JVMCI >>>> ??? ? ? initialization, but the amount of memory needed after the >>>> ??? System.gc() is >>>> ??? ? ? more than the memory used by the loop (and then freed)? I >>>> ??? wonder if more >>>> ??? ? ? compilation is being triggered after the System.gc() call, and >>>> ??? that uses >>>> ??? ? ? a lot of memory. >>>> >>>> ??? ? ? Also, I'm not comfortable with this concept of considering >>>> ??? JVMCI to be >>>> ??? ? ? initialized. You're making assumptions on the internal state >>>> ??? of JVMCI. >>>> ??? ? ? Other compilations could require other allocations that could >>>> ??? end up >>>> ??? ? ? failing. You also don't know how JVMCI behavior might change >>>> ??? in the >>>> ??? ? ? future, causing this test to fail again. Perhaps it is best >>>> ??? not to run >>>> ??? ? ? these ResourceExhausted tests with JVMCI. Their reliability is >>>> ??? dubious >>>> ??? ? ? enough already. >>>> >>>> ??? ? ? thanks, >>>> >>>> ??? ? ? Chris >>>> >>>> ??? ? ? On 3/22/19 4:02 PM, Daniil Titov wrote: >>>> ??? ? ? > Hi Chris, >>>> ??? ? ? > >>>> ??? ? ? > Addind -XX:+PrintCompilation flag shows that the first >>>> ??? compiled method is java.lang.Object::. >>>> ??? ? ? > >>>> ??? ? ? > Max heap size and parameter for the warmup stage (10K >>>> ??? iterations) were found a posteriori, to ensure that JVMCI >>>> ??? initialization is kicked but without throwing OutOfMemoryError. >>>> ??? ? ? > >>>> ??? ? ? > The heap increase is required otherwise a second OOME is >>>> ??? thrown in the main thread after line 75 and in some cases even >>>> ??? after line 86. It seems as JVMCI eats out all 8Mb of the heap. >>>> ??? ? ? > >>>> ??? ? ? >? ? 75? ? ? ? ?System.gc(); >>>> ??? ? ? >? ? 76? ? ? ? ?if ( ! Helper.checkResult("creating " + count >>>> ??? + " objects") ) >>>> ??? ? ? >? ? 77? ? ? ? ? ? ?return Consts.TEST_FAILED; >>>> ??? ? ? >? ? 78 >>>> ??? ? ? >? ? 79? ? ? ? ?return Consts.TEST_PASSED; >>>> ??? ? ? >? ? 80? ? ?} >>>> ??? ? ? >? ? 81 >>>> ??? ? ? >? ? 82? ? ?public static void main(String[] args) { >>>> ??? ? ? >? ? 83? ? ? ? ?args = >>>> nsk.share.jvmti.JVMTITest.commonInit(args); >>>> ??? ? ? >? ? 84 >>>> ??? ? ? >? ? 85? ? ? ? ?int result = run(args, System.out); >>>> ??? ? ? >? ? 86? ? ? ? ?System.out.println(result == >>>> ??? Consts.TEST_PASSED ? "TEST PASSED" : "TEST FAILED"); >>>> ??? ? ? >? ? 87? ? ? ? ?System.exit(result + Consts.JCK_STATUS_BASE); >>>> ??? ? ? >? ? 88? ? ?} >>>> ??? ? ? > >>>> ??? ? ? > Best regards, >>>> ??? ? ? > Daniil >>>> ??? ? ? > >>>> ??? ? ? > ?On 3/22/19, 2:09 PM, "Chris Plummer" >>>> ??? > wrote: >>>> ??? ? ? > >>>> ??? ? ? >? ? ? Hi Daniil, >>>> ??? ? ? > >>>> ??? ? ? >? ? ? What triggers the JVMCI initialization, what (in >>>> ??? general) is done during >>>> ??? ? ? >? ? ? the initialization, and how did you come up with the >>>> ??? 10k iterations and >>>> ??? ? ? >? ? ? a 10s sleep to ensure that initialization is complete? >>>> ??? ? ? > >>>> ??? ? ? >? ? ? What was the reason for the heap size increase? Does >>>> ??? the OOME happen >>>> ??? ? ? >? ? ? before 10k iterations if you don't increase the heap >>>> size? >>>> ??? ? ? > >>>> ??? ? ? >? ? ? thanks, >>>> ??? ? ? > >>>> ??? ? ? >? ? ? Chris >>>> ??? ? ? > >>>> ??? ? ? >? ? ? On 3/22/19 1:53 PM, Daniil Titov wrote: >>>> ??? ? ? >? ? ? > Please review the change that fixes the failure of >>>> ??? the test when running with Graal. >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > The problem here is that the test consumes all memory >>>> ??? before JVMCI runtime is fully initialized. As a result the call to >>>> ??? JVMCIRuntime::get_HotSpotJVMCIRuntime(CHECK_EXIT) >>>> ??? ? ? >? ? ? > at src/hotspot/share/jvmci/jvmciCompiler.cpp:132 >>>> ??? throws OutOfmemoryError that is caught by CHECK_EXIT macro that in >>>> ??? turn calls JVMCICompiler::exit_on_pending_exception that performs >>>> ??? vm_exit(-1). >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > The fix increases the maximum heap size the test uses >>>> ??? and adds a delay to ensure the JVMCI Runtime is fully initialized >>>> ??? before proceeding with provoking OutOfMemoryError. >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > Before the change? the test failure rate in Mach5 >>>> ??? builds was about 25% . With this change after 900 rounds in Mach5 >>>> ??? no failure was detected. The test execution time with the change >>>> ??? is 50 second. >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > Webrev: >>>> ??? http://cr.openjdk.java.net/~dtitov/8217827/webrev.01/ >>>> ??? ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8217827 >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > Thanks! >>>> ??? ? ? >? ? ? > --Daniil >>>> ??? ? ? >? ? ? > >>>> ??? ? ? >? ? ? > >>>> ??? ? ? > >>>> ??? ? ? > >>>> ??? ? ? > >>>> ??? ? ? > >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >>> > From per.liden at oracle.com Mon Mar 25 09:59:35 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Mar 2019 10:59:35 +0100 Subject: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java Message-ID: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> Clean up serviceability/sa/TestUniverse.java to remove the need for the withZ/withoutZ option we currently pass in. This also changes the test to only run with the selected GC instead of testing all GCs every time, which should save us some cycles in testing. Bug: https://bugs.openjdk.java.net/browse/JDK-8221396 Webrev: http://cr.openjdk.java.net/~pliden/8221396/webrev.0 /Per From claes.redestad at oracle.com Mon Mar 25 10:46:01 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Mar 2019 11:46:01 +0100 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Message-ID: Ping. Still passes tests and is necessary to unblock work to more aggressively archive invariant heap graphs. /Claes On 2019-03-15 17:26, Claes Redestad wrote: > Hi, > > I ran into a few additional test issues, one exposing a crash in jmap > -histo:live in a test that seems to have been problem listed when I > ran tests earlier. > > Also filtering out archived-but-not-yet-loaded classes in > KlassInfoBucket::lookup makes tests exercising jmap etc work as intended > in the presence of archived classes: > > http://cr.openjdk.java.net/~redestad/8220682/open.01/ > > Testing: tier1-3 with 8214712 ongoing > > /Claes > > On 2019-03-15 16:28, Jiangli Zhou wrote: >> +1 >> >> Thanks, >> Jiangli >> >> On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler >> > wrote: >> >> ??? Hi Claes, >> >> ??? Looks good to me. For those who would want to see the patch change >> ??? done in the serviceability-agent: >> ??? http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da >> >> ??? Thanks, >> ??? Jc >> From claes.redestad at oracle.com Mon Mar 25 11:23:35 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Mar 2019 12:23:35 +0100 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Message-ID: [Adding hotspot-runtime-dev] On 2019-03-15 17:26, Claes Redestad wrote: > Hi, > > I ran into a few additional test issues, one exposing a crash in jmap > -histo:live in a test that seems to have been problem listed when I > ran tests earlier. > > Also filtering out archived-but-not-yet-loaded classes in > KlassInfoBucket::lookup makes tests exercising jmap etc work as intended > in the presence of archived classes: > > http://cr.openjdk.java.net/~redestad/8220682/open.01/ > > Testing: tier1-3 with 8214712 ongoing > > /Claes > > On 2019-03-15 16:28, Jiangli Zhou wrote: >> +1 >> >> Thanks, >> Jiangli >> >> On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler >> > wrote: >> >> ??? Hi Claes, >> >> ??? Looks good to me. For those who would want to see the patch change >> ??? done in the serviceability-agent: >> ??? http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da >> >> ??? Thanks, >> ??? Jc >> From gary.adams at oracle.com Sun Mar 24 23:51:23 2019 From: gary.adams at oracle.com (Gary Adams) Date: Sun, 24 Mar 2019 19:51:23 -0400 Subject: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out In-Reply-To: References: <2dd59c9e-3c44-b40f-f880-b6be0631e61c@oracle.com> <800940e9-03b8-e931-a169-fbf43dd53e4a@oracle.com> Message-ID: <5C9817FB.2030806@oracle.com> Agreed. Unless a test is specifically testing the functionality of VirtualMachine.list() it should not be used for locating a pid, which is easily provided from the ProcessBuilder after the process is started. Reducing the environmental interference of scanning all running java processes is our best bet at this point for these intermittent timeouts. I do plan to follow up to find the root cause of these hangs, but at this time we don't have a concrete problem identified. We just know which swamp to look for the beast. On 3/24/19, 9:09 PM, David Holmes wrote: > Just an aside, but it seems that other tests that happen to use this > functionality can also run into these transient timeout issues and > likely for the same underlying reasons. See for example: > > JDK-8217347: [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java > timed out > > So it would be good to get to the bottom of the underlying problem here. > > Cheers, > David > > On 23/03/2019 1:00 pm, Chris Plummer wrote: >> Ok. No need to write the stress test now, just file the CR. >> >> thanks, >> >> Chris >> >> On 3/22/19 4:07 PM, gary.adams at oracle.com wrote: >>> Yes, there will be more follow up after the patch is pushed. >>> >>> I started a thread on jtreg-dev to discuss the current implementation >>> and possibly an enhancement to meet the need of the vmTestbase >>> tests that may have the wrong expectation of the current feature. >>> e.g. the previous test harness had a nonconcurrent option. >>> >>> Filing a bug against jtreg will be cleaner after a bit more >>> discussion there. >>> >>> You had also suggested creating a stress test to see if we can >>> capture the jps hang. That may take a bit more time to consider >>> and is not as urgent as some other work items in progress. >>> >>> On 3/22/19 3:32 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> The changes look fine, but are you going to file the CRs I >>>> suggested (one for jtreg exclusiveAccess.dirs help text and one to >>>> further look into this issue)? >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 3/22/19 1:38 AM, gary.adams at oracle.com wrote: >>>>> This proposed change will configure the sun/tools/j* and >>>>> com/sun/tools/attach tests to be labeled as jtreg >>>>> exclusiveAccess.dirs >>>>> so the java attaching tests are not run concurrently. >>>>> >>>>> There is only annecdotal observations that multiple >>>>> tools are running when these tests are timing out. >>>>> 1000s of test runs have succeeded with this change in place. >>>>> >>>>> More investigation can be done to find the root cause >>>>> of these failures, but for now it's best to make the tests >>>>> run more reliably without timing out. >>>>> >>>>> Issues: >>>>> https://bugs.openjdk.java.net/browse/JDK-8220242 >>>>> https://bugs.openjdk.java.net/browse/JDK-8220295 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~gadams/8220295/webrev/ >>>> >>>> >>>> >>> >> >> From gary.adams at oracle.com Mon Mar 25 00:10:50 2019 From: gary.adams at oracle.com (Gary Adams) Date: Sun, 24 Mar 2019 20:10:50 -0400 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table In-Reply-To: <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> References: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> Message-ID: <5C981C8A.3060101@oracle.com> Here's an updated webrev that includes the change to bind to the stub. The jstatd tests continue to pass after this change. Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/ It would be good to have a second reviewer from the serviceability team. Longer term it would be good to replace the rmi dependency, which does not appear to be central to the functionality provided here. On 3/22/19, 9:56 AM, Roger Riggs wrote: > Hi Gary, > > Holding a static reference to the implementation solves the problem. > > But I noticed that the object that is bound in the registry is the > RemoteHostImpl > and it should be the RemoteHost stub. > > Line 145: should be: > > bind(name.toString(), stub); > > That is likely to solve the problem as well, because the distributed > garbage > collector will correctly cause a hard reference to be retained to the > implementation. > > Roger > > > On 03/22/2019 04:05 AM, gary.adams at oracle.com wrote: >> Here's a proposed fix for the intermittent jstatd test failure. >> By moving the exported object from a local method variable to a >> static class variable a strong reference is held so the object >> will not be garbage collected prematurely. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8203026 >> >> The test is currently filed as a core-libs/java.rmi, but it probably >> should be core-svc/tools with label=jstatd. It is the callers >> responsibility to ensure the strong reference to prevent >> the premature garbage collection, so this is a test failure >> rather than a need to change the underlying rmi behavior. > From sgehwolf at redhat.com Mon Mar 25 13:01:51 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Mar 2019 14:01:51 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: <9f743d16db44bc87ddb0a4aa275538ba3260fe9c.camel@redhat.com> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Is there ever a situation where the memory.limit_in_bytes could be unlimited but the > hierarchical_memory_limit is not? Yes. This is the very bug. Under a systemd slice with newer kernels the memory.limit_in_bytes file OpenJDK looks at has unlimited, but memory.stat on the same hierarchy has the correct setting. Patched JDK with -Xlog:os+container=trace [0.051s][trace][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.limit_in_bytes [0.051s][trace][os,container] Memory Limit is: 9223372036854771712 [0.051s][trace][os,container] Non-Hierarchical Memory Limit is: Unlimited [0.051s][trace][os,container] Path to /memory.stat is /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.stat [0.051s][trace][os,container] Hierarchical Memory Limit is: 10485760 $ cat /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.limit_in_bytes 9223372036854771712 $ cat /sys/fs/cgroup/memory/user.slice/user-cg.slice/memory.limit_in_bytes 10485760 $ grep hierarchical /sys/fs/cgroup/memory/user.slice/user-cg.slice/run-raf53fa46d5cc47ce857fbfaae04459c1.scope/memory.stat hierarchical_memory_limit 10485760 hierarchical_memsw_limit 9223372036854771712 This was mentioned in the bug comments as well. > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > by adding an additional argument? Sure, I could look into that. I'll post an updated webrev soon. Thanks for the review! Cheers, Severin > BTW: I found another problem with the mountinfo/cgroup parsing that impacts the > container tests. > > I don?t know why it only caused a failure on one of my systems. I?m going to > file another bug. You might want to test with these changes to make sure > your looking at the correct subsystem files. OK. Thanks for the heads-up. It looks unrelated, though. > > diff --git a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > --- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > +++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java > @@ -60,7 +60,7 @@ > path = mountPoint; > } > else { > - if (root.indexOf(cgroupPath) == 0) { > + if (cgroupPath.indexOf(root) == 0) { > if (cgroupPath.length() > root.length()) { > String cgroupSubstr = cgroupPath.substring(root.length()); > path = mountPoint + cgroupSubstr; > diff --git a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > --- a/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > +++ b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java > @@ -85,7 +85,7 @@ > String mountPoint = paths[1]; > if (root != null && cgroupPath != null) { > if (root.equals("/")) { > - if (cgroupPath.equals("/")) { > + if (!cgroupPath.equals("/")) { > finalPath = mountPoint + cgroupPath; > } else { > finalPath = mountPoint; > @@ -94,7 +94,7 @@ > if (root.equals(cgroupPath)) { > finalPath = mountPoint; > } else { > - if (root.indexOf(cgroupPath) == 0) { > + if (cgroupPath.indexOf(root) == 0) { > if (cgroupPath.length() > root.length()) { > String cgroupSubstr = cgroupPath.substring(root.length()); > finalPath = mountPoint + cgroupSubstr; > @@ -103,7 +103,7 @@ > } > } > } > - subSystemPaths.put(subSystem, new String[]{finalPath}); > + subSystemPaths.put(subSystem, new String[]{finalPath, mountPoint}); > } > } > } > > > Bob. > > > > > On Mar 22, 2019, at 6:43 AM, Severin Gehwolf wrote: > > > > Hi, > > > > Please review this change which improves container detection support > > tin the JVM. While docker container detection works quite well the > > results for systemd slices with memory limits are mixed and depend on > > the Linux kernel version in use. With newer kernel versions becoming > > more widely used we should improve JVMs memory limit detection support > > as well. This should be entirely backwards compatible as the > > hierarchical limit will only be used if everything else is unlimited. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217338 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/04/webrev/ > > > > Testing: Manual testing of -XshowSettings and -Xlog:os+container=trace > > with systemd slices on affected Linux distributions: Fedora 29, > > recent Ubuntu (18-10). Existing docker tests pass. I'm currently also > > running this through jdk/submit. > > > > Thoughts? > > > > Thanks, > > Severin > > From stefan.karlsson at oracle.com Mon Mar 25 13:44:14 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 25 Mar 2019 14:44:14 +0100 Subject: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java In-Reply-To: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> References: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> Message-ID: <86dfea50-0657-6133-8a45-50b704186393@oracle.com> Looks good. StefanK On 2019-03-25 10:59, Per Liden wrote: > Clean up serviceability/sa/TestUniverse.java to remove the need for the > withZ/withoutZ option we currently pass in. This also changes the test > to only run with the selected GC instead of testing all GCs every time, > which should save us some cycles in testing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221396 > Webrev: http://cr.openjdk.java.net/~pliden/8221396/webrev.0 > > /Per From per.liden at oracle.com Mon Mar 25 13:56:32 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 25 Mar 2019 14:56:32 +0100 Subject: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java In-Reply-To: <86dfea50-0657-6133-8a45-50b704186393@oracle.com> References: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> <86dfea50-0657-6133-8a45-50b704186393@oracle.com> Message-ID: <4513e27a-e38d-6055-0441-fb54c40a9c56@oracle.com> Thanks Stefan! /Per On 3/25/19 2:44 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2019-03-25 10:59, Per Liden wrote: >> Clean up serviceability/sa/TestUniverse.java to remove the need for >> the withZ/withoutZ option we currently pass in. This also changes the >> test to only run with the selected GC instead of testing all GCs every >> time, which should save us some cycles in testing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221396 >> Webrev: http://cr.openjdk.java.net/~pliden/8221396/webrev.0 >> >> /Per From jcbeyler at google.com Mon Mar 25 16:25:41 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 25 Mar 2019 09:25:41 -0700 Subject: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java In-Reply-To: <4513e27a-e38d-6055-0441-fb54c40a9c56@oracle.com> References: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> <86dfea50-0657-6133-8a45-50b704186393@oracle.com> <4513e27a-e38d-6055-0441-fb54c40a9c56@oracle.com> Message-ID: Hi Per, It looks good to me (not an official reviewer), my nit would be perhaps to add a print when you skip a configuration just for future debugging/understanding the log, perhaps?. No need evidently to make a new webrev for that :) Thanks, Jc On Mon, Mar 25, 2019 at 6:59 AM Per Liden wrote: > Thanks Stefan! > > /Per > > On 3/25/19 2:44 PM, Stefan Karlsson wrote: > > Looks good. > > > > StefanK > > > > On 2019-03-25 10:59, Per Liden wrote: > >> Clean up serviceability/sa/TestUniverse.java to remove the need for > >> the withZ/withoutZ option we currently pass in. This also changes the > >> test to only run with the selected GC instead of testing all GCs every > >> time, which should save us some cycles in testing. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221396 > >> Webrev: http://cr.openjdk.java.net/~pliden/8221396/webrev.0 > >> > >> /Per > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianglizhou at google.com Mon Mar 25 16:51:14 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 25 Mar 2019 09:51:14 -0700 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Message-ID: Hi Claes, The updated change also matches with the state of shared klasses, so it seems good to me. Sorry for the delay. It's probably a good idea to add an assert to make sure k->is_shared() in both places. No new webrev is necessary for me for the assert change. Thanks and regards, Jiangli On Mon, Mar 25, 2019 at 3:45 AM Claes Redestad wrote: > Ping. > > Still passes tests and is necessary to unblock work to more aggressively > archive invariant heap graphs. > > /Claes > > On 2019-03-15 17:26, Claes Redestad wrote: > > Hi, > > > > I ran into a few additional test issues, one exposing a crash in jmap > > -histo:live in a test that seems to have been problem listed when I > > ran tests earlier. > > > > Also filtering out archived-but-not-yet-loaded classes in > > KlassInfoBucket::lookup makes tests exercising jmap etc work as intended > > in the presence of archived classes: > > > > http://cr.openjdk.java.net/~redestad/8220682/open.01/ > > > > Testing: tier1-3 with 8214712 ongoing > > > > /Claes > > > > On 2019-03-15 16:28, Jiangli Zhou wrote: > >> +1 > >> > >> Thanks, > >> Jiangli > >> > >> On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler > >> > wrote: > >> > >> Hi Claes, > >> > >> Looks good to me. For those who would want to see the patch change > >> done in the serviceability-agent: > >> http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da > >> > >> Thanks, > >> Jc > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Mar 25 17:06:09 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Mar 2019 10:06:09 -0700 Subject: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" In-Reply-To: References: Message-ID: <70eb458b-46a0-3cd3-84cc-d126928a64a9@oracle.com> Looks Okat to me. Thanks, Serguei On 3/22/19 00:11, Nick Gasson wrote: > On 22/03/2019 00:17, Daniel D. Daugherty wrote: >> >> You can list both bug IDs in the same changeset like this: >> >> 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: >> thread2 is not alive" >> 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT >> while waiting for event" > > Thanks everyone for the reviews. I've updated the commit message to > match the above: > > http://hg.openjdk.java.net/jdk/jdk/rev/ed34367d4e9f > > Nick From serguei.spitsyn at oracle.com Mon Mar 25 17:21:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Mar 2019 10:21:30 -0700 Subject: RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table In-Reply-To: <5C981C8A.3060101@oracle.com> References: <788c067f-6fc3-0c9a-ffb1-c80d03bcfd99@oracle.com> <0a98388d-3fc8-04ce-5477-be6afca58e0a@oracle.com> <5C981C8A.3060101@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Mon Mar 25 17:30:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 25 Mar 2019 18:30:48 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> Message-ID: <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > by adding an additional argument? Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ Thanks, Severin From gary.adams at oracle.com Mon Mar 25 18:18:03 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 25 Mar 2019 14:18:03 -0400 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> Message-ID: <5C991B5B.2050203@oracle.com> During testing I found that there is still good reasons to leave 003 and 004 tests on the ProblemList. I believe there is still work to be done to ensure JDK-7013634 and JDK-6606767 are covered. This pass attempts to solve the primary issue in this bug which is improper paths on the test command lines. Cleanup is limited to the 003 and 004 tests. The tests will remain on the ProblemList. Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html On 3/8/19, 3:39 PM, Chris Plummer wrote: > Ok, I didn't realize the @ignore was removed also. I guess this is > what "exclude" was converted into. So the question now is should the > @ignore (and the exclude comment) remain. The @ignore bug > (JDK-7013634) was closed as CNR. I'm actually the one that closed it a > while back, and that may have been a mistake since I didn't realize > that some of the tests had been completely excluded from testing, even > quarantine testing. After reading through some of the comments in > JDK-7013634, I'm not trusting these tests to run reliably. That's > often the case with tests that try to exhaust resources. > > Chris > > On 3/8/19 9:41 AM, Gary Adams wrote: >> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>> You can remove the quarantine and exclude keywords. I think that's >>> appropriate if the test is off the problemlist and working. It was >>> just nonconcurrent removal that I was against. >> Done >>> >>> As for the resexhausted001 failure you are still seeing, how could >>> jtreg exclude it if it was not on the problemlist. I didn't think >>> there was any other mechanism. I don't believe jtreg looks at the >>> tonga keywords. >> >> I believe the @ignore is a jtreg keyword. >> With the -ignore command line flag jtreg can be directed to >> quietly ignore a test, or force an error, or attempt to run the test >> even though the @ignore directive is there. >> >>> >>> thanks, >>> >>> Chris >>> >>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>> I'll revert the comments that were left in during the tonga conversion. >>>> >>>> I did come across an interesting test failure in resexhausted001 >>>> which had an >>>> @ignore 7013634 >>>> >>>> JDK-7013634: jvmti resexhausted001 can timeout or fail due to >>>> excessive thread creation >>>> >>>> The test was closed because it was not reproducible. >>>> Even though the test was not on the ProblemList, I believe >>>> jtreg was excluding the test from running. >>>> >>>> The original problem reported an "out of swap" condition. >>>> >>>> The current failure reports: >>>> ----------System.out:(3/217)---------- >>>> Creating threads... >>>> Timeout refired 480 times >>>> [730.871s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>> >>>> >>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> Why did you remove the "nonconcurrent" keyword. I know these are >>>>> just comments for reference that were added when the test was >>>>> ported from tonga, but as a comment it is still applicable. The >>>>> test should not be run concurrent with others (which you have also >>>>> fixed with the addition of the "exclusiveAccess.dirs=."). >>>>> >>>>> Otherwise changes look good. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>> >>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>> path issues in finding the correct classes. This change searches the >>>>>> test.class.path for the appropriate vmTestbase classes rather >>>>>> than using >>>>>> incorrect settings on the command line. >>>>>> >>>>>> Some clean up has been done to remove quarantine keyword >>>>>> and @ignore directives. Should additional clean up be done to remove >>>>>> bug numbers, etc.? >>>>>> >>>>>> TEST.PROPERTIES were added so test 3 so it is consistent with the >>>>>> other tests >>>>>> in the group. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>> >>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>> Testing on mach5 for other platforms next. >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Mon Mar 25 19:16:41 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Mar 2019 20:16:41 +0100 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Message-ID: <5ae86007-4de1-e1b6-50db-21234de618bd@oracle.com> On 2019-03-25 17:51, Jiangli Zhou wrote: > Hi Claes, > > The updated change also matches with the state of shared klasses, so it > seems good to me. Thanks! > Sorry for the delay. No worries, I was on vacation last week. :-) > It's probably a good idea to add > an assert to make sure k->is_shared() in both places. No new webrev is > necessary for me for the assert change. Ok, will do and run some tests. Thanks! /Claes From chris.plummer at oracle.com Mon Mar 25 19:46:19 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 25 Mar 2019 12:46:19 -0700 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <5C991B5B.2050203@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> Message-ID: <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Mar 25 22:10:49 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Mar 2019 15:10:49 -0700 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> Message-ID: <2034e44f-b52f-6822-1acf-8006013a8ef1@oracle.com> Hi Claes, It looks good. I've targeted the bug to 13. Thanks, Serguei On 3/25/19 04:23, Claes Redestad wrote: > [Adding hotspot-runtime-dev] > > On 2019-03-15 17:26, Claes Redestad wrote: >> Hi, >> >> I ran into a few additional test issues, one exposing a crash in jmap >> -histo:live in a test that seems to have been problem listed when I >> ran tests earlier. >> >> Also filtering out archived-but-not-yet-loaded classes in >> KlassInfoBucket::lookup makes tests exercising jmap etc work as intended >> in the presence of archived classes: >> >> http://cr.openjdk.java.net/~redestad/8220682/open.01/ >> >> Testing: tier1-3 with 8214712 ongoing >> >> /Claes >> >> On 2019-03-15 16:28, Jiangli Zhou wrote: >>> +1 >>> >>> Thanks, >>> Jiangli >>> >>> On Fri, Mar 15, 2019 at 7:56 AM Jean Christophe Beyler >>> > wrote: >>> >>> ??? Hi Claes, >>> >>> ??? Looks good to me. For those who would want to see the patch change >>> ??? done in the serviceability-agent: >>> ??? http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da >>> >>> ??? Thanks, >>> ??? Jc >>> From claes.redestad at oracle.com Mon Mar 25 22:15:13 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Mar 2019 23:15:13 +0100 Subject: RFR: 8220682: Heap dumping and inspection fails with JDK-8214712 In-Reply-To: <2034e44f-b52f-6822-1acf-8006013a8ef1@oracle.com> References: <44c76461-49eb-c128-aabc-8caf7eb329a9@oracle.com> <2034e44f-b52f-6822-1acf-8006013a8ef1@oracle.com> Message-ID: On 2019-03-25 23:10, serguei.spitsyn at oracle.com wrote: > Hi Claes, > > It looks good. > I've targeted the bug to 13. Thanks, Serguei! /Claes From ioi.lam at oracle.com Tue Mar 26 00:37:57 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 25 Mar 2019 17:37:57 -0700 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: <2134a4ab-a731-2b71-4963-8f5f83c11a04@oracle.com> References: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> <2134a4ab-a731-2b71-4963-8f5f83c11a04@oracle.com> Message-ID: <9a99a0ae-41f6-61aa-b62e-49c458ba5728@oracle.com> Hi David, http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v02/ Thanks for the explanation. I've reverted my previous changes and instead modified how the hand-shake is done. There's no need to use VirtualMachine.list() as the pid is passed as part of the hand-shake. // Hand-shake protocol with the child process // [1] Parent process (this process) launches child process (InstrumentationApp) //???? and then waits until child process writes its pid into the flagFile. // [2] Child process process starts up, writes its pid into the flagFile, //???? and waits for the flagFile to be deleted. // [3] When parent process gets the pid, it attaches to the child process //???? (if we attempt to attach to a process too early, the SIGQUIT //???? may cause the child to die) and deletes the flagFile. // [4] Child process resumes execution. Thanks - Ioi On 3/24/19 10:28 PM, David Holmes wrote: > On 25/03/2019 3:06 pm, Ioi Lam wrote: >> >> >> On 3/24/19 9:14 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> On 25/03/2019 1:46 pm, Ioi Lam wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8217347 >>>> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ >>>> >>>> >>>> This test case used VirtualMachine.list() to find the pid of the >>>> the child >>>> process. However, as David Holmes commented in the bug report, it's >>>> suspected that this call may lead to timeout. >>>> >>>> In any case, since Process.pid() has been added since JDK 9, it's >>>> better to call this >>>> API directly. That way, we can avoid unnecessary dependency on >>>> VirtualMachine.list(). >>> >>> In so far as I can see how you replaced the VM.list() with >>> Process.pid() this seems okay. I'm having trouble actually >>> understanding the handshake being used to control things though. I >>> would have expected the target VM to create the flagfile to indicate >>> it is ready for attaching, then it would wait for the flagfile to be >>> deleted. >>> >> >> Hi David, >> >> As far as I can tell, the handshake is this: the main test process >> creates the flag file and passes the name of the flag file to the >> child process (whose main class is InstrumentationApp). The child >> process will wait until the main process deletes the flag file. >> >> After the child process is launched, the main process attaches to it >> (using the child's pid), and then deletes the flag file. At that >> point, the child will resume execution. > > Okay but the problem is that the main process can try to attach to the > child process before the child is ready to be attached to. This is a > day one limitation of the attach-on-demand process. If the child > process created the flags file (using the name supplied by the main > process) the main process could wait until it sees it to do the attach. > > Anyway this is not directly related to your fix, just be aware this > test can fail in obscure ways as the child process may silently > disappear if the SIGQUIT used to attach-on-demand arrives too soon. > >> >> BTW, I found this comment to be out-dated so I changed it: >> >> -??????? // At this point, the child process is not yet launched. >> Note that >> -??????? // TestCommon.exec() and OutputAnalyzer.OutputAnalyzer() >> both block >> -??????? // until the child process has finished. >> -??????? // >> -??????? // So, we will launch a AgentAttachThread which will poll >> the system >> -??????? // until the child process is launched, and then do the >> attachment. >> -??????? // The child process is uniquely identified by having >> flagFile in its >> -??????? // command-line -- see AgentAttachThread.getPid(). >> >> +??????? // At this point, the child process is not yet launched. >> +??????? // We will launch a AgentAttachThread which will wait until >> +??????? // the child process's pid is known, and then do the >> attachment. > > Okay but the comment is out of date because you now return the process > directly, which means you no longer need the AgentAttachThread at all, > you can do the attach logic directly from the main thread. > > Cheers, > David > ----- > >> ????????? AgentAttachThread t = new AgentAttachThread(flagFile, >> agentJar); >> ????????? t.start(); >> ????????? return t; >> >> Thanks >> - Ioi >> >>> Thanks, >>> David >>> >>>> Tested with tiers{1,2,3}. Also removed some unnecessary @module and >>>> import lines. >>>> >>>> Thanks >>>> - Ioi >> From serguei.spitsyn at oracle.com Tue Mar 26 02:21:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Mar 2019 19:21:51 -0700 Subject: RFR: 8146986: JDI: Signature lookups for unprepared classes can take a long time In-Reply-To: <5d435195-a2f2-3ebf-4ff9-7ae971384770@jetbrains.com> References: <77f28581-16fa-38ec-ed8d-fd37c8b6f1ce@jetbrains.com> <2b701c72-5380-b110-bf49-53f851051f08@oracle.com> <5d435195-a2f2-3ebf-4ff9-7ae971384770@jetbrains.com> Message-ID: An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Tue Mar 26 04:56:31 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 25 Mar 2019 21:56:31 -0700 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> Message-ID: <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> Gary Just want to add that following code 68 } catch (OutOfMemoryError me) { 69 me.printStackTrace(); 70 } might throw another OOME in printStackTrace(). If you want to do something after OOME it is needed to free some before trying to allocate. Leonid > On Mar 25, 2019, at 12:46 PM, Chris Plummer wrote: > > Hi Gary, > > In resexhausted004.java, the indentation needs to be fixed. Also, what happens if one of the caught exceptions is thrown? Does the test fail or pass? I'm not sure what the default behavior is if you just return from main(). > > Otherwise looks good. > > thanks, > > Chris > > On 3/25/19 11:18 AM, Gary Adams wrote: >> During testing I found that there is still good reasons to leave 003 and 004 >> tests on the ProblemList. I believe there is still work to be done to ensure >> JDK-7013634 and JDK-6606767 are covered. >> >> This pass attempts to solve the primary issue in this bug which is improper paths on the >> test command lines. Cleanup is limited to the 003 and 004 tests. The tests will >> remain on the ProblemList. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >> Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html >> >> On 3/8/19, 3:39 PM, Chris Plummer wrote: >>> >>> Ok, I didn't realize the @ignore was removed also. I guess this is what "exclude" was converted into. So the question now is should the @ignore (and the exclude comment) remain. The @ignore bug (JDK-7013634) was closed as CNR. I'm actually the one that closed it a while back, and that may have been a mistake since I didn't realize that some of the tests had been completely excluded from testing, even quarantine testing. After reading through some of the comments in JDK-7013634, I'm not trusting these tests to run reliably. That's often the case with tests that try to exhaust resources. >>> >>> Chris >>> >>> On 3/8/19 9:41 AM, Gary Adams wrote: >>>> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>>>> >>>>> You can remove the quarantine and exclude keywords. I think that's appropriate if the test is off the problemlist and working. It was just nonconcurrent removal that I was against. >>>> Done >>>>> >>>>> As for the resexhausted001 failure you are still seeing, how could jtreg exclude it if it was not on the problemlist. I didn't think there was any other mechanism. I don't believe jtreg looks at the tonga keywords. >>>> >>>> I believe the @ignore is a jtreg keyword. >>>> With the -ignore command line flag jtreg can be directed to >>>> quietly ignore a test, or force an error, or attempt to run the test >>>> even though the @ignore directive is there. >>>> >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>>>> I'll revert the comments that were left in during the tonga conversion. >>>>>> >>>>>> I did come across an interesting test failure in resexhausted001 >>>>>> which had an >>>>>> @ignore 7013634 >>>>>> >>>>>> JDK-7013634: jvmti resexhausted001 can timeout or fail due to excessive thread creation >>>>>> >>>>>> The test was closed because it was not reproducible. >>>>>> Even though the test was not on the ProblemList, I believe >>>>>> jtreg was excluding the test from running. >>>>>> >>>>>> The original problem reported an "out of swap" condition. >>>>>> >>>>>> The current failure reports: >>>>>> ----------System.out:(3/217)---------- >>>>>> Creating threads... >>>>>> Timeout refired 480 times >>>>>> [730.871s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>>>> >>>>>> >>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>>>> >>>>>>> Hi Gary, >>>>>>> >>>>>>> Why did you remove the "nonconcurrent" keyword. I know these are just comments for reference that were added when the test was ported from tonga, but as a comment it is still applicable. The test should not be run concurrent with others (which you have also fixed with the addition of the "exclusiveAccess.dirs=."). >>>>>>> >>>>>>> Otherwise changes look good. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>>>> >>>>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>>>> path issues in finding the correct classes. This change searches the >>>>>>>> test.class.path for the appropriate vmTestbase classes rather than using >>>>>>>> incorrect settings on the command line. >>>>>>>> >>>>>>>> Some clean up has been done to remove quarantine keyword >>>>>>>> and @ignore directives. Should additional clean up be done to remove >>>>>>>> bug numbers, etc.? >>>>>>>> >>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent with the other tests >>>>>>>> in the group. >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>>>> >>>>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>>>> Testing on mach5 for other platforms next. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Mar 26 05:05:06 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 25 Mar 2019 22:05:06 -0700 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Mar 26 05:11:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 15:11:48 +1000 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> Message-ID: On 26/03/2019 3:05 pm, Chris Plummer wrote: > printStackTrace shouldn't ever result in an OOME since the memory held > that caused the previous OOME should be released before another OOME is > generated (no longer any references to it). It will depend on the code executed leading up to and after the OOME that will determine if memory has been released by the time the OOME reaches the top-level. David > Chris > > On 3/25/19 9:56 PM, Leonid Mesnik wrote: >> Gary >> >> Just want to add that following code >> 68 } catch (OutOfMemoryError me) { >> 69 me.printStackTrace(); >> 70 } >> might throw another OOME in printStackTrace(). >> >> If you want to do something after OOME it is needed to free some >> before trying to allocate. >> >> Leonid >> >>> On Mar 25, 2019, at 12:46 PM, Chris Plummer >> > wrote: >>> >>> Hi Gary, >>> >>> In resexhausted004.java, the indentation needs to be fixed. Also, >>> what happens if one of the caught exceptions is thrown? Does the test >>> fail or pass? I'm not sure what the default behavior is if you just >>> return from main(). >>> >>> Otherwise looks good. >>> >>> thanks, >>> >>> Chris >>> >>> On 3/25/19 11:18 AM, Gary Adams wrote: >>>> During testing I found that there is still good reasons to leave 003 >>>> and 004 >>>> tests on the ProblemList. I believe there is still work to be done >>>> to ensure >>>> JDK-7013634 and JDK-6606767 are covered. >>>> >>>> This pass attempts to solve the primary issue in this bug which is >>>> improper paths on the >>>> test command lines. Cleanup is limited to the 003 and 004 tests. The >>>> tests will >>>> remain on the ProblemList. >>>> >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>> ? Webrev: >>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html >>>> >>>> On 3/8/19, 3:39 PM, Chris Plummer wrote: >>>>> Ok, I didn't realize the @ignore was removed also. I guess this is >>>>> what "exclude" was converted into. So the question now is should >>>>> the @ignore (and the exclude comment) remain. The @ignore bug >>>>> (JDK-7013634) was closed as CNR. I'm actually the one that closed >>>>> it a while back, and that may have been a mistake since I didn't >>>>> realize that some of the tests had been completely excluded from >>>>> testing, even quarantine testing. After reading through some of the >>>>> comments in JDK-7013634, I'm not trusting these tests to run >>>>> reliably. That's often the case with tests that try to exhaust >>>>> resources. >>>>> >>>>> Chris >>>>> >>>>> On 3/8/19 9:41 AM, Gary Adams wrote: >>>>>> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>>>>>> You can remove the quarantine and exclude keywords. I think >>>>>>> that's appropriate if the test is off the problemlist and >>>>>>> working. It was just nonconcurrent removal that I was against. >>>>>> Done >>>>>>> >>>>>>> As for the resexhausted001 failure you are still seeing, how >>>>>>> could jtreg exclude it if it was not on the problemlist. I didn't >>>>>>> think there was any other mechanism. I don't believe jtreg looks >>>>>>> at the tonga keywords. >>>>>> >>>>>> I believe the @ignore is a jtreg keyword. >>>>>> With the -ignore command line flag jtreg can be directed to >>>>>> quietly ignore a test, or force an error, or attempt to run the test >>>>>> even though the @ignore directive is there. >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>>>>>> I'll revert the comments that were left in during the tonga >>>>>>>> conversion. >>>>>>>> >>>>>>>> I did come across an interesting test failure in resexhausted001 >>>>>>>> which had an >>>>>>>> ? @ignore 7013634 >>>>>>>> >>>>>>>> ??? JDK-7013634: jvmti resexhausted001 can timeout or fail due >>>>>>>> to excessive thread creation >>>>>>>> >>>>>>>> The test was closed because it was not reproducible. >>>>>>>> Even though the test was not on the ProblemList, I believe >>>>>>>> jtreg was excluding the test from running. >>>>>>>> >>>>>>>> The original problem reported an "out of swap" condition. >>>>>>>> >>>>>>>> The current failure reports: >>>>>>>> ----------System.out:(3/217)---------- >>>>>>>> Creating threads... >>>>>>>> Timeout refired 480 times >>>>>>>> [730.871s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>>>>>> >>>>>>>> >>>>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> Why did you remove the "nonconcurrent" keyword. I know these >>>>>>>>> are just comments for reference that were added when the test >>>>>>>>> was ported from tonga, but as a comment it is still applicable. >>>>>>>>> The test should not be run concurrent with others (which you >>>>>>>>> have also fixed with the addition of the >>>>>>>>> "exclusiveAccess.dirs=."). >>>>>>>>> >>>>>>>>> Otherwise changes look good. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>>>>>> >>>>>>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>>>>>> path issues in finding the correct classes. This change >>>>>>>>>> searches the >>>>>>>>>> test.class.path for the appropriate vmTestbase classes rather >>>>>>>>>> than using >>>>>>>>>> incorrect settings on the command line. >>>>>>>>>> >>>>>>>>>> Some clean up has been done to remove quarantine keyword >>>>>>>>>> and @ignore directives. Should additional clean up be done to >>>>>>>>>> remove >>>>>>>>>> bug numbers, etc.? >>>>>>>>>> >>>>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent with >>>>>>>>>> the other tests >>>>>>>>>> in the group. >>>>>>>>>> >>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>>>>> ? Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>>>>>> >>>>>>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>>>>>> Testing on mach5 for other platforms next. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Tue Mar 26 05:34:25 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 25 Mar 2019 22:34:25 -0700 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> Message-ID: <76315ed0-a8ba-1ee4-b23c-1bc93411a726@oracle.com> On 3/25/19 10:11 PM, David Holmes wrote: > On 26/03/2019 3:05 pm, Chris Plummer wrote: >> printStackTrace shouldn't ever result in an OOME since the memory >> held that caused the previous OOME should be released before another >> OOME is generated (no longer any references to it). > > It will depend on the code executed leading up to and after the OOME > that will determine if memory has been released by the time the OOME > reaches the top-level. Well, my assumption is that there is no class static holding on to the memory. If there isn't and printStackTrace needs to allocate an object, then a gc will be done if necessary. If there is static, I'd call that a test bug. A test shouldn't fill the heap, generate and catch an OOME, and then expect the test to be able to exit gracefully unless it first releases the memory. Chris > > David > >> Chris >> >> On 3/25/19 9:56 PM, Leonid Mesnik wrote: >>> Gary >>> >>> Just want to add that following code >>> 68 } catch (OutOfMemoryError me) { >>> 69 me.printStackTrace(); >>> 70 } >>> might throw another OOME in printStackTrace(). >>> >>> If you want to do something after OOME it is needed to free some >>> before trying to allocate. >>> >>> Leonid >>> >>>> On Mar 25, 2019, at 12:46 PM, Chris Plummer >>>> > wrote: >>>> >>>> Hi Gary, >>>> >>>> In resexhausted004.java, the indentation needs to be fixed. Also, >>>> what happens if one of the caught exceptions is thrown? Does the >>>> test fail or pass? I'm not sure what the default behavior is if you >>>> just return from main(). >>>> >>>> Otherwise looks good. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 3/25/19 11:18 AM, Gary Adams wrote: >>>>> During testing I found that there is still good reasons to leave >>>>> 003 and 004 >>>>> tests on the ProblemList. I believe there is still work to be done >>>>> to ensure >>>>> JDK-7013634 and JDK-6606767 are covered. >>>>> >>>>> This pass attempts to solve the primary issue in this bug which is >>>>> improper paths on the >>>>> test command lines. Cleanup is limited to the 003 and 004 tests. >>>>> The tests will >>>>> remain on the ProblemList. >>>>> >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>> ? Webrev: >>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html >>>>> >>>>> On 3/8/19, 3:39 PM, Chris Plummer wrote: >>>>>> Ok, I didn't realize the @ignore was removed also. I guess this >>>>>> is what "exclude" was converted into. So the question now is >>>>>> should the @ignore (and the exclude comment) remain. The @ignore >>>>>> bug (JDK-7013634) was closed as CNR. I'm actually the one that >>>>>> closed it a while back, and that may have been a mistake since I >>>>>> didn't realize that some of the tests had been completely >>>>>> excluded from testing, even quarantine testing. After reading >>>>>> through some of the comments in JDK-7013634, I'm not trusting >>>>>> these tests to run reliably. That's often the case with tests >>>>>> that try to exhaust resources. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 3/8/19 9:41 AM, Gary Adams wrote: >>>>>>> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>>>>>>> You can remove the quarantine and exclude keywords. I think >>>>>>>> that's appropriate if the test is off the problemlist and >>>>>>>> working. It was just nonconcurrent removal that I was against. >>>>>>> Done >>>>>>>> >>>>>>>> As for the resexhausted001 failure you are still seeing, how >>>>>>>> could jtreg exclude it if it was not on the problemlist. I >>>>>>>> didn't think there was any other mechanism. I don't believe >>>>>>>> jtreg looks at the tonga keywords. >>>>>>> >>>>>>> I believe the @ignore is a jtreg keyword. >>>>>>> With the -ignore command line flag jtreg can be directed to >>>>>>> quietly ignore a test, or force an error, or attempt to run the >>>>>>> test >>>>>>> even though the @ignore directive is there. >>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>>>>>>> I'll revert the comments that were left in during the tonga >>>>>>>>> conversion. >>>>>>>>> >>>>>>>>> I did come across an interesting test failure in resexhausted001 >>>>>>>>> which had an >>>>>>>>> ? @ignore 7013634 >>>>>>>>> >>>>>>>>> ??? JDK-7013634: jvmti resexhausted001 can timeout or fail due >>>>>>>>> to excessive thread creation >>>>>>>>> >>>>>>>>> The test was closed because it was not reproducible. >>>>>>>>> Even though the test was not on the ProblemList, I believe >>>>>>>>> jtreg was excluding the test from running. >>>>>>>>> >>>>>>>>> The original problem reported an "out of swap" condition. >>>>>>>>> >>>>>>>>> The current failure reports: >>>>>>>>> ----------System.out:(3/217)---------- >>>>>>>>> Creating threads... >>>>>>>>> Timeout refired 480 times >>>>>>>>> [730.871s][warning][os,thread] Failed to start thread - >>>>>>>>> _beginthreadex failed (EACCES) for attributes: stacksize: >>>>>>>>> default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>>>>>>> Hi Gary, >>>>>>>>>> >>>>>>>>>> Why did you remove the "nonconcurrent" keyword. I know these >>>>>>>>>> are just comments for reference that were added when the test >>>>>>>>>> was ported from tonga, but as a comment it is still >>>>>>>>>> applicable. The test should not be run concurrent with others >>>>>>>>>> (which you have also fixed with the addition of the >>>>>>>>>> "exclusiveAccess.dirs=."). >>>>>>>>>> >>>>>>>>>> Otherwise changes look good. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>>>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>>>>>>> >>>>>>>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>>>>>>> path issues in finding the correct classes. This change >>>>>>>>>>> searches the >>>>>>>>>>> test.class.path for the appropriate vmTestbase classes >>>>>>>>>>> rather than using >>>>>>>>>>> incorrect settings on the command line. >>>>>>>>>>> >>>>>>>>>>> Some clean up has been done to remove quarantine keyword >>>>>>>>>>> and @ignore directives. Should additional clean up be done >>>>>>>>>>> to remove >>>>>>>>>>> bug numbers, etc.? >>>>>>>>>>> >>>>>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent >>>>>>>>>>> with the other tests >>>>>>>>>>> in the group. >>>>>>>>>>> >>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>>>>>> ? Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>>>>>>> >>>>>>>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>>>>>>> Testing on mach5 for other platforms next. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Mar 26 05:56:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 15:56:47 +1000 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <76315ed0-a8ba-1ee4-b23c-1bc93411a726@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> <76315ed0-a8ba-1ee4-b23c-1bc93411a726@oracle.com> Message-ID: <772318db-c674-0058-5f8b-95284af69934@oracle.com> On 26/03/2019 3:34 pm, Chris Plummer wrote: > On 3/25/19 10:11 PM, David Holmes wrote: >> On 26/03/2019 3:05 pm, Chris Plummer wrote: >>> printStackTrace shouldn't ever result in an OOME since the memory >>> held that caused the previous OOME should be released before another >>> OOME is generated (no longer any references to it). >> >> It will depend on the code executed leading up to and after the OOME >> that will determine if memory has been released by the time the OOME >> reaches the top-level. > Well, my assumption is that there is no class static holding on to the > memory. If there isn't and printStackTrace needs to allocate an object, > then a gc will be done if necessary. If there is static, I'd call that a > test bug. A test shouldn't fill the heap, generate and catch an OOME, > and then expect the test to be able to exit gracefully unless it first > releases the memory. I think that was Leonid's point too. It's not obvious from resexhausted004.java that that is the case. That aside the change to resexhausted004.java seems unnecessary. These tests report success or failure by calling System.exit() with an appropriate return code. By catching the exceptions the VM will appear to exit with a zero code, which should still be seen as a failure in this case. If the exceptions are left to propagate out you'll get a non-zero return code which should still be a failure, and the stacktrace printing will be handled in the normal way if main returns via throwing an exception. David > Chris >> >> David >> >>> Chris >>> >>> On 3/25/19 9:56 PM, Leonid Mesnik wrote: >>>> Gary >>>> >>>> Just want to add that following code >>>> 68 } catch (OutOfMemoryError me) { >>>> 69 me.printStackTrace(); >>>> 70 } >>>> might throw another OOME in printStackTrace(). >>>> >>>> If you want to do something after OOME it is needed to free some >>>> before trying to allocate. >>>> >>>> Leonid >>>> >>>>> On Mar 25, 2019, at 12:46 PM, Chris Plummer >>>>> > wrote: >>>>> >>>>> Hi Gary, >>>>> >>>>> In resexhausted004.java, the indentation needs to be fixed. Also, >>>>> what happens if one of the caught exceptions is thrown? Does the >>>>> test fail or pass? I'm not sure what the default behavior is if you >>>>> just return from main(). >>>>> >>>>> Otherwise looks good. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 3/25/19 11:18 AM, Gary Adams wrote: >>>>>> During testing I found that there is still good reasons to leave >>>>>> 003 and 004 >>>>>> tests on the ProblemList. I believe there is still work to be done >>>>>> to ensure >>>>>> JDK-7013634 and JDK-6606767 are covered. >>>>>> >>>>>> This pass attempts to solve the primary issue in this bug which is >>>>>> improper paths on the >>>>>> test command lines. Cleanup is limited to the 003 and 004 tests. >>>>>> The tests will >>>>>> remain on the ProblemList. >>>>>> >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>> ? Webrev: >>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html >>>>>> >>>>>> On 3/8/19, 3:39 PM, Chris Plummer wrote: >>>>>>> Ok, I didn't realize the @ignore was removed also. I guess this >>>>>>> is what "exclude" was converted into. So the question now is >>>>>>> should the @ignore (and the exclude comment) remain. The @ignore >>>>>>> bug (JDK-7013634) was closed as CNR. I'm actually the one that >>>>>>> closed it a while back, and that may have been a mistake since I >>>>>>> didn't realize that some of the tests had been completely >>>>>>> excluded from testing, even quarantine testing. After reading >>>>>>> through some of the comments in JDK-7013634, I'm not trusting >>>>>>> these tests to run reliably. That's often the case with tests >>>>>>> that try to exhaust resources. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 3/8/19 9:41 AM, Gary Adams wrote: >>>>>>>> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>>>>>>>> You can remove the quarantine and exclude keywords. I think >>>>>>>>> that's appropriate if the test is off the problemlist and >>>>>>>>> working. It was just nonconcurrent removal that I was against. >>>>>>>> Done >>>>>>>>> >>>>>>>>> As for the resexhausted001 failure you are still seeing, how >>>>>>>>> could jtreg exclude it if it was not on the problemlist. I >>>>>>>>> didn't think there was any other mechanism. I don't believe >>>>>>>>> jtreg looks at the tonga keywords. >>>>>>>> >>>>>>>> I believe the @ignore is a jtreg keyword. >>>>>>>> With the -ignore command line flag jtreg can be directed to >>>>>>>> quietly ignore a test, or force an error, or attempt to run the >>>>>>>> test >>>>>>>> even though the @ignore directive is there. >>>>>>>> >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>>>>>>>> I'll revert the comments that were left in during the tonga >>>>>>>>>> conversion. >>>>>>>>>> >>>>>>>>>> I did come across an interesting test failure in resexhausted001 >>>>>>>>>> which had an >>>>>>>>>> ? @ignore 7013634 >>>>>>>>>> >>>>>>>>>> ??? JDK-7013634: jvmti resexhausted001 can timeout or fail due >>>>>>>>>> to excessive thread creation >>>>>>>>>> >>>>>>>>>> The test was closed because it was not reproducible. >>>>>>>>>> Even though the test was not on the ProblemList, I believe >>>>>>>>>> jtreg was excluding the test from running. >>>>>>>>>> >>>>>>>>>> The original problem reported an "out of swap" condition. >>>>>>>>>> >>>>>>>>>> The current failure reports: >>>>>>>>>> ----------System.out:(3/217)---------- >>>>>>>>>> Creating threads... >>>>>>>>>> Timeout refired 480 times >>>>>>>>>> [730.871s][warning][os,thread] Failed to start thread - >>>>>>>>>> _beginthreadex failed (EACCES) for attributes: stacksize: >>>>>>>>>> default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>>>>>>>> Hi Gary, >>>>>>>>>>> >>>>>>>>>>> Why did you remove the "nonconcurrent" keyword. I know these >>>>>>>>>>> are just comments for reference that were added when the test >>>>>>>>>>> was ported from tonga, but as a comment it is still >>>>>>>>>>> applicable. The test should not be run concurrent with others >>>>>>>>>>> (which you have also fixed with the addition of the >>>>>>>>>>> "exclusiveAccess.dirs=."). >>>>>>>>>>> >>>>>>>>>>> Otherwise changes look good. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>>>>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>>>>>>>> >>>>>>>>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>>>>>>>> path issues in finding the correct classes. This change >>>>>>>>>>>> searches the >>>>>>>>>>>> test.class.path for the appropriate vmTestbase classes >>>>>>>>>>>> rather than using >>>>>>>>>>>> incorrect settings on the command line. >>>>>>>>>>>> >>>>>>>>>>>> Some clean up has been done to remove quarantine keyword >>>>>>>>>>>> and @ignore directives. Should additional clean up be done >>>>>>>>>>>> to remove >>>>>>>>>>>> bug numbers, etc.? >>>>>>>>>>>> >>>>>>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent >>>>>>>>>>>> with the other tests >>>>>>>>>>>> in the group. >>>>>>>>>>>> >>>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>>>>>>> ? Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>>>>>>>> >>>>>>>>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>>>>>>>> Testing on mach5 for other platforms next. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > > From david.holmes at oracle.com Tue Mar 26 07:13:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2019 17:13:13 +1000 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: <9a99a0ae-41f6-61aa-b62e-49c458ba5728@oracle.com> References: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> <2134a4ab-a731-2b71-4963-8f5f83c11a04@oracle.com> <9a99a0ae-41f6-61aa-b62e-49c458ba5728@oracle.com> Message-ID: <094bab3c-5289-e5ce-393b-3255fbdd80e0@oracle.com> Hi Ioi, On 26/03/2019 10:37 am, Ioi Lam wrote: > Hi David, > > http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v02/ > > > Thanks for the explanation. I've reverted my previous changes and > instead modified how the hand-shake is done. There's no need to use > VirtualMachine.list() as the pid is passed as part of the hand-shake. > > // Hand-shake protocol with the child process > // [1] Parent process (this process) launches child process > (InstrumentationApp) > //???? and then waits until child process writes its pid into the flagFile. > // [2] Child process process starts up, writes its pid into the flagFile, > //???? and waits for the flagFile to be deleted. > // [3] When parent process gets the pid, it attaches to the child process > //???? (if we attempt to attach to a process too early, the SIGQUIT > //???? may cause the child to die) and deletes the flagFile. > // [4] Child process resumes execution. Okay that all seems fine. The test could be simplified further I think but that's a different story. Thanks, David > Thanks > - Ioi > > > On 3/24/19 10:28 PM, David Holmes wrote: >> On 25/03/2019 3:06 pm, Ioi Lam wrote: >>> >>> >>> On 3/24/19 9:14 PM, David Holmes wrote: >>>> Hi Ioi, >>>> >>>> On 25/03/2019 1:46 pm, Ioi Lam wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8217347 >>>>> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ >>>>> >>>>> >>>>> This test case used VirtualMachine.list() to find the pid of the >>>>> the child >>>>> process. However, as David Holmes commented in the bug report, it's >>>>> suspected that this call may lead to timeout. >>>>> >>>>> In any case, since Process.pid() has been added since JDK 9, it's >>>>> better to call this >>>>> API directly. That way, we can avoid unnecessary dependency on >>>>> VirtualMachine.list(). >>>> >>>> In so far as I can see how you replaced the VM.list() with >>>> Process.pid() this seems okay. I'm having trouble actually >>>> understanding the handshake being used to control things though. I >>>> would have expected the target VM to create the flagfile to indicate >>>> it is ready for attaching, then it would wait for the flagfile to be >>>> deleted. >>>> >>> >>> Hi David, >>> >>> As far as I can tell, the handshake is this: the main test process >>> creates the flag file and passes the name of the flag file to the >>> child process (whose main class is InstrumentationApp). The child >>> process will wait until the main process deletes the flag file. >>> >>> After the child process is launched, the main process attaches to it >>> (using the child's pid), and then deletes the flag file. At that >>> point, the child will resume execution. >> >> Okay but the problem is that the main process can try to attach to the >> child process before the child is ready to be attached to. This is a >> day one limitation of the attach-on-demand process. If the child >> process created the flags file (using the name supplied by the main >> process) the main process could wait until it sees it to do the attach. >> >> Anyway this is not directly related to your fix, just be aware this >> test can fail in obscure ways as the child process may silently >> disappear if the SIGQUIT used to attach-on-demand arrives too soon. >> >>> >>> BTW, I found this comment to be out-dated so I changed it: >>> >>> -??????? // At this point, the child process is not yet launched. >>> Note that >>> -??????? // TestCommon.exec() and OutputAnalyzer.OutputAnalyzer() >>> both block >>> -??????? // until the child process has finished. >>> -??????? // >>> -??????? // So, we will launch a AgentAttachThread which will poll >>> the system >>> -??????? // until the child process is launched, and then do the >>> attachment. >>> -??????? // The child process is uniquely identified by having >>> flagFile in its >>> -??????? // command-line -- see AgentAttachThread.getPid(). >>> >>> +??????? // At this point, the child process is not yet launched. >>> +??????? // We will launch a AgentAttachThread which will wait until >>> +??????? // the child process's pid is known, and then do the >>> attachment. >> >> Okay but the comment is out of date because you now return the process >> directly, which means you no longer need the AgentAttachThread at all, >> you can do the attach logic directly from the main thread. >> >> Cheers, >> David >> ----- >> >>> ????????? AgentAttachThread t = new AgentAttachThread(flagFile, >>> agentJar); >>> ????????? t.start(); >>> ????????? return t; >>> >>> Thanks >>> - Ioi >>> >>>> Thanks, >>>> David >>>> >>>>> Tested with tiers{1,2,3}. Also removed some unnecessary @module and >>>>> import lines. >>>>> >>>>> Thanks >>>>> - Ioi >>> > From per.liden at oracle.com Tue Mar 26 07:27:20 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 26 Mar 2019 08:27:20 +0100 Subject: RFR: 8221396: Clean up serviceability/sa/TestUniverse.java In-Reply-To: References: <3dfc7e1b-4bc4-88de-e14f-6144e0ce2b7f@oracle.com> <86dfea50-0657-6133-8a45-50b704186393@oracle.com> <4513e27a-e38d-6055-0441-fb54c40a9c56@oracle.com> Message-ID: <7b7efe90-11b8-f937-e735-9c56faff3f9b@oracle.com> Hi Jc, On 3/25/19 5:25 PM, Jean Christophe Beyler wrote: > Hi Per, > > It looks good to me (not an official reviewer), my nit would be perhaps > to add a print when you skip a configuration just for future > debugging/understanding the log, perhaps?. Thanks for reviewing. I will add a println when we skip an unsupported configuration. cheers, Per > > No need evidently to make a new webrev for that :) > > Thanks, > Jc > > On Mon, Mar 25, 2019 at 6:59 AM Per Liden > wrote: > > Thanks Stefan! > > /Per > > On 3/25/19 2:44 PM, Stefan Karlsson wrote: > > Looks good. > > > > StefanK > > > > On 2019-03-25 10:59, Per Liden wrote: > >> Clean up serviceability/sa/TestUniverse.java to remove the need for > >> the withZ/withoutZ option we currently pass in. This also > changes the > >> test to only run with the selected GC instead of testing all GCs > every > >> time, which should save us some cycles in testing. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221396 > >> Webrev: http://cr.openjdk.java.net/~pliden/8221396/webrev.0 > >> > >> /Per > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Tue Mar 26 09:41:14 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 26 Mar 2019 05:41:14 -0400 Subject: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes In-Reply-To: <772318db-c674-0058-5f8b-95284af69934@oracle.com> References: <5C8169B4.5080305@oracle.com> <5C8268FF.8050007@oracle.com> <5C82A944.9020506@oracle.com> <98af6aca-c131-ecf9-2a94-ac0b13ef6d80@oracle.com> <5C991B5B.2050203@oracle.com> <1ef97b11-a88a-f588-dd6c-ead384131980@oracle.com> <930E4BB3-1D5A-4592-A278-07030DF86BD6@oracle.com> <76315ed0-a8ba-1ee4-b23c-1bc93411a726@oracle.com> <772318db-c674-0058-5f8b-95284af69934@oracle.com> Message-ID: <5bdae6ca-a4eb-2ab2-b197-31511fd64245@oracle.com> The stab at catching the OOME was added to try an diagnose some of the remaininf failures. The tests will remain on the ProblemList. Probably best to remove the extra debugging and start fresh when the other issues are investigated. On 3/26/19 1:56 AM, David Holmes wrote: > On 26/03/2019 3:34 pm, Chris Plummer wrote: >> On 3/25/19 10:11 PM, David Holmes wrote: >>> On 26/03/2019 3:05 pm, Chris Plummer wrote: >>>> printStackTrace shouldn't ever result in an OOME since the memory >>>> held that caused the previous OOME should be released before >>>> another OOME is generated (no longer any references to it). >>> >>> It will depend on the code executed leading up to and after the OOME >>> that will determine if memory has been released by the time the OOME >>> reaches the top-level. >> Well, my assumption is that there is no class static holding on to >> the memory. If there isn't and printStackTrace needs to allocate an >> object, then a gc will be done if necessary. If there is static, I'd >> call that a test bug. A test shouldn't fill the heap, generate and >> catch an OOME, and then expect the test to be able to exit gracefully >> unless it first releases the memory. > > I think that was Leonid's point too. It's not obvious from > resexhausted004.java that that is the case. > > That aside the change to resexhausted004.java seems unnecessary. These > tests report success or failure by calling System.exit() with an > appropriate return code. By catching the exceptions the VM will appear > to exit with a zero code, which should still be seen as a failure in > this case. If the exceptions are left to propagate out you'll get a > non-zero return code which should still be a failure, and the > stacktrace printing will be handled in the normal way if main returns > via throwing an exception. > > David > >> Chris >>> >>> David >>> >>>> Chris >>>> >>>> On 3/25/19 9:56 PM, Leonid Mesnik wrote: >>>>> Gary >>>>> >>>>> Just want to add that following code >>>>> 68 } catch (OutOfMemoryError me) { >>>>> 69 me.printStackTrace(); >>>>> 70 } >>>>> might throw another OOME in printStackTrace(). >>>>> >>>>> If you want to do something after OOME it is needed to free some >>>>> before trying to allocate. >>>>> >>>>> Leonid >>>>> >>>>>> On Mar 25, 2019, at 12:46 PM, Chris Plummer >>>>>> > wrote: >>>>>> >>>>>> Hi Gary, >>>>>> >>>>>> In resexhausted004.java, the indentation needs to be fixed. Also, >>>>>> what happens if one of the caught exceptions is thrown? Does the >>>>>> test fail or pass? I'm not sure what the default behavior is if >>>>>> you just return from main(). >>>>>> >>>>>> Otherwise looks good. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 3/25/19 11:18 AM, Gary Adams wrote: >>>>>>> During testing I found that there is still good reasons to leave >>>>>>> 003 and 004 >>>>>>> tests on the ProblemList. I believe there is still work to be >>>>>>> done to ensure >>>>>>> JDK-7013634 and JDK-6606767 are covered. >>>>>>> >>>>>>> This pass attempts to solve the primary issue in this bug which >>>>>>> is improper paths on the >>>>>>> test command lines. Cleanup is limited to the 003 and 004 tests. >>>>>>> The tests will >>>>>>> remain on the ProblemList. >>>>>>> >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>> ? Webrev: >>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.01/index.html >>>>>>> >>>>>>> On 3/8/19, 3:39 PM, Chris Plummer wrote: >>>>>>>> Ok, I didn't realize the @ignore was removed also. I guess this >>>>>>>> is what "exclude" was converted into. So the question now is >>>>>>>> should the @ignore (and the exclude comment) remain. The >>>>>>>> @ignore bug (JDK-7013634) was closed as CNR. I'm actually the >>>>>>>> one that closed it a while back, and that may have been a >>>>>>>> mistake since I didn't realize that some of the tests had been >>>>>>>> completely excluded from testing, even quarantine testing. >>>>>>>> After reading through some of the comments in JDK-7013634, I'm >>>>>>>> not trusting these tests to run reliably. That's often the case >>>>>>>> with tests that try to exhaust resources. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 3/8/19 9:41 AM, Gary Adams wrote: >>>>>>>>> On 3/8/19, 12:10 PM, Chris Plummer wrote: >>>>>>>>>> You can remove the quarantine and exclude keywords. I think >>>>>>>>>> that's appropriate if the test is off the problemlist and >>>>>>>>>> working. It was just nonconcurrent removal that I was against. >>>>>>>>> Done >>>>>>>>>> >>>>>>>>>> As for the resexhausted001 failure you are still seeing, how >>>>>>>>>> could jtreg exclude it if it was not on the problemlist. I >>>>>>>>>> didn't think there was any other mechanism. I don't believe >>>>>>>>>> jtreg looks at the tonga keywords. >>>>>>>>> >>>>>>>>> I believe the @ignore is a jtreg keyword. >>>>>>>>> With the -ignore command line flag jtreg can be directed to >>>>>>>>> quietly ignore a test, or force an error, or attempt to run >>>>>>>>> the test >>>>>>>>> even though the @ignore directive is there. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 3/8/19 5:07 AM, Gary Adams wrote: >>>>>>>>>>> I'll revert the comments that were left in during the tonga >>>>>>>>>>> conversion. >>>>>>>>>>> >>>>>>>>>>> I did come across an interesting test failure in >>>>>>>>>>> resexhausted001 >>>>>>>>>>> which had an >>>>>>>>>>> ? @ignore 7013634 >>>>>>>>>>> >>>>>>>>>>> ??? JDK-7013634: jvmti resexhausted001 can timeout or fail >>>>>>>>>>> due to excessive thread creation >>>>>>>>>>> >>>>>>>>>>> The test was closed because it was not reproducible. >>>>>>>>>>> Even though the test was not on the ProblemList, I believe >>>>>>>>>>> jtreg was excluding the test from running. >>>>>>>>>>> >>>>>>>>>>> The original problem reported an "out of swap" condition. >>>>>>>>>>> >>>>>>>>>>> The current failure reports: >>>>>>>>>>> ----------System.out:(3/217)---------- >>>>>>>>>>> Creating threads... >>>>>>>>>>> Timeout refired 480 times >>>>>>>>>>> [730.871s][warning][os,thread] Failed to start thread - >>>>>>>>>>> _beginthreadex failed (EACCES) for attributes: stacksize: >>>>>>>>>>> default, flags: CREATE_SUSPENDED STACK_SIZE_PARAM_IS. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/7/19, 4:02 PM, Chris Plummer wrote: >>>>>>>>>>>> Hi Gary, >>>>>>>>>>>> >>>>>>>>>>>> Why did you remove the "nonconcurrent" keyword. I know >>>>>>>>>>>> these are just comments for reference that were added when >>>>>>>>>>>> the test was ported from tonga, but as a comment it is >>>>>>>>>>>> still applicable. The test should not be run concurrent >>>>>>>>>>>> with others (which you have also fixed with the addition of >>>>>>>>>>>> the "exclusiveAccess.dirs=."). >>>>>>>>>>>> >>>>>>>>>>>> Otherwise changes look good. >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 3/7/19 10:57 AM, Gary Adams wrote: >>>>>>>>>>>>> This proposed fix will restore the ResourceExhausted tests. >>>>>>>>>>>>> >>>>>>>>>>>>> Test 3 and 4 were on the ProblemList because of the potential >>>>>>>>>>>>> path issues in finding the correct classes. This change >>>>>>>>>>>>> searches the >>>>>>>>>>>>> test.class.path for the appropriate vmTestbase classes >>>>>>>>>>>>> rather than using >>>>>>>>>>>>> incorrect settings on the command line. >>>>>>>>>>>>> >>>>>>>>>>>>> Some clean up has been done to remove quarantine keyword >>>>>>>>>>>>> and @ignore directives. Should additional clean up be done >>>>>>>>>>>>> to remove >>>>>>>>>>>>> bug numbers, etc.? >>>>>>>>>>>>> >>>>>>>>>>>>> TEST.PROPERTIES were added so test 3 so it is consistent >>>>>>>>>>>>> with the other tests >>>>>>>>>>>>> in the group. >>>>>>>>>>>>> >>>>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218128 >>>>>>>>>>>>> ? Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~gadams/8218128/webrev.00/index.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Local testing has been successful on a linux-x64-debug build. >>>>>>>>>>>>> Testing on mach5 for other platforms next. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> From gary.adams at oracle.com Tue Mar 26 15:40:17 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 26 Mar 2019 11:40:17 -0400 Subject: JDK-8207347: HeapDumpAllTest.java fails intermittently Message-ID: <5C9A47E1.1000109@oracle.com> I'll try one more time to reproduce the failure running the serviceability/dcmd tests. If there are no failures, I plan to close the issue similar to what was done for JDK-8217220 runtime/NMT/MallocStressTest.java: target process doesn't respond -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Tue Mar 26 18:06:57 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 26 Mar 2019 11:06:57 -0700 Subject: RFR 8217347 [TESTBUG] runtime/appcds/jvmti/InstrumentationTest.java timed out In-Reply-To: <094bab3c-5289-e5ce-393b-3255fbdd80e0@oracle.com> References: <024571ee-df96-36fd-9f2b-a1730f4c56b7@oracle.com> <2134a4ab-a731-2b71-4963-8f5f83c11a04@oracle.com> <9a99a0ae-41f6-61aa-b62e-49c458ba5728@oracle.com> <094bab3c-5289-e5ce-393b-3255fbdd80e0@oracle.com> Message-ID: Hi David, thanks for the review! - Ioi On 3/26/19 12:13 AM, David Holmes wrote: > Hi Ioi, > > On 26/03/2019 10:37 am, Ioi Lam wrote: >> Hi David, >> >> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v02/ >> >> >> Thanks for the explanation. I've reverted my previous changes and >> instead modified how the hand-shake is done. There's no need to use >> VirtualMachine.list() as the pid is passed as part of the hand-shake. >> >> // Hand-shake protocol with the child process >> // [1] Parent process (this process) launches child process >> (InstrumentationApp) >> //???? and then waits until child process writes its pid into the >> flagFile. >> // [2] Child process process starts up, writes its pid into the >> flagFile, >> //???? and waits for the flagFile to be deleted. >> // [3] When parent process gets the pid, it attaches to the child >> process >> //???? (if we attempt to attach to a process too early, the SIGQUIT >> //???? may cause the child to die) and deletes the flagFile. >> // [4] Child process resumes execution. > > Okay that all seems fine. > > The test could be simplified further I think but that's a different > story. > > Thanks, > David > >> Thanks >> - Ioi >> >> >> On 3/24/19 10:28 PM, David Holmes wrote: >>> On 25/03/2019 3:06 pm, Ioi Lam wrote: >>>> >>>> >>>> On 3/24/19 9:14 PM, David Holmes wrote: >>>>> Hi Ioi, >>>>> >>>>> On 25/03/2019 1:46 pm, Ioi Lam wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8217347 >>>>>> http://cr.openjdk.java.net/~iklam/jdk13/8217347-appcds-InstrumentationTest-timeout.v01/ >>>>>> >>>>>> >>>>>> This test case used VirtualMachine.list() to find the pid of the >>>>>> the child >>>>>> process. However, as David Holmes commented in the bug report, it's >>>>>> suspected that this call may lead to timeout. >>>>>> >>>>>> In any case, since Process.pid() has been added since JDK 9, it's >>>>>> better to call this >>>>>> API directly. That way, we can avoid unnecessary dependency on >>>>>> VirtualMachine.list(). >>>>> >>>>> In so far as I can see how you replaced the VM.list() with >>>>> Process.pid() this seems okay. I'm having trouble actually >>>>> understanding the handshake being used to control things though. I >>>>> would have expected the target VM to create the flagfile to >>>>> indicate it is ready for attaching, then it would wait for the >>>>> flagfile to be deleted. >>>>> >>>> >>>> Hi David, >>>> >>>> As far as I can tell, the handshake is this: the main test process >>>> creates the flag file and passes the name of the flag file to the >>>> child process (whose main class is InstrumentationApp). The child >>>> process will wait until the main process deletes the flag file. >>>> >>>> After the child process is launched, the main process attaches to >>>> it (using the child's pid), and then deletes the flag file. At that >>>> point, the child will resume execution. >>> >>> Okay but the problem is that the main process can try to attach to >>> the child process before the child is ready to be attached to. This >>> is a day one limitation of the attach-on-demand process. If the >>> child process created the flags file (using the name supplied by the >>> main process) the main process could wait until it sees it to do the >>> attach. >>> >>> Anyway this is not directly related to your fix, just be aware this >>> test can fail in obscure ways as the child process may silently >>> disappear if the SIGQUIT used to attach-on-demand arrives too soon. >>> >>>> >>>> BTW, I found this comment to be out-dated so I changed it: >>>> >>>> -??????? // At this point, the child process is not yet launched. >>>> Note that >>>> -??????? // TestCommon.exec() and OutputAnalyzer.OutputAnalyzer() >>>> both block >>>> -??????? // until the child process has finished. >>>> -??????? // >>>> -??????? // So, we will launch a AgentAttachThread which will poll >>>> the system >>>> -??????? // until the child process is launched, and then do the >>>> attachment. >>>> -??????? // The child process is uniquely identified by having >>>> flagFile in its >>>> -??????? // command-line -- see AgentAttachThread.getPid(). >>>> >>>> +??????? // At this point, the child process is not yet launched. >>>> +??????? // We will launch a AgentAttachThread which will wait until >>>> +??????? // the child process's pid is known, and then do the >>>> attachment. >>> >>> Okay but the comment is out of date because you now return the >>> process directly, which means you no longer need the >>> AgentAttachThread at all, you can do the attach logic directly from >>> the main thread. >>> >>> Cheers, >>> David >>> ----- >>> >>>> ????????? AgentAttachThread t = new AgentAttachThread(flagFile, >>>> agentJar); >>>> ????????? t.start(); >>>> ????????? return t; >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Tested with tiers{1,2,3}. Also removed some unnecessary @module >>>>>> and import lines. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>> >> From serguei.spitsyn at oracle.com Tue Mar 26 21:10:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Mar 2019 14:10:48 -0700 Subject: RFR(XXS): 8221513: Add vmTestbase/nsk/jdb/eval/eval001/eval001.java to ProblemList.txt Message-ID: <0e3c7287-94ad-13e7-d123-71020f75a282@oracle.com> Please, review the following trivial fix for: ? https://bugs.openjdk.java.net/browse/JDK-8221513 The vmTestbase/nsk/jdb/eval/eval001/eval001.java started to fail after fix of JDK-8146986. New bug has been filed: ? https://bugs.openjdk.java.net/browse/JDK-8221503 ?? vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] The simplest approach is to problem list the test until JDK-8221503 is fixed. The change is: diff -r 176e8aec3097 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Mar 25 19:16:58 2019 -0700 +++ b/test/hotspot/jtreg/ProblemList.txt??? Tue Mar 26 13:52:50 2019 -0700 @@ -162,6 +162,8 @@ ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all + ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 generic-all Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Mar 26 21:23:41 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Mar 2019 17:23:41 -0400 Subject: RFR(XXS): 8221513: Add vmTestbase/nsk/jdb/eval/eval001/eval001.java to ProblemList.txt In-Reply-To: <0e3c7287-94ad-13e7-d123-71020f75a282@oracle.com> References: <0e3c7287-94ad-13e7-d123-71020f75a282@oracle.com> Message-ID: Thumbs up. I agree that this is trivial. Dan P.S. I also converted JDK-8221513 into a subtask of JDK-8221503. On 3/26/19 5:10 PM, serguei.spitsyn at oracle.com wrote: > Please, review the following trivial fix for: > https://bugs.openjdk.java.net/browse/JDK-8221513 > > The vmTestbase/nsk/jdb/eval/eval001/eval001.java started to fail after > fix of JDK-8146986. > New bug has been filed: > https://bugs.openjdk.java.net/browse/JDK-8221503 > ?? vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: > com.sun.jdi.InvalidTypeException: Can't assign double[][][] to > double[][][] > > The simplest approach is to problem list the test until JDK-8221503 is > fixed. > > The change is: > > diff -r 176e8aec3097 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Mar 25 19:16:58 2019 -0700 > +++ b/test/hotspot/jtreg/ProblemList.txt??? Tue Mar 26 13:52:50 2019 -0700 > @@ -162,6 +162,8 @@ > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > + > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 > generic-all > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Mar 26 21:40:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Mar 2019 14:40:14 -0700 Subject: RFR(XXS): 8221513: Add vmTestbase/nsk/jdb/eval/eval001/eval001.java to ProblemList.txt In-Reply-To: References: <0e3c7287-94ad-13e7-d123-71020f75a282@oracle.com> Message-ID: <6deebe95-2be5-b230-c5b9-ab2b2661511c@oracle.com> Thanks a lot, Dan! Serguei On 3/26/19 2:23 PM, Daniel D. Daugherty wrote: > Thumbs up. I agree that this is trivial. > > Dan > > P.S. > I also converted JDK-8221513 into a subtask of JDK-8221503. > > On 3/26/19 5:10 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the following trivial fix for: >> https://bugs.openjdk.java.net/browse/JDK-8221513 >> >> The vmTestbase/nsk/jdb/eval/eval001/eval001.java started to fail >> after fix of JDK-8146986. >> New bug has been filed: >> https://bugs.openjdk.java.net/browse/JDK-8221503 >> ?? vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: >> com.sun.jdi.InvalidTypeException: Can't assign double[][][] to >> double[][][] >> >> The simplest approach is to problem list the test until JDK-8221503 >> is fixed. >> >> The change is: >> >> diff -r 176e8aec3097 test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Mar 25 19:16:58 2019 >> -0700 >> +++ b/test/hotspot/jtreg/ProblemList.txt??? Tue Mar 26 13:52:50 2019 >> -0700 >> @@ -162,6 +162,8 @@ >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> >> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >> + >> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 >> generic-all >> >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.gasson at arm.com Wed Mar 27 03:19:40 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 27 Mar 2019 11:19:40 +0800 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> Message-ID: Hi, Could I get another reviewer to look at this please? Thanks! Nick On 18/03/2019 18:04, Nick Gasson wrote: > Hi Sharath, > > On 15/03/2019 23:32, Sharath Ballal wrote: >> >> Fix looks good.? How have you tested it ? > > I ran the test using the "make test" target with and without > JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail with > that argument. > > Thanks, > Nick From daniil.x.titov at oracle.com Wed Mar 27 03:32:40 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 26 Mar 2019 20:32:40 -0700 Subject: RFR: 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library Message-ID: <2326BE1A-49F9-41CF-BA02-42DDA6BD4305@oracle.com> Please review the change that fixes the test when running with Graal on. The problem here is the lack of synchronization when accessing the internal data structure (the list of events) in the agent procedure and in the callbacks the test enables. That results in the agent proc starts removing elements from the list of the events while the callback handlers are still enabled, assuming that no new events could be generated, but in case of Graal it is not true. This causes to the crash when the callback iterates over the list of events and tries to access the element that was just removed by the agent procedure. Webrev: http://cr.openjdk.java.net/~dtitov/8218727/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218727 Thanks! --Daniil From serguei.spitsyn at oracle.com Wed Mar 27 07:59:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Mar 2019 00:59:11 -0700 Subject: RFR: 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library In-Reply-To: <2326BE1A-49F9-41CF-BA02-42DDA6BD4305@oracle.com> References: <2326BE1A-49F9-41CF-BA02-42DDA6BD4305@oracle.com> Message-ID: Hi Daniil, The fix looks good. Thanks, Serguei On 3/26/19 20:32, Daniil Titov wrote: > Please review the change that fixes the test when running with Graal on. > > The problem here is the lack of synchronization when accessing the internal data structure (the list of events) in the agent procedure and in the callbacks the test enables. That results in the agent proc starts removing elements from the list of the events while the callback handlers are still enabled, assuming that no new events could be generated, but in case of Graal it is not true. This causes to the crash when the callback iterates over the list of events and tries to access the element that was just removed by the agent procedure. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218727/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218727 > > Thanks! > > --Daniil > > > From gary.adams at oracle.com Wed Mar 27 12:20:25 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 27 Mar 2019 08:20:25 -0400 Subject: RFR: 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library In-Reply-To: References: <2326BE1A-49F9-41CF-BA02-42DDA6BD4305@oracle.com> Message-ID: <5C9B6A89.9050000@oracle.com> Looks OK to me. On 3/27/19, 3:59 AM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > The fix looks good. > > Thanks, > Serguei > > > On 3/26/19 20:32, Daniil Titov wrote: >> Please review the change that fixes the test when running with Graal on. >> >> The problem here is the lack of synchronization when accessing the >> internal data structure (the list of events) in the agent procedure >> and in the callbacks the test enables. That results in the agent proc >> starts removing elements from the list of the events while the >> callback handlers are still enabled, assuming that no new events >> could be generated, but in case of Graal it is not true. This causes >> to the crash when the callback iterates over the list of events and >> tries to access the element that was just removed by the agent >> procedure. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8218727/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218727 >> >> Thanks! >> >> --Daniil >> >> >> > From coleen.phillimore at oracle.com Wed Mar 27 13:09:42 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 27 Mar 2019 09:09:42 -0400 Subject: RFR (M) 8221183: Avoid code cache walk in MetadataOnStackMark Message-ID: Summary: Note nmethods with "old" Methods in them in table to walk instead. See RFE for more details.? Tested with RedefineClasses tests with/without -Xcomp, mach5 tier1-5. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8221183.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8221183 Thanks, Coleen From daniil.x.titov at oracle.com Wed Mar 27 18:18:50 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 27 Mar 2019 11:18:50 -0700 Subject: RFR: 8221532: Incorrect copyright header in FileSystemSupport_md.c Message-ID: Please review a trivial change that fixes the copyright headers in two files. Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 Thanks! --Daniil From chris.plummer at oracle.com Wed Mar 27 18:46:29 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 27 Mar 2019 11:46:29 -0700 Subject: RFR: 8221532: Incorrect copyright header in FileSystemSupport_md.c In-Reply-To: References: Message-ID: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> Hi Daniil, The copyright year should not be changed when fixing copyright issues. thanks, Chris On 3/27/19 11:18 AM, Daniil Titov wrote: > Please review a trivial change that fixes the copyright headers in two files. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Wed Mar 27 18:58:37 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 27 Mar 2019 11:58:37 -0700 Subject: 8221532: Incorrect copyright header in FileSystemSupport_md.c In-Reply-To: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> References: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> Message-ID: <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> Hi Chris, Please review a new version of the webrev that corrects this. Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 Thanks! --Daniil ?On 3/27/19, 11:46 AM, "Chris Plummer" wrote: Hi Daniil, The copyright year should not be changed when fixing copyright issues. thanks, Chris On 3/27/19 11:18 AM, Daniil Titov wrote: > Please review a trivial change that fixes the copyright headers in two files. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > Thanks! > --Daniil > > From gary.adams at oracle.com Wed Mar 27 19:11:30 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 27 Mar 2019 15:11:30 -0400 Subject: 8221532: Incorrect copyright header in FileSystemSupport_md.c In-Reply-To: <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> References: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> Message-ID: Looks good to me . On 3/27/19 2:58 PM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the webrev that corrects this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > Thanks! > --Daniil > > ?On 3/27/19, 11:46 AM, "Chris Plummer" wrote: > > Hi Daniil, > > The copyright year should not be changed when fixing copyright issues. > > thanks, > > Chris > > On 3/27/19 11:18 AM, Daniil Titov wrote: > > Please review a trivial change that fixes the copyright headers in two files. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > > > Thanks! > > --Daniil > > > > > > > > From chris.plummer at oracle.com Wed Mar 27 19:19:26 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 27 Mar 2019 12:19:26 -0700 Subject: 8221532: Incorrect copyright header in FileSystemSupport_md.c In-Reply-To: <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> References: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> Message-ID: <7ef6e2bf-9118-43ca-d9f6-69154241700f@oracle.com> Looks good. Chris On 3/27/19 11:58 AM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the webrev that corrects this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > Thanks! > --Daniil > > ?On 3/27/19, 11:46 AM, "Chris Plummer" wrote: > > Hi Daniil, > > The copyright year should not be changed when fixing copyright issues. > > thanks, > > Chris > > On 3/27/19 11:18 AM, Daniil Titov wrote: > > Please review a trivial change that fixes the copyright headers in two files. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > > > Thanks! > > --Daniil > > > > > > > > From daniil.x.titov at oracle.com Wed Mar 27 19:42:19 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 27 Mar 2019 12:42:19 -0700 Subject: 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library In-Reply-To: <5C9B6A89.9050000@oracle.com> References: <2326BE1A-49F9-41CF-BA02-42DDA6BD4305@oracle.com> <5C9B6A89.9050000@oracle.com> Message-ID: <36D019B1-0876-4E25-BC33-CD0654AF0616@oracle.com> Thank you, Serguei and Gary, for reviewing this change! --Daniil ?On 3/27/19, 5:20 AM, "Gary Adams" wrote: Looks OK to me. On 3/27/19, 3:59 AM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > The fix looks good. > > Thanks, > Serguei > > > On 3/26/19 20:32, Daniil Titov wrote: >> Please review the change that fixes the test when running with Graal on. >> >> The problem here is the lack of synchronization when accessing the >> internal data structure (the list of events) in the agent procedure >> and in the callbacks the test enables. That results in the agent proc >> starts removing elements from the list of the events while the >> callback handlers are still enabled, assuming that no new events >> could be generated, but in case of Graal it is not true. This causes >> to the crash when the callback iterates over the list of events and >> tries to access the element that was just removed by the agent >> procedure. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8218727/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218727 >> >> Thanks! >> >> --Daniil >> >> >> > From daniil.x.titov at oracle.com Wed Mar 27 19:43:09 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 27 Mar 2019 12:43:09 -0700 Subject: 8221532: Incorrect copyright header in FileSystemSupport_md.c In-Reply-To: <7ef6e2bf-9118-43ca-d9f6-69154241700f@oracle.com> References: <70a0c3a6-fb16-bb35-f3ec-91a54419c9eb@oracle.com> <2C134C49-F4D5-40B3-83A3-6AA817A27829@oracle.com> <7ef6e2bf-9118-43ca-d9f6-69154241700f@oracle.com> Message-ID: <1762EBAA-328C-4D9E-AE6C-57AB25D55704@oracle.com> Thank you, Chris and Gary, for review! --Daniil ?On 3/27/19, 12:19 PM, "Chris Plummer" wrote: Looks good. Chris On 3/27/19 11:58 AM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the webrev that corrects this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > Thanks! > --Daniil > > ?On 3/27/19, 11:46 AM, "Chris Plummer" wrote: > > Hi Daniil, > > The copyright year should not be changed when fixing copyright issues. > > thanks, > > Chris > > On 3/27/19 11:18 AM, Daniil Titov wrote: > > Please review a trivial change that fixes the copyright headers in two files. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 > > > > Thanks! > > --Daniil > > > > > > > > From alexey.menkov at oracle.com Wed Mar 27 23:04:37 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 27 Mar 2019 16:04:37 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 Message-ID: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8184770 webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/ Main changes are in socketTransport.c - the code is updated to support both IPv4 and IPv6. Some details to simplify reviewing: - listening: - if IP address is specified (like 127.0.0.1 or ::1), connector listens only on this address; - for backward compatibility if no address (or "localhost") is specified, IPv4 is used (if supported by the host); - if "*" is specified (means "listen on all local interfaces"), dual mode socket is used to listen on both IPv6 and IPv4 addresses; - AllowedPeerInfo structure (for "allow" option) is updated to use IPv6 address/mask, support for IPv4 is implemented by using "mapped" IPv4 addresses; - attaching: agent resolves and tries to connect to all (IPv4 and IPv6) addresses, IPv4 are tried first; SocketListeningConnector.java/SocketTransportService.java are updated to support IPv6 addresses (the addresses may contain colons); new JdwpAttachTest.java/JdwpListenTest.java test that listening and attaching works for all available addresses (Ipv4 and IPv6) BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it tests "allow" functionality), tests for mask (prefix length) functionality are added (for both IPv4 and IPv6); --alex From serguei.spitsyn at oracle.com Thu Mar 28 00:55:04 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Mar 2019 17:55:04 -0700 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods Message-ID: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Mar 28 07:02:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 08:02:49 +0100 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: Hi Serguei, This is planned to be introduced in jdk 13? The only concern I have is that both paths (old and new behavior) should be well tested, and hiding the old behavior behind an optional switch may reduce its test coverage considerably. Cheers, Thomas (p.s. html format does not work well with the OpenJDK mailing list archive, see https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html ) On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi All, > > This is request for comments and potentially reviews for the following CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > *Problem* > > Now, the implementation of JVMTI RedefineClasses and RetransformClasses > allows to > add/delete private static and private final instance methods in the new > class versions. > > It means that current implementation does not follow the JVM TI spec which > explicitly states: > > "The redefinition must not add, remove or rename fields or methods, change > the signatures > of methods, change modifiers, or change inheritance." > > For details, please, see the spec: > > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses > > The decision was made to align the implementation with the spec. > For reference, please, see the > https://bugs.openjdk.java.net/browse/JDK-8192936. > > This decision is going to cause some inconveniences to the customers. > > > *Solution* > > The solution is to introduce a compatibility mode with new command-line VM > option: > -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods > > New option will enable old behavior and allow the JVM TI RedefineClasses > and RetransformClasses > to add/delete private static and private final instance methods in the new > class versions. > Without this option the old behavior will be disabled. > > New option is deprecated right away. > The plan is to keep it for a couple of releases to allow customers (tool > vendors) > to remove dependency on old behavior from their tools. > > Thanks, > Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 28 07:40:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 17:40:25 +1000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> Hi Thomas, On 28/03/2019 5:02 pm, Thomas St?fe wrote: > Hi Serguei, > > This is planned to be introduced in jdk 13? > > The only concern I have is that both paths (old and new behavior) should > be well tested, and hiding the old behavior behind an optional switch > may reduce its test coverage considerably. The old behaviour is hardly ever used - I'm not even sure we currently have a test that tries to use it - so it's already not "well tested" and there's no intent here of increasing test coverage for the code we plan to remove. The new path will be tested as we do have a test that expects to get the error. And Serguei will of course have a simple test that checks the flag with both values. Cheers, David > Cheers, Thomas > > (p.s. html format does not work well with the OpenJDK mailing list > archive, see > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html) > > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com > > wrote: > > Hi All, > > This is request for comments and potentially reviews for the > following CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > *Problem* > > Now, the implementation of JVMTI RedefineClasses and > RetransformClasses allows to > add/delete private static and private final instance methods in the > new class versions. > > It means that current implementation does not follow the JVM TI spec > which explicitly states: > > "The redefinition must not add, remove or rename fields or methods, > change the signatures > ?of methods, change modifiers, or change inheritance." > > For details, please, see the spec: > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses > > The decision was made to align the implementation with the spec. > For reference, please, see the > https://bugs.openjdk.java.net/browse/JDK-8192936. > > This decision is going to cause some inconveniences to the customers. > > > *Solution* > > The solution is to introduce a compatibility mode with new > command-line VM option: > ?? -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods > > New option will enable old behavior and allow the JVM TI > RedefineClasses and RetransformClasses > to add/delete private static and private final instance methods in > the new class versions. > Without this option the old behavior will be disabled. > > New option is deprecated right away. > The plan is to keep it for a couple of releases to allow customers > (tool vendors) > to remove dependency on old behavior from their tools. > > Thanks, > Serguei > From volker.simonis at gmail.com Thu Mar 28 07:54:37 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Mar 2019 08:54:37 +0100 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: Hi Serguei, can you please detail a little bit on the reasons why you finally decided to change the implementation to conform to the spec instead of just updating the spec to endorse a behavior which is there since quite some time? I read trough the comment thread of "JDK-8192936" and it seems to me that right until your last comment from today, the general conses has been to change the specs rather than the implementation. I understand from the various comments in that issue that changing the specs is not trivial but still doable. Unfortunately, some of the referenced material in that issue is not available outside Oracle (i.e. wiki.se.oracle.com) - it would be nice if you could make these information available in the OpenJDK wiki or somewhere else. I think that adding private methods is a feature widely used by a lot of tools and removing it will break them. Deprecating this feature in a non-LTS release and removing it after "a couple" of (non-LTS) releases won't help a lot because many productive systems won't use these releases anyway. Thank you and best regards, Volker On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com wrote: > > Hi All, > > This is request for comments and potentially reviews for the following CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Problem > > Now, the implementation of JVMTI RedefineClasses and RetransformClasses allows to > add/delete private static and private final instance methods in the new class versions. > > It means that current implementation does not follow the JVM TI spec which explicitly states: > > "The redefinition must not add, remove or rename fields or methods, change the signatures > of methods, change modifiers, or change inheritance." > > For details, please, see the spec: > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses > > The decision was made to align the implementation with the spec. > For reference, please, see the https://bugs.openjdk.java.net/browse/JDK-8192936. > > This decision is going to cause some inconveniences to the customers. > > > Solution > > The solution is to introduce a compatibility mode with new command-line VM option: > -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods > > New option will enable old behavior and allow the JVM TI RedefineClasses and RetransformClasses > to add/delete private static and private final instance methods in the new class versions. > Without this option the old behavior will be disabled. > > New option is deprecated right away. > The plan is to keep it for a couple of releases to allow customers (tool vendors) > to remove dependency on old behavior from their tools. > > Thanks, > Serguei From thomas.stuefe at gmail.com Thu Mar 28 06:55:34 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 07:55:34 +0100 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> Message-ID: On Thu, Mar 28, 2019 at 8:40 AM David Holmes wrote: > Hi Thomas, > > On 28/03/2019 5:02 pm, Thomas St?fe wrote: > > Hi Serguei, > > > > This is planned to be introduced in jdk 13? > > > > The only concern I have is that both paths (old and new behavior) should > > be well tested, and hiding the old behavior behind an optional switch > > may reduce its test coverage considerably. > > The old behaviour is hardly ever used - I'm not even sure we currently > have a test that tries to use it - so it's already not "well tested" and > there's no intent here of increasing test coverage for the code we plan > to remove. The new path will be tested as we do have a test that expects > to get the error. And Serguei will of course have a simple test that > checks the flag with both values. > I remember at least one case causing crashes in our code base where the method ordering array was not reordered on RedefineClasses. May have been this one: JDK-8149743. My point is, I have seen crashes in the field coming from bytecode agents redefining classes with method added or substracted, so it is no theoretical problem. Cheers Thomas > > Cheers, > David > > > > Cheers, Thomas > > > > (p.s. html format does not work well with the OpenJDK mailing list > > archive, see > > > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html > ) > > > > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com > > > > wrote: > > > > Hi All, > > > > This is request for comments and potentially reviews for the > > following CSR: > > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > > > > *Problem* > > > > Now, the implementation of JVMTI RedefineClasses and > > RetransformClasses allows to > > add/delete private static and private final instance methods in the > > new class versions. > > > > It means that current implementation does not follow the JVM TI spec > > which explicitly states: > > > > "The redefinition must not add, remove or rename fields or methods, > > change the signatures > > of methods, change modifiers, or change inheritance." > > > > For details, please, see the spec: > > > > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses > > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses > > > > The decision was made to align the implementation with the spec. > > For reference, please, see the > > https://bugs.openjdk.java.net/browse/JDK-8192936. > > > > This decision is going to cause some inconveniences to the customers. > > > > > > *Solution* > > > > The solution is to introduce a compatibility mode with new > > command-line VM option: > > -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods > > > > New option will enable old behavior and allow the JVM TI > > RedefineClasses and RetransformClasses > > to add/delete private static and private final instance methods in > > the new class versions. > > Without this option the old behavior will be disabled. > > > > New option is deprecated right away. > > The plan is to keep it for a couple of releases to allow customers > > (tool vendors) > > to remove dependency on old behavior from their tools. > > > > Thanks, > > Serguei > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Mar 28 08:10:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 08:10:56 +0000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: <7f7a7c89-db7b-e094-a9b0-c7291049b2bd@oracle.com> On 28/03/2019 07:54, Volker Simonis wrote: > : > > I think that adding private methods is a feature widely used by a lot > of tools and removing it will break them. Can you provide examples of tools that are making use of this? -Alan From david.holmes at oracle.com Thu Mar 28 10:10:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 20:10:27 +1000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> Message-ID: <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> On 28/03/2019 4:55 pm, Thomas St?fe wrote: > On Thu, Mar 28, 2019 at 8:40 AM David Holmes > wrote: > > Hi Thomas, > > On 28/03/2019 5:02 pm, Thomas St?fe wrote: > > Hi Serguei, > > > > This is planned to be introduced in jdk 13? > > > > The only concern I have is that both paths (old and new behavior) > should > > be well tested, and hiding the old behavior behind an optional > switch > > may reduce its test coverage considerably. > > The old behaviour is hardly ever used - I'm not even sure we currently > have a test that tries to use it - so it's already not "well tested" > and > there's no intent here of increasing test coverage for the code we plan > to remove. The new path will be tested as we do have a test that > expects > to get the error. And Serguei will of course have a simple test that > checks the flag with both values. > > > I remember at least one case causing crashes in our code base where the > method ordering array was not reordered on RedefineClasses. May have > been this one: JDK-8149743. > > My point is, I have seen crashes in the field coming from bytecode > agents redefining classes with method added or substracted, so it is no > theoretical problem. My point is that we don't really care if the code works well or not, we're intending to kill it off not improve it. It's a capability that really should never have snuck in to the code. Cheers, David > Cheers Thomas > > > Cheers, > David > > > > Cheers, Thomas > > > > (p.s. html format does not work well with the OpenJDK mailing list > > archive, see > > > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html) > > > > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com > > > > > > >> wrote: > > > >? ? ?Hi All, > > > >? ? ?This is request for comments and potentially reviews for the > >? ? ?following CSR: > > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > > > >? ? ?*Problem* > > > >? ? ?Now, the implementation of JVMTI RedefineClasses and > >? ? ?RetransformClasses allows to > >? ? ?add/delete private static and private final instance methods > in the > >? ? ?new class versions. > > > >? ? ?It means that current implementation does not follow the JVM > TI spec > >? ? ?which explicitly states: > > > >? ? ?"The redefinition must not add, remove or rename fields or > methods, > >? ? ?change the signatures > >? ? ? ?of methods, change modifiers, or change inheritance." > > > >? ? ?For details, please, see the spec: > > > > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses > > > https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses > > > >? ? ?The decision was made to align the implementation with the spec. > >? ? ?For reference, please, see the > > https://bugs.openjdk.java.net/browse/JDK-8192936. > > > >? ? ?This decision is going to cause some inconveniences to the > customers. > > > > > >? ? ?*Solution* > > > >? ? ?The solution is to introduce a compatibility mode with new > >? ? ?command-line VM option: > >? ? ? ?? -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods > > > >? ? ?New option will enable old behavior and allow the JVM TI > >? ? ?RedefineClasses and RetransformClasses > >? ? ?to add/delete private static and private final instance > methods in > >? ? ?the new class versions. > >? ? ?Without this option the old behavior will be disabled. > > > >? ? ?New option is deprecated right away. > >? ? ?The plan is to keep it for a couple of releases to allow > customers > >? ? ?(tool vendors) > >? ? ?to remove dependency on old behavior from their tools. > > > >? ? ?Thanks, > >? ? ?Serguei > > > From david.holmes at oracle.com Thu Mar 28 10:15:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 20:15:26 +1000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: Hi Volker, On 28/03/2019 5:54 pm, Volker Simonis wrote: > Hi Serguei, > > can you please detail a little bit on the reasons why you finally > decided to change the implementation to conform to the spec instead of > just updating the spec to endorse a behavior which is there since > quite some time? The behaviour that has been there "quite some time" only actually works for very limited usecases. In trying to legitimise the capability and allow you to add/remove private methods we encountered an ever increasing spiral of complexity in trying to establish meaningful semantics. Is it physically possible to implement this? Yes. It is worth the cost in complexity and maintenance? We concluded not. We should try to produce a better summary of all the issues. Cheers, David > I read trough the comment thread of "JDK-8192936" and it seems to me > that right until your last comment from today, the general conses has > been to change the specs rather than the implementation. I understand > from the various comments in that issue that changing the specs is not > trivial but still doable. Unfortunately, some of the referenced > material in that issue is not available outside Oracle (i.e. > wiki.se.oracle.com) - it would be nice if you could make these > information available in the OpenJDK wiki or somewhere else. > > I think that adding private methods is a feature widely used by a lot > of tools and removing it will break them. Deprecating this feature in > a non-LTS release and removing it after "a couple" of (non-LTS) > releases won't help a lot because many productive systems won't use > these releases anyway. > > Thank you and best regards, > Volker > > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com > wrote: >> >> Hi All, >> >> This is request for comments and potentially reviews for the following CSR: >> https://bugs.openjdk.java.net/browse/JDK-8221528 >> >> >> Problem >> >> Now, the implementation of JVMTI RedefineClasses and RetransformClasses allows to >> add/delete private static and private final instance methods in the new class versions. >> >> It means that current implementation does not follow the JVM TI spec which explicitly states: >> >> "The redefinition must not add, remove or rename fields or methods, change the signatures >> of methods, change modifiers, or change inheritance." >> >> For details, please, see the spec: >> >> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses >> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses >> >> The decision was made to align the implementation with the spec. >> For reference, please, see the https://bugs.openjdk.java.net/browse/JDK-8192936. >> >> This decision is going to cause some inconveniences to the customers. >> >> >> Solution >> >> The solution is to introduce a compatibility mode with new command-line VM option: >> -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods >> >> New option will enable old behavior and allow the JVM TI RedefineClasses and RetransformClasses >> to add/delete private static and private final instance methods in the new class versions. >> Without this option the old behavior will be disabled. >> >> New option is deprecated right away. >> The plan is to keep it for a couple of releases to allow customers (tool vendors) >> to remove dependency on old behavior from their tools. >> >> Thanks, >> Serguei From Michael.Rasmussen at roguewave.com Thu Mar 28 10:19:13 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Thu, 28 Mar 2019 10:19:13 +0000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> , <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: It was my assumption that the reason adding private methods were allowed with redefineClass was to support adding/removing lambdas from method bodies, since javac converts those into private methods. Removing this capability would remove this support. I would assume that would cause users a lot of headache, since from a user's point-of-view, they are just changing the method body, which should be supported! /Michael From: serviceability-dev on behalf of David Holmes Sent: 28 March 2019 12:10 To: Thomas St?fe Cc: serviceability-dev at openjdk.java.net; Coleen Phillimore Subject: Re: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods ? On 28/03/2019 4:55 pm, Thomas St?fe wrote: > On Thu, Mar 28, 2019 at 8:40 AM David Holmes > wrote: > >???? Hi Thomas, > >???? On 28/03/2019 5:02 pm, Thomas St?fe wrote: >????? > Hi Serguei, >????? > >????? > This is planned to be introduced in jdk 13? >????? > >????? > The only concern I have is that both paths (old and new behavior) >???? should >????? > be well tested, and hiding the old behavior behind an optional >???? switch >????? > may reduce its test coverage considerably. > >???? The old behaviour is hardly ever used - I'm not even sure we currently >???? have a test that tries to use it - so it's already not "well tested" >???? and >???? there's no intent here of increasing test coverage for the code we plan >???? to remove. The new path will be tested as we do have a test that >???? expects >???? to get the error. And Serguei will of course have a simple test that >???? checks the flag with both values. > > > I remember at least one case causing crashes in our code base where the > method ordering array was not reordered on RedefineClasses. May have > been this one: JDK-8149743. > > My point is, I have seen crashes in the field coming from bytecode > agents redefining classes with method added or substracted, so it is no > theoretical problem. My point is that we don't really care if the code works well or not, we're intending to kill it off not improve it. It's a capability that really should never have snuck in to the code. Cheers, David > Cheers Thomas > > >???? Cheers, >???? David > > >????? > Cheers, Thomas >????? > >????? > (p.s. html format does not work well with the OpenJDK mailing list >????? > archive, see >????? > >???? https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html) >????? > >????? > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com >???? >????? > ???? > ???? >????? > ???? >> wrote: >????? > >????? >? ? ?Hi All, >????? > >????? >? ? ?This is request for comments and potentially reviews for the >????? >? ? ?following CSR: >????? > https://bugs.openjdk.java.net/browse/JDK-8221528 >????? > >????? > >????? >? ? ?*Problem* >????? > >????? >? ? ?Now, the implementation of JVMTI RedefineClasses and >????? >? ? ?RetransformClasses allows to >????? >? ? ?add/delete private static and private final instance methods >???? in the >????? >? ? ?new class versions. >????? > >????? >? ? ?It means that current implementation does not follow the JVM >???? TI spec >????? >? ? ?which explicitly states: >????? > >????? >? ? ?"The redefinition must not add, remove or rename fields or >???? methods, >????? >? ? ?change the signatures >????? >? ? ? ?of methods, change modifiers, or change inheritance." >????? > >????? >? ? ?For details, please, see the spec: >????? > >????? > >???? https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses >????? > >???? https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses >????? > >????? >? ? ?The decision was made to align the implementation with the spec. >????? >? ? ?For reference, please, see the >????? > https://bugs.openjdk.java.net/browse/JDK-8192936. >????? > >????? >? ? ?This decision is going to cause some inconveniences to the >???? customers. >????? > >????? > >????? >? ? ?*Solution* >????? > >????? >? ? ?The solution is to introduce a compatibility mode with new >????? >? ? ?command-line VM option: >????? >? ? ? ?? -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods >????? > >????? >? ? ?New option will enable old behavior and allow the JVM TI >????? >? ? ?RedefineClasses and RetransformClasses >????? >? ? ?to add/delete private static and private final instance >???? methods in >????? >? ? ?the new class versions. >????? >? ? ?Without this option the old behavior will be disabled. >????? > >????? >? ? ?New option is deprecated right away. >????? >? ? ?The plan is to keep it for a couple of releases to allow >???? customers >????? >? ? ?(tool vendors) >????? >? ? ?to remove dependency on old behavior from their tools. >????? > >????? >? ? ?Thanks, >????? >? ? ?Serguei >????? > > From thomas.stuefe at gmail.com Thu Mar 28 10:32:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 11:32:21 +0100 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: On Thu, Mar 28, 2019 at 11:10 AM David Holmes wrote: > On 28/03/2019 4:55 pm, Thomas St?fe wrote: > > On Thu, Mar 28, 2019 at 8:40 AM David Holmes > > wrote: > > > > Hi Thomas, > > > > On 28/03/2019 5:02 pm, Thomas St?fe wrote: > > > Hi Serguei, > > > > > > This is planned to be introduced in jdk 13? > > > > > > The only concern I have is that both paths (old and new behavior) > > should > > > be well tested, and hiding the old behavior behind an optional > > switch > > > may reduce its test coverage considerably. > > > > The old behaviour is hardly ever used - I'm not even sure we > currently > > have a test that tries to use it - so it's already not "well tested" > > and > > there's no intent here of increasing test coverage for the code we > plan > > to remove. The new path will be tested as we do have a test that > > expects > > to get the error. And Serguei will of course have a simple test that > > checks the flag with both values. > > > > > > I remember at least one case causing crashes in our code base where the > > method ordering array was not reordered on RedefineClasses. May have > > been this one: JDK-8149743. > > > > My point is, I have seen crashes in the field coming from bytecode > > agents redefining classes with method added or substracted, so it is no > > theoretical problem. > > My point is that we don't really care if the code works well or not, > we're intending to kill it off not improve it. It's a capability that > really should never have snuck in to the code. > > If you provide a backward compatibility switch which is not well tested, the coding behind it may bitrot; then, when you want to use it, you would run into errors. That is worse than not having that switch. Jdk head development goes at quite a pace, the chance that something which is not tested well bitrots is not that absurd. I am not idly bike shedding. I remember distinctly running into problems associated with RedefineClasses method adding/removal (I even remember us talking about it). So I know this is a thing which can happen. I do not want to improve it but I would like it to reliably work for as long as this switch exists. Cheers, Thomas > Cheers, > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 28 11:22:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 21:22:36 +1000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: On 28/03/2019 8:32 pm, Thomas St?fe wrote: > On Thu, Mar 28, 2019 at 11:10 AM David Holmes > wrote: > > On 28/03/2019 4:55 pm, Thomas St?fe wrote: > > On Thu, Mar 28, 2019 at 8:40 AM David Holmes > > > >> wrote: > > > >? ? ?Hi Thomas, > > > >? ? ?On 28/03/2019 5:02 pm, Thomas St?fe wrote: > >? ? ? > Hi Serguei, > >? ? ? > > >? ? ? > This is planned to be introduced in jdk 13? > >? ? ? > > >? ? ? > The only concern I have is that both paths (old and new > behavior) > >? ? ?should > >? ? ? > be well tested, and hiding the old behavior behind an optional > >? ? ?switch > >? ? ? > may reduce its test coverage considerably. > > > >? ? ?The old behaviour is hardly ever used - I'm not even sure we > currently > >? ? ?have a test that tries to use it - so it's already not "well > tested" > >? ? ?and > >? ? ?there's no intent here of increasing test coverage for the > code we plan > >? ? ?to remove. The new path will be tested as we do have a test that > >? ? ?expects > >? ? ?to get the error. And Serguei will of course have a simple > test that > >? ? ?checks the flag with both values. > > > > > > I remember at least one case causing crashes in our code base > where the > > method ordering array was not reordered on RedefineClasses. May have > > been this one: JDK-8149743. > > > > My point is, I have seen crashes in the field coming from bytecode > > agents redefining classes with method added or substracted, so it > is no > > theoretical problem. > > My point is that we don't really care if the code works well or not, > we're intending to kill it off not improve it. It's a capability that > really should never have snuck in to the code. > > > If you provide a backward compatibility switch which is not well tested, > the coding behind it may bitrot; then, when you want to use it, you > would run into errors. That is worse than not having that switch. AFAIK we don't actively test this code currently, so in that sense it can bitrot even without the flag. Serguei can correct me if I am wrong here. David ----- > Jdk head development goes at quite a pace, the chance that something > which is not tested well bitrots is not that absurd. > > I am not idly bike shedding. I remember distinctly running into problems > associated with RedefineClasses method adding/removal (I even remember > us talking about it). So I know this is a thing which can happen. I do > not want to improve it but I would like it to reliably work for as long > as this switch exists. > > Cheers, Thomas > > Cheers, > David > From adinn at redhat.com Thu Mar 28 11:28:17 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 Mar 2019 11:28:17 +0000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: <22ea4fe9-3d3b-b9ee-d759-3cc7764e40d0@redhat.com> On 28/03/2019 11:22, David Holmes wrote: > On 28/03/2019 8:32 pm, Thomas St?fe wrote: >> If you provide a backward compatibility switch which is not well >> tested, the coding behind it may bitrot; then, when you want to use >> it, you would run into errors. That is worse than not having that switch. > > AFAIK we don't actively test this code currently, so in that sense it > can bitrot even without the flag. Serguei can correct me if I am wrong > here. I believe Serguei's spec suggested deprecation of the compatibility feature from the get go. So, this means the outcome is down to a race between the bit-rot and the deprecation axe. If bit-rot wins then isn't that simply the deprecation axe swinging a tad earlier? (i.e. de facto deprecation rather than de jure :-). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From david.holmes at oracle.com Thu Mar 28 11:28:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2019 21:28:49 +1000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: <9f1552b1-0277-62b0-ae06-b772de2318be@oracle.com> On 28/03/2019 8:19 pm, Michael Rasmussen wrote: > It was my assumption that the reason adding private methods were allowed with redefineClass was to support adding/removing lambdas from method bodies, since javac converts those into private methods. IIUC it predates that and was added to support redefinition of native methods. > Removing this capability would remove this support. I would assume that would cause users a lot of headache, since from a user's point-of-view, they are just changing the method body, which should be supported! It will depend on how the user is generating the modified classfile bytes for the redefinition. And we certainly want to hear about such cases. David ----- > /Michael > > > From: serviceability-dev on behalf of David Holmes > Sent: 28 March 2019 12:10 > To: Thomas St?fe > Cc: serviceability-dev at openjdk.java.net; Coleen Phillimore > Subject: Re: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods > > > On 28/03/2019 4:55 pm, Thomas St?fe wrote: >> On Thu, Mar 28, 2019 at 8:40 AM David Holmes > > wrote: >> >> ???? Hi Thomas, >> >> ???? On 28/03/2019 5:02 pm, Thomas St?fe wrote: >> ????? > Hi Serguei, >> ????? > >> ????? > This is planned to be introduced in jdk 13? >> ????? > >> ????? > The only concern I have is that both paths (old and new behavior) >> ???? should >> ????? > be well tested, and hiding the old behavior behind an optional >> ???? switch >> ????? > may reduce its test coverage considerably. >> >> ???? The old behaviour is hardly ever used - I'm not even sure we currently >> ???? have a test that tries to use it - so it's already not "well tested" >> ???? and >> ???? there's no intent here of increasing test coverage for the code we plan >> ???? to remove. The new path will be tested as we do have a test that >> ???? expects >> ???? to get the error. And Serguei will of course have a simple test that >> ???? checks the flag with both values. >> >> >> I remember at least one case causing crashes in our code base where the >> method ordering array was not reordered on RedefineClasses. May have >> been this one: JDK-8149743. >> >> My point is, I have seen crashes in the field coming from bytecode >> agents redefining classes with method added or substracted, so it is no >> theoretical problem. > > My point is that we don't really care if the code works well or not, > we're intending to kill it off not improve it. It's a capability that > really should never have snuck in to the code. > > Cheers, > David > >> Cheers Thomas >> >> >> ???? Cheers, >> ???? David >> >> >> ????? > Cheers, Thomas >> ????? > >> ????? > (p.s. html format does not work well with the OpenJDK mailing list >> ????? > archive, see >> ????? > >> ???? https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027612.html) >> ????? > >> ????? > On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com >> ???? >> ????? > > ???? > > ???? >> ????? > > ???? >> wrote: >> ????? > >> ????? >? ? ?Hi All, >> ????? > >> ????? >? ? ?This is request for comments and potentially reviews for the >> ????? >? ? ?following CSR: >> ????? > https://bugs.openjdk.java.net/browse/JDK-8221528 >> ????? > >> ????? > >> ????? >? ? ?*Problem* >> ????? > >> ????? >? ? ?Now, the implementation of JVMTI RedefineClasses and >> ????? >? ? ?RetransformClasses allows to >> ????? >? ? ?add/delete private static and private final instance methods >> ???? in the >> ????? >? ? ?new class versions. >> ????? > >> ????? >? ? ?It means that current implementation does not follow the JVM >> ???? TI spec >> ????? >? ? ?which explicitly states: >> ????? > >> ????? >? ? ?"The redefinition must not add, remove or rename fields or >> ???? methods, >> ????? >? ? ?change the signatures >> ????? >? ? ? ?of methods, change modifiers, or change inheritance." >> ????? > >> ????? >? ? ?For details, please, see the spec: >> ????? > >> ????? > >> ???? https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses >> ????? > >> ???? https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses >> ????? > >> ????? >? ? ?The decision was made to align the implementation with the spec. >> ????? >? ? ?For reference, please, see the >> ????? > https://bugs.openjdk.java.net/browse/JDK-8192936. >> ????? > >> ????? >? ? ?This decision is going to cause some inconveniences to the >> ???? customers. >> ????? > >> ????? > >> ????? >? ? ?*Solution* >> ????? > >> ????? >? ? ?The solution is to introduce a compatibility mode with new >> ????? >? ? ?command-line VM option: >> ????? >? ? ? ?? -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods >> ????? > >> ????? >? ? ?New option will enable old behavior and allow the JVM TI >> ????? >? ? ?RedefineClasses and RetransformClasses >> ????? >? ? ?to add/delete private static and private final instance >> ???? methods in >> ????? >? ? ?the new class versions. >> ????? >? ? ?Without this option the old behavior will be disabled. >> ????? > >> ????? >? ? ?New option is deprecated right away. >> ????? >? ? ?The plan is to keep it for a couple of releases to allow >> ???? customers >> ????? >? ? ?(tool vendors) >> ????? >? ? ?to remove dependency on old behavior from their tools. >> ????? > >> ????? >? ? ?Thanks, >> ????? >? ? ?Serguei >> ????? > >> > > From Alan.Bateman at oracle.com Thu Mar 28 11:36:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 11:36:56 +0000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: <7d8b25bd-077a-00ed-cb02-61ff365347e7@oracle.com> On 28/03/2019 10:19, Michael Rasmussen wrote: > It was my assumption that the reason adding private methods were allowed with redefineClass was to support adding/removing lambdas from method bodies, since javac converts those into private methods. > It came about in JDK 6 as part of the effort to instrument native methods. The intention, in Java SE 6, was to provide a way for JVM TI and java agents to wrap native methods at load time. The SetNativeMethodPrefix function in the JVM TI spec documents this feature. Somehow, there was an attempt to get do the equivalent for late binding agents but that has massive implications, not just the JVM TI spec, but to wide areas of the platform. I see the VM option as a pragmatic approach to allow the mistake be removed over time and to give time for agent writers that might be using this to show up with their use-cases if it's anything other than instrumenting native methods. -Alan From Michael.Rasmussen at roguewave.com Thu Mar 28 12:25:41 2019 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Thu, 28 Mar 2019 12:25:41 +0000 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <9f1552b1-0277-62b0-ae06-b772de2318be@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> , <9f1552b1-0277-62b0-ae06-b772de2318be@oracle.com> Message-ID: >> Removing this capability would remove this support. I would assume that would cause users a lot of headache, since from a user's point-of-view, they are just changing the method body, which should be supported! > It will depend on how the user is generating the modified classfile > bytes for the redefinition. And we certainly want to hear about such cases. > David While I don't have any metrics readily available to back up my claim, my assumption is that users debugging their application via their IDE (be that IntelliJ IDEA, Eclipse, NetBeans, etc), and using its built-in support to recompile and redefine classes, would be one of the biggest use-cases for redefineClass and the adding/removing of private methods due to changing lambdas in method bodies. IDEs generally javac or ecj, or something derived from that, to do the compilation, to generate the bytes to redefine. Many users are aware of the limitations that you cannot add/remove members of a class (many using tools like JRebel to overcome those limitations), but I doubt many realize that adding/changing a lambda in a method does exactly this! Removing the capability of adding/removing private methods would thus have an impact on these users. /Michael From gary.adams at oracle.com Thu Mar 28 14:44:54 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 28 Mar 2019 10:44:54 -0400 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> Message-ID: <5C9CDDE6.90608@oracle.com> Is there any documentation that needs to be updated along with the impl changes? Would it make sense to support the preference properties? java.net.preferIPv4Stack java.net.preferIPv6Addresses Will the previous jdwp tests run with IPv6 or just the new additions? Should probably have reviewers with networking expertise. core-libs(?) Do we know if IPv6 is enabled in our test infrastructure? A stray "printf" statement in the initial webrev. socketTransport.c On 3/27/19, 7:04 PM, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8184770 > webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/ > > Main changes are in socketTransport.c - the code is updated to support > both IPv4 and IPv6. > Some details to simplify reviewing: > - listening: > - if IP address is specified (like 127.0.0.1 or ::1), connector > listens only on this address; > - for backward compatibility if no address (or "localhost") is > specified, IPv4 is used (if supported by the host); > - if "*" is specified (means "listen on all local interfaces"), dual > mode socket is used to listen on both IPv6 and IPv4 addresses; > - AllowedPeerInfo structure (for "allow" option) is updated to use > IPv6 address/mask, support for IPv4 is implemented by using "mapped" > IPv4 addresses; > - attaching: agent resolves and tries to connect to all (IPv4 and > IPv6) addresses, IPv4 are tried first; > > SocketListeningConnector.java/SocketTransportService.java are updated > to support IPv6 addresses (the addresses may contain colons); > > new JdwpAttachTest.java/JdwpListenTest.java test that listening and > attaching works for all available addresses (Ipv4 and IPv6) > > BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it > tests "allow" functionality), tests for mask (prefix length) > functionality are added (for both IPv4 and IPv6); > > --alex From Alan.Bateman at oracle.com Thu Mar 28 14:49:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Mar 2019 14:49:37 +0000 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <5C9CDDE6.90608@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> Message-ID: <23217d1c-8f13-0f5f-1f89-a7dd3761fb59@oracle.com> On 28/03/2019 14:44, Gary Adams wrote: > Is there any documentation that needs to be updated along with the > impl changes? > > Would it make sense to support the preference properties? > ? java.net.preferIPv4Stack > ? java.net.preferIPv6Addresses > > Will the previous jdwp tests run with IPv6 or just the new additions? > > Should probably have reviewers with networking expertise. core-libs(?) Maybe include net-dev as this is mostly about socket transport rather than anything debugger specific. -Alan From mark.reinhold at oracle.com Thu Mar 28 15:12:40 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 28 Mar 2019 08:12:40 -0700 Subject: OpenJDK Governing Board CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: <2862612d-74a4-4fb4-a51d-98be3beababd@default> References: <243a5f3a-61d0-4481-b41c-c94bd6a55d26@default> <2862612d-74a4-4fb4-a51d-98be3beababd@default> Message-ID: <20190328081240.890383717@eggemoggin.niobe.net> 2019/3/27 17:21:14 -0700, iris.clark at oracle.com: >> To: gb-discuss at openjdk.java.net >> Date: Tuesday, March 12, 2019 11:00 PM >> >> Serguei Spitsyn was voted in as the new Lead of the >> Serviceability Group [1]. >> >> Governing Board members: Please vote on whether to ratify this change >> as required by the Bylaws [2]. Votes are due in two weeks, by 23:00 >> UTC on Wednesday, 27 March 2019. Votes must be cast in the open by >> replying to this message. >> >> For Simple Majority voting instructions, see [3]. >> >> Iris >> >> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021205.html >> [2] https://openjdk.java.net/bylaws#group-lead > > Thank you for your votes. A majority has voted in favor of ratification. > Serguei Spitsyn is now the Lead of the Serviceability Group. So recorded. - Mark From bob.vandette at oracle.com Thu Mar 28 15:37:53 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 28 Mar 2019 11:37:53 -0400 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> Message-ID: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Sorry for the delay. The update looks good. Bob. > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >> Could you maybe combine subsystem_file_contents with subsystem_file_line_contents >> by adding an additional argument? > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > Thanks, > Severin > From sgehwolf at redhat.com Thu Mar 28 15:59:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Mar 2019 16:59:22 +0100 Subject: RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Message-ID: <014ebe0ced3e94cd5563e19e87a337f686338248.camel@redhat.com> On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > Sorry for the delay. The update looks good. Thanks for the review, Bob. Any other Reviewer(s)? Thanks, Severin > Bob. > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > by adding an additional argument? > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > Thanks, > > Severin > > From coleen.phillimore at oracle.com Thu Mar 28 17:14:11 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 28 Mar 2019 13:14:11 -0400 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> Message-ID: <87115f7b-fc66-b66d-9c59-ac4862585d67@oracle.com> On 3/28/19 7:22 AM, David Holmes wrote: > On 28/03/2019 8:32 pm, Thomas St?fe wrote: >> On Thu, Mar 28, 2019 at 11:10 AM David Holmes >> > wrote: >> >> ??? On 28/03/2019 4:55 pm, Thomas St?fe wrote: >> ???? > On Thu, Mar 28, 2019 at 8:40 AM David Holmes >> ??? >> ???? > > ??? >> wrote: >> ???? > >> ???? >? ? ?Hi Thomas, >> ???? > >> ???? >? ? ?On 28/03/2019 5:02 pm, Thomas St?fe wrote: >> ???? >? ? ? > Hi Serguei, >> ???? >? ? ? > >> ???? >? ? ? > This is planned to be introduced in jdk 13? >> ???? >? ? ? > >> ???? >? ? ? > The only concern I have is that both paths (old and new >> ??? behavior) >> ???? >? ? ?should >> ???? >? ? ? > be well tested, and hiding the old behavior behind an >> optional >> ???? >? ? ?switch >> ???? >? ? ? > may reduce its test coverage considerably. >> ???? > >> ???? >? ? ?The old behaviour is hardly ever used - I'm not even sure we >> ??? currently >> ???? >? ? ?have a test that tries to use it - so it's already not "well >> ??? tested" >> ???? >? ? ?and >> ???? >? ? ?there's no intent here of increasing test coverage for the >> ??? code we plan >> ???? >? ? ?to remove. The new path will be tested as we do have a >> test that >> ???? >? ? ?expects >> ???? >? ? ?to get the error. And Serguei will of course have a simple >> ??? test that >> ???? >? ? ?checks the flag with both values. >> ???? > >> ???? > >> ???? > I remember at least one case causing crashes in our code base >> ??? where the >> ???? > method ordering array was not reordered on RedefineClasses. >> May have >> ???? > been this one: JDK-8149743. >> ???? > >> ???? > My point is, I have seen crashes in the field coming from >> bytecode >> ???? > agents redefining classes with method added or substracted, so it >> ??? is no >> ???? > theoretical problem. >> >> ??? My point is that we don't really care if the code works well or not, >> ??? we're intending to kill it off not improve it. It's a capability >> that >> ??? really should never have snuck in to the code. >> >> >> If you provide a backward compatibility switch which is not well >> tested, the coding behind it may bitrot; then, when you want to use >> it, you would run into errors. That is worse than not having that >> switch. > > AFAIK we don't actively test this code currently, so in that sense it > can bitrot even without the flag. Serguei can correct me if I am wrong > here. This is not true.? We do actively test this code and I've personally fixed many bugs in this.? We will continue to have the tests we have now, with the option, to provide continued support until the option is removed. Thanks, Coleen > > David > ----- > >> Jdk head development goes at quite a pace, the chance that something >> which is not tested well bitrots is not that absurd. >> >> I am not idly bike shedding. I remember distinctly running into >> problems associated with RedefineClasses method adding/removal (I >> even remember us talking about it). So I know this is a thing which >> can happen. I do not want to improve it but I would like it to >> reliably work for as long as this switch exists. >> >> Cheers, Thomas >> >> ??? Cheers, >> ??? David >> From serguei.spitsyn at oracle.com Thu Mar 28 20:03:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Mar 2019 13:03:27 -0700 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: <87115f7b-fc66-b66d-9c59-ac4862585d67@oracle.com> References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> <8f09802f-1eda-55c2-25f3-cbbe949be62a@oracle.com> <30eea1b4-7703-3261-33a2-20bafb892f20@oracle.com> <87115f7b-fc66-b66d-9c59-ac4862585d67@oracle.com> Message-ID: On 3/28/19 10:14, coleen.phillimore at oracle.com wrote: > > > On 3/28/19 7:22 AM, David Holmes wrote: >> On 28/03/2019 8:32 pm, Thomas St?fe wrote: >>> On Thu, Mar 28, 2019 at 11:10 AM David Holmes >>> > wrote: >>> >>> ??? On 28/03/2019 4:55 pm, Thomas St?fe wrote: >>> ???? > On Thu, Mar 28, 2019 at 8:40 AM David Holmes >>> ??? >>> ???? > >> ??? >> wrote: >>> ???? > >>> ???? >? ? ?Hi Thomas, >>> ???? > >>> ???? >? ? ?On 28/03/2019 5:02 pm, Thomas St?fe wrote: >>> ???? >? ? ? > Hi Serguei, >>> ???? >? ? ? > >>> ???? >? ? ? > This is planned to be introduced in jdk 13? >>> ???? >? ? ? > >>> ???? >? ? ? > The only concern I have is that both paths (old and new >>> ??? behavior) >>> ???? >? ? ?should >>> ???? >? ? ? > be well tested, and hiding the old behavior behind an >>> optional >>> ???? >? ? ?switch >>> ???? >? ? ? > may reduce its test coverage considerably. >>> ???? > >>> ???? >? ? ?The old behaviour is hardly ever used - I'm not even sure we >>> ??? currently >>> ???? >? ? ?have a test that tries to use it - so it's already not "well >>> ??? tested" >>> ???? >? ? ?and >>> ???? >? ? ?there's no intent here of increasing test coverage for the >>> ??? code we plan >>> ???? >? ? ?to remove. The new path will be tested as we do have a >>> test that >>> ???? >? ? ?expects >>> ???? >? ? ?to get the error. And Serguei will of course have a simple >>> ??? test that >>> ???? >? ? ?checks the flag with both values. >>> ???? > >>> ???? > >>> ???? > I remember at least one case causing crashes in our code base >>> ??? where the >>> ???? > method ordering array was not reordered on RedefineClasses. >>> May have >>> ???? > been this one: JDK-8149743. >>> ???? > >>> ???? > My point is, I have seen crashes in the field coming from >>> bytecode >>> ???? > agents redefining classes with method added or substracted, >>> so it >>> ??? is no >>> ???? > theoretical problem. >>> >>> ??? My point is that we don't really care if the code works well or >>> not, >>> ??? we're intending to kill it off not improve it. It's a capability >>> that >>> ??? really should never have snuck in to the code. >>> >>> >>> If you provide a backward compatibility switch which is not well >>> tested, the coding behind it may bitrot; then, when you want to use >>> it, you would run into errors. That is worse than not having that >>> switch. >> >> AFAIK we don't actively test this code currently, so in that sense it >> can bitrot even without the flag. Serguei can correct me if I am >> wrong here. > > This is not true.? We do actively test this code and I've personally > fixed many bugs in this.? We will continue to have the tests we have > now, with the option, to provide continued support until the option is > removed. Yes, I'd like to confirm that we are going to test the switch with the tests we have now. But we already discovered a couple of holes that we are not going to fix. Thanks, Serguei > Thanks, > Coleen > >> >> David >> ----- >> >>> Jdk head development goes at quite a pace, the chance that something >>> which is not tested well bitrots is not that absurd. >>> >>> I am not idly bike shedding. I remember distinctly running into >>> problems associated with RedefineClasses method adding/removal (I >>> even remember us talking about it). So I know this is a thing which >>> can happen. I do not want to improve it but I would like it to >>> reliably work for as long as this switch exists. >>> >>> Cheers, Thomas >>> >>> ??? Cheers, >>> ??? David >>> > From serguei.spitsyn at oracle.com Thu Mar 28 20:27:15 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Mar 2019 13:27:15 -0700 Subject: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods In-Reply-To: References: <00672615-6a02-31a8-bc88-5982e495e777@oracle.com> Message-ID: <5f818253-7971-2ab2-1205-5025f33546ca@oracle.com> Hi Volker, On 3/28/19 03:15, David Holmes wrote: > Hi Volker, > > On 28/03/2019 5:54 pm, Volker Simonis wrote: >> Hi Serguei, >> >> can you please detail a little bit on the reasons why you finally >> decided to change the implementation to conform to the spec instead of >> just updating the spec to endorse a behavior which is there since >> quite some time? > > The behaviour that has been there "quite some time" only actually > works for very limited usecases. In trying to legitimise the > capability and allow you to add/remove private methods we encountered > an ever increasing spiral of complexity in trying to establish > meaningful semantics. Is it physically possible to implement this? > Yes. It is worth the cost in complexity and maintenance? We concluded > not. > > We should try to produce a better summary of all the issues. Thanks, David, for replying to this question. I agree, we have to provide a better summary of all the issues we discovered. Shortly, the capability to allow to add/remove private methods has non-local impact on VM mechanisms such as nestmates, methods resolution, MethodHandle's and reflection. The red flag is that we were looping in discovering more problems than were initially expected. Yes, fixing those is doable but will introduce extra complexity and maintenance cost. We concluded that it is not worth it. > Cheers, > David > >> I read trough the comment thread of "JDK-8192936" and it seems to me >> that right until your last comment from today, the general conses has >> been to change the specs rather than the implementation. I understand >> from the various comments in that issue that changing the specs is not >> trivial but still doable. Unfortunately, some of the referenced >> material in that issue is not available outside Oracle (i.e. >> wiki.se.oracle.com) - it would be nice if you could make these >> information available in the OpenJDK wiki or somewhere else. >> >> I think that adding private methods is a feature widely used by a lot >> of tools and removing it will break them. Deprecating this feature in >> a non-LTS release and removing it after "a couple" of (non-LTS) >> releases won't help a lot because many productive systems won't use >> these releases anyway. This is interesting point. We may need to think a little bit more on this. Thank you for your questions and concerns! It is what we hoped for. Thanks, Serguei >> Thank you and best regards, >> Volker >> >> On Thu, Mar 28, 2019 at 1:57 AM serguei.spitsyn at oracle.com >> wrote: >>> >>> Hi All, >>> >>> This is request for comments and potentially reviews for the >>> following CSR: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8221528 >>> >>> >>> Problem >>> >>> Now, the implementation of JVMTI RedefineClasses and >>> RetransformClasses allows to >>> add/delete private static and private final instance methods in the >>> new class versions. >>> >>> It means that current implementation does not follow the JVM TI spec >>> which explicitly states: >>> >>> "The redefinition must not add, remove or rename fields or methods, >>> change the signatures >>> ? of methods, change modifiers, or change inheritance." >>> >>> For details, please, see the spec: >>> >>> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RedefineClasses >>> >>> https://docs.oracle.com/en/java/javase/12/docs/specs/jvmti.html#RetransformClasses >>> >>> >>> The decision was made to align the implementation with the spec. >>> For reference, please, see the >>> https://bugs.openjdk.java.net/browse/JDK-8192936. >>> >>> This decision is going to cause some inconveniences to the customers. >>> >>> >>> Solution >>> >>> The solution is to introduce a compatibility mode with new >>> command-line VM option: >>> ??? -XX:{+|-}AllowRedefinitionToAddOrDeleteMethods >>> >>> New option will enable old behavior and allow the JVM TI >>> RedefineClasses and RetransformClasses >>> to add/delete private static and private final instance methods in >>> the new class versions. >>> Without this option the old behavior will be disabled. >>> >>> New option is deprecated right away. >>> The plan is to keep it for a couple of releases to allow customers >>> (tool vendors) >>> to remove dependency on old behavior from their tools. >>> >>> Thanks, >>> Serguei From christoph.langer at sap.com Fri Mar 29 09:10:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 29 Mar 2019 09:10:29 +0000 Subject: RFR(XS): 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g In-Reply-To: References: <02887333-8901-c993-fc22-11d0e832571f@arm.com> <93c2f273-b210-3b53-fba6-31247c035d7e@arm.com> Message-ID: Hi Nick, this is great, thank you for fixing this, +1?? We ran into the same problem when we were trying to set different default Xmx options in our test infrastructure for small machines where the default heaps would be too small by default. My colleague Arno had the very same patch on his ToDo list already. Best regards Christoph > -----Original Message----- > From: serviceability-dev On > Behalf Of Nick Gasson > Sent: Mittwoch, 27. M?rz 2019 04:20 > To: Sharath Ballal ; serviceability- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8220707: [TESTBUG] > serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg - > vmoption:-Xmx < 8g > > Hi, > > Could I get another reviewer to look at this please? > > Thanks! > Nick > > > On 18/03/2019 18:04, Nick Gasson wrote: > > Hi Sharath, > > > > On 15/03/2019 23:32, Sharath Ballal wrote: > >> > >> Fix looks good.? How have you tested it ? > > > > I ran the test using the "make test" target with and without > > JTREG="MAX_MEM=512m" on AArch64 and x86. Previously it would fail > with > > that argument. > > > > Thanks, > > Nick From erik.osterlund at oracle.com Fri Mar 29 13:39:23 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 29 Mar 2019 14:39:23 +0100 Subject: RFR (M) 8221183: Avoid code cache walk in MetadataOnStackMark In-Reply-To: References: Message-ID: <780ddef6-9af2-7fdb-abf0-93c4680f9a08@oracle.com> Hi Coleen, Seems like the recreate_old_table() should be called reset_old_table() as it does not really create anything. The CodeCache::mark_all_nmethods_for_deoptimization function seems like a general facility. I don't think I like passing in a boolean if class redefinition-specific stuff should be done in there or not. It's a very small method that just iterates over the nmethods. I'd rather duplicate that while loop in a new function and have the class redefinition logic be separate. Otherwise this looks good! Thanks, /Erik On 2019-03-27 14:09, coleen.phillimore at oracle.com wrote: > Summary: Note nmethods with "old" Methods in them in table to walk instead. > > See RFE for more details.? Tested with RedefineClasses tests > with/without -Xcomp, mach5 tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8221183.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8221183 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Mar 29 14:54:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 29 Mar 2019 10:54:02 -0400 Subject: RFR (M) 8221183: Avoid code cache walk in MetadataOnStackMark In-Reply-To: <780ddef6-9af2-7fdb-abf0-93c4680f9a08@oracle.com> References: <780ddef6-9af2-7fdb-abf0-93c4680f9a08@oracle.com> Message-ID: Hi Erik, Thank you for reviewing this! On 3/29/19 9:39 AM, Erik ?sterlund wrote: > Hi Coleen, > > Seems like the recreate_old_table() should be called reset_old_table() > as it does not really create anything. > I can change the name.? I guess the table isn't old but the methods are.? So I could call it reset_old_method_table instead. > The CodeCache::mark_all_nmethods_for_deoptimization function seems > like a general facility. I don't think I like passing in a boolean if > class redefinition-specific stuff should be done in there or not. It's > a very small method that just iterates over the nmethods. I'd rather > duplicate that while loop in a new function and have the class > redefinition logic be separate. > Yes, I could do this too.? I hate passing a boolean to a function to do something different.? Sort of implies one should write a different function in the first place. Thanks! Coleen > Otherwise this looks good! > > Thanks, > /Erik > > On 2019-03-27 14:09, coleen.phillimore at oracle.com wrote: >> Summary: Note nmethods with "old" Methods in them in table to walk >> instead. >> >> See RFE for more details.? Tested with RedefineClasses tests >> with/without -Xcomp, mach5 tier1-5. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8221183.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8221183 >> >> Thanks, >> Coleen From gary.adams at oracle.com Fri Mar 29 17:12:33 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 29 Mar 2019 13:12:33 -0400 Subject: LingeredApp termination sequence Message-ID: <5C9E5201.4090106@oracle.com> While running some bulk testing on jdk/sun/tools I've come across some errors reported from the termination sequence for LingeredApp debuggee process. The main process creates a locking file, which the LingeredApp sits in a loop updating the file modification date. When the main test completes it stops the LingeredApp by removing the file. The clean exit results when LingeredApp gets a NoSuchFileException. I see a number of bugs filed that are getting a raw IOException on the LingeredApp termination. I'm going to attempt to get more specific information about the IOException. diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java b/test/lib/jdk/test/lib/apps/LingeredApp.java --- a/test/lib/jdk/test/lib/apps/LingeredApp.java +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java @@ -504,6 +504,9 @@ } catch (NoSuchFileException ex) { // Lock deleted while we are setting last modified time. // Ignore error and lets the app exits + } catch (IOException ioe) { + ioe.printStackTrace(); + System.exit(3); } catch (Exception ex) { System.err.println("LingeredApp ERROR: " + ex); // Leave exit_code = 1 to Java launcher Since the error is being detected as the test is terminating, I think it would be possible to simply replace the NoSuchFileException, and consider an IOException as the trigger for the clean exit sequence. Anyone have experience with this corner of the swamp? From daniel.daugherty at oracle.com Fri Mar 29 17:47:08 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Mar 2019 13:47:08 -0400 Subject: LingeredApp termination sequence In-Reply-To: <5C9E5201.4090106@oracle.com> References: <5C9E5201.4090106@oracle.com> Message-ID: <49ae012e-36d1-f9aa-3f47-cf47c3c743fa@oracle.com> Adding Dmitri to this thread... I believe LingeredApp was a Dmitri Samersoff creation. Although he has left Oracle, he still participates in OpenJDK stuff... Dan On 3/29/19 1:12 PM, Gary Adams wrote: > While running some bulk testing on jdk/sun/tools I've > come across some errors reported from the termination sequence > for LingeredApp debuggee process. > > The main process creates a locking file, which the LingeredApp > sits in a loop updating the file modification date. When the main > test completes it stops the LingeredApp by removing the file. > > The clean exit results when LingeredApp gets a NoSuchFileException. > I see a number of bugs filed that are getting a raw IOException > on the LingeredApp termination. > > I'm going to attempt to get more specific information about the > IOException. > > diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java > b/test/lib/jdk/test/lib/apps/LingeredApp.java > --- a/test/lib/jdk/test/lib/apps/LingeredApp.java > +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java > @@ -504,6 +504,9 @@ > ???????? } catch (NoSuchFileException ex) { > ???????????? // Lock deleted while we are setting last modified time. > ???????????? // Ignore error and lets the app exits > +??????? } catch (IOException ioe) { > +??????????? ioe.printStackTrace(); > +??????????? System.exit(3); > ???????? } catch (Exception ex) { > ???????????? System.err.println("LingeredApp ERROR: " + ex); > ???????????? // Leave exit_code = 1 to Java launcher > > Since the error is being detected as the test is terminating, > I think it would be possible to simply replace the NoSuchFileException, > and consider an IOException as the trigger for the clean exit sequence. > > Anyone have experience with this corner of the swamp? > From gary.adams at oracle.com Fri Mar 29 18:12:01 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 29 Mar 2019 14:12:01 -0400 Subject: RFR: JDK-8221694: jstatLineCounts1 needs to be NaN resilient Message-ID: <5C9E5FF1.60804@oracle.com> With additional testing of jdk/sun/tools The problem seen previously with lineCounts3 and lineCounts4 has begun to appear in lineCounts1. To complete the set this changset will also invlude the same fix for lineCounts2. e.g. allow floating point or NaN dash ("-") in the metaspace column ([0-9]+\.[0-9]+|-) Issue: https://bugs.openjdk.java.net/browse/JDK-8221694 diff --git a/test/jdk/sun/tools/jstat/lineCounts1.awk b/test/jdk/sun/tools/jstat/lineCounts1.awk --- a/test/jdk/sun/tools/jstat/lineCounts1.awk +++ b/test/jdk/sun/tools/jstat/lineCounts1.awk @@ -18,7 +18,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { datalines++; } diff --git a/test/jdk/sun/tools/jstat/lineCounts2.awk b/test/jdk/sun/tools/jstat/lineCounts2.awk --- a/test/jdk/sun/tools/jstat/lineCounts2.awk +++ b/test/jdk/sun/tools/jstat/lineCounts2.awk @@ -14,7 +14,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { datalines++; } From chris.plummer at oracle.com Fri Mar 29 18:47:05 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 29 Mar 2019 11:47:05 -0700 Subject: RFR: JDK-8221694: jstatLineCounts1 needs to be NaN resilient In-Reply-To: <5C9E5FF1.60804@oracle.com> References: <5C9E5FF1.60804@oracle.com> Message-ID: <1e8f9494-6e1f-ba65-218c-79be579de455@oracle.com> Looks good. Chris On 3/29/19 11:12 AM, Gary Adams wrote: > With additional testing of jdk/sun/tools The problem seen previously with > lineCounts3 and lineCounts4 has begun to appear in lineCounts1. To > complete > the set this changset will also invlude the same fix for lineCounts2. > e.g. allow floating point or NaN dash ("-") in the metaspace column > ???? ([0-9]+\.[0-9]+|-) > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8221694 > > > > diff --git a/test/jdk/sun/tools/jstat/lineCounts1.awk > b/test/jdk/sun/tools/jstat/lineCounts1.awk > --- a/test/jdk/sun/tools/jstat/lineCounts1.awk > +++ b/test/jdk/sun/tools/jstat/lineCounts1.awk > @@ -18,7 +18,7 @@ > ???????? headerlines++; > ???? } > > -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { > +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ > ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { > ???????? datalines++; > ???? } > > diff --git a/test/jdk/sun/tools/jstat/lineCounts2.awk > b/test/jdk/sun/tools/jstat/lineCounts2.awk > --- a/test/jdk/sun/tools/jstat/lineCounts2.awk > +++ b/test/jdk/sun/tools/jstat/lineCounts2.awk > @@ -14,7 +14,7 @@ > ???????? headerlines++; > ???? } > > -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { > +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ > ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/??? { > ???????? datalines++; > ???? } From jcbeyler at google.com Fri Mar 29 18:48:51 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 29 Mar 2019 11:48:51 -0700 Subject: RFR: JDK-8221694: jstatLineCounts1 needs to be NaN resilient In-Reply-To: <5C9E5FF1.60804@oracle.com> References: <5C9E5FF1.60804@oracle.com> Message-ID: Hi Gary, Looks good to me :) Jc On Fri, Mar 29, 2019 at 11:14 AM Gary Adams wrote: > With additional testing of jdk/sun/tools The problem seen previously with > lineCounts3 and lineCounts4 has begun to appear in lineCounts1. To complete > the set this changset will also invlude the same fix for lineCounts2. > e.g. allow floating point or NaN dash ("-") in the metaspace column > ([0-9]+\.[0-9]+|-) > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221694 > > > > diff --git a/test/jdk/sun/tools/jstat/lineCounts1.awk > b/test/jdk/sun/tools/jstat/lineCounts1.awk > --- a/test/jdk/sun/tools/jstat/lineCounts1.awk > +++ b/test/jdk/sun/tools/jstat/lineCounts1.awk > @@ -18,7 +18,7 @@ > headerlines++; > } > > -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { > +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { > datalines++; > } > > diff --git a/test/jdk/sun/tools/jstat/lineCounts2.awk > b/test/jdk/sun/tools/jstat/lineCounts2.awk > --- a/test/jdk/sun/tools/jstat/lineCounts2.awk > +++ b/test/jdk/sun/tools/jstat/lineCounts2.awk > @@ -14,7 +14,7 @@ > headerlines++; > } > > -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { > +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ > ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { > datalines++; > } > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Mar 29 19:06:35 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Mar 2019 12:06:35 -0700 Subject: RFR (M) 8221183: Avoid code cache walk in MetadataOnStackMark In-Reply-To: References: Message-ID: <8970aca2-faa7-268e-6043-a7a269af4706@oracle.com> An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Mar 29 21:53:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 29 Mar 2019 17:53:49 -0400 Subject: RFR (M) 8221183: Avoid code cache walk in MetadataOnStackMark In-Reply-To: <8970aca2-faa7-268e-6043-a7a269af4706@oracle.com> References: <8970aca2-faa7-268e-6043-a7a269af4706@oracle.com> Message-ID: <8714487a-c2a8-0b07-e7fb-7b43dbc2c090@oracle.com> Serguei, Thank you for reviewing. On 3/29/19 3:06 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good to me. > I agree with Erik on reset_old_table(). > > I have one question. > > http://cr.openjdk.java.net/~coleenp/2019/8221183.01/webrev/src/hotspot/share/code/codeCache.cpp.frames.html > Yes, I changed it to reset_old_method_table. > 1077 void CodeCache::mark_for_evol_deoptimization(InstanceKlass* > dependee) { > *1078 MutexLockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);* > 1079 > 1080 // Mark dependent AOT nmethods, which are only found via the class redefined. > 1081 // TODO: add dependencies to aotCompiledMethod's metadata section > so this isn't > 1082 // needed. > 1083 AOTLoader::mark_evol_dependent_methods(dependee); > 1084 } > > Is it still necessary to grab the CodeCache_lock here? > It's actually not necessary because we're at a safepoint, and this code is always at a safepoint. I'll assert it's at a safepoint.? flush_evol_dependents has this: ? // --- Compile_lock is not held. However we are at a safepoint. ? assert_locked_or_safepoint(Compile_lock); Thanks, Coleen > > Thanks, > Serguei > > > On 3/27/19 06:09, coleen.phillimore at oracle.com wrote: >> Summary: Note nmethods with "old" Methods in them in table to walk >> instead. >> >> See RFE for more details.? Tested with RedefineClasses tests >> with/without -Xcomp, mach5 tier1-5. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8221183.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8221183 >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Mar 29 22:07:20 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 29 Mar 2019 15:07:20 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <5C9CDDE6.90608@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> Message-ID: <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> (added net-dev as suggested by Alan) Net gurus, please assist in reviewing socket-related code. New webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ On 03/28/2019 07:44, Gary Adams wrote: > Is there any documentation that needs to be updated along with the impl > changes? created an issue for this: https://bugs.openjdk.java.net/browse/JDK-8221707 > > Would it make sense to support the preference properties? > ? java.net.preferIPv4Stack > ? java.net.preferIPv6Addresses Done (with new test for the functionality) > > Will the previous jdwp tests run with IPv6 or just the new additions? many tests use "localhost" (or empty string which has the same meaning) address. localhost can be resolved to IPv4 or IPv6 address, but by default IPv4 is used. So IPv6 will be used only on IPv6-only systems. > > Should probably have reviewers with networking expertise. core-libs(?) > > Do we know if IPv6 is enabled in our test infrastructure? Accordingly the logs IPv6 stack is enabled, but no external IPv6 address is assigned (i.e. the only IPv6 address is loopback - ::1). This is enough for testing. > > A stray "printf" statement in the initial webrev. socketTransport.c fixed. --alex > > On 3/27/19, 7:04 PM, Alex Menkov wrote: >> Hi all, >> >> Please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8184770 >> webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/ >> >> Main changes are in socketTransport.c - the code is updated to support >> both IPv4 and IPv6. >> Some details to simplify reviewing: >> - listening: >> ? - if IP address is specified (like 127.0.0.1 or ::1), connector >> listens only on this address; >> ? - for backward compatibility if no address (or "localhost") is >> specified, IPv4 is used (if supported by the host); >> ? - if "*" is specified (means "listen on all local interfaces"), dual >> mode socket is used to listen on both IPv6 and IPv4 addresses; >> ? - AllowedPeerInfo structure (for "allow" option) is updated to use >> IPv6 address/mask, support for IPv4 is implemented by using "mapped" >> IPv4 addresses; >> - attaching: agent resolves and tries to connect to all (IPv4 and >> IPv6) addresses, IPv4 are tried first; >> >> SocketListeningConnector.java/SocketTransportService.java are updated >> to support IPv6 addresses (the addresses may contain colons); >> >> new JdwpAttachTest.java/JdwpListenTest.java test that listening and >> attaching works for all available addresses (Ipv4 and IPv6) >> >> BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it >> tests "allow" functionality), tests for mask (prefix length) >> functionality are added (for both IPv4 and IPv6); >> >> --alex > From aeubanks at google.com Sat Mar 30 00:06:43 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Fri, 29 Mar 2019 17:06:43 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: (one more time now that I'm subscribed to serviceability-dev) On Fri, Mar 29, 2019 at 5:03 PM Arthur Eubanks wrote: > We have some ipv6 patches as well in this area as well (as well as other > patches to support ipv6 only environments) that we're trying to upstream. I > don't understand the code myself, but it might be useful to take a look: > http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html > > On Fri, Mar 29, 2019 at 3:09 PM Alex Menkov > wrote: > >> (added net-dev as suggested by Alan) >> >> Net gurus, please assist in reviewing socket-related code. >> >> New webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >> >> >> On 03/28/2019 07:44, Gary Adams wrote: >> > Is there any documentation that needs to be updated along with the impl >> > changes? >> >> created an issue for this: >> https://bugs.openjdk.java.net/browse/JDK-8221707 >> >> > >> > Would it make sense to support the preference properties? >> > java.net.preferIPv4Stack >> > java.net.preferIPv6Addresses >> >> Done (with new test for the functionality) >> >> > >> > Will the previous jdwp tests run with IPv6 or just the new additions? >> >> many tests use "localhost" (or empty string which has the same meaning) >> address. localhost can be resolved to IPv4 or IPv6 address, but by >> default IPv4 is used. >> So IPv6 will be used only on IPv6-only systems. >> >> > >> > Should probably have reviewers with networking expertise. core-libs(?) >> > >> > Do we know if IPv6 is enabled in our test infrastructure? >> >> Accordingly the logs IPv6 stack is enabled, but no external IPv6 address >> is assigned (i.e. the only IPv6 address is loopback - ::1). This is >> enough for testing. >> >> > >> > A stray "printf" statement in the initial webrev. socketTransport.c >> >> fixed. >> >> --alex >> >> > >> > On 3/27/19, 7:04 PM, Alex Menkov wrote: >> >> Hi all, >> >> >> >> Please review the fix for >> >> https://bugs.openjdk.java.net/browse/JDK-8184770 >> >> webrev: >> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.00/ >> >> >> >> Main changes are in socketTransport.c - the code is updated to support >> >> both IPv4 and IPv6. >> >> Some details to simplify reviewing: >> >> - listening: >> >> - if IP address is specified (like 127.0.0.1 or ::1), connector >> >> listens only on this address; >> >> - for backward compatibility if no address (or "localhost") is >> >> specified, IPv4 is used (if supported by the host); >> >> - if "*" is specified (means "listen on all local interfaces"), dual >> >> mode socket is used to listen on both IPv6 and IPv4 addresses; >> >> - AllowedPeerInfo structure (for "allow" option) is updated to use >> >> IPv6 address/mask, support for IPv4 is implemented by using "mapped" >> >> IPv4 addresses; >> >> - attaching: agent resolves and tries to connect to all (IPv4 and >> >> IPv6) addresses, IPv4 are tried first; >> >> >> >> SocketListeningConnector.java/SocketTransportService.java are updated >> >> to support IPv6 addresses (the addresses may contain colons); >> >> >> >> new JdwpAttachTest.java/JdwpListenTest.java test that listening and >> >> attaching works for all available addresses (Ipv4 and IPv6) >> >> >> >> BasicJDWPConnectionTest.java was renamed to JdwpAllowTest.java (as it >> >> tests "allow" functionality), tests for mask (prefix length) >> >> functionality are added (for both IPv4 and IPv6); >> >> >> >> --alex >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at samersoff.net Sat Mar 30 13:46:44 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Sat, 30 Mar 2019 16:46:44 +0300 Subject: LingeredApp termination sequence In-Reply-To: <5C9E5201.4090106@oracle.com> References: <5C9E5201.4090106@oracle.com> Message-ID: <27b13316-90c8-80d1-d751-9db70249d166@samersoff.net> Hello Gary, The LingeredApp was designed to provide precise control over the life cycle of a subordinate process. This means that if the app exits unexpectedly, we should have detailed information why it happens. IOException may occur when the app tries to touch lockfile (e.g. due to a network filesystem error), so it might be better to catch IOException, then check if it is an instance of NoSuchFileException or the lockfile was deleted by driver. -Dmitry On 29.03.2019 20:12, Gary Adams wrote: > While running some bulk testing on jdk/sun/tools I've > come across some errors reported from the termination sequence > for LingeredApp debuggee process. > > The main process creates a locking file, which the LingeredApp > sits in a loop updating the file modification date. When the main > test completes it stops the LingeredApp by removing the file. > > The clean exit results when LingeredApp gets a NoSuchFileException. > I see a number of bugs filed that are getting a raw IOException > on the LingeredApp termination. > > I'm going to attempt to get more specific information about the > IOException. > > diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java > b/test/lib/jdk/test/lib/apps/LingeredApp.java > --- a/test/lib/jdk/test/lib/apps/LingeredApp.java > +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java > @@ -504,6 +504,9 @@ > ???????? } catch (NoSuchFileException ex) { > ???????????? // Lock deleted while we are setting last modified time. > ???????????? // Ignore error and lets the app exits > +??????? } catch (IOException ioe) { > +??????????? ioe.printStackTrace(); > +??????????? System.exit(3); > ???????? } catch (Exception ex) { > ???????????? System.err.println("LingeredApp ERROR: " + ex); > ???????????? // Leave exit_code = 1 to Java launcher > > Since the error is being detected as the test is terminating, > I think it would be possible to simply replace the NoSuchFileException, > and consider an IOException as the trigger for the clean exit sequence. > > Anyone have experience with this corner of the swamp? >