From ioi.lam at oracle.com Fri Apr 1 05:43:19 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 31 Mar 2016 22:43:19 -0700 Subject: RFR 8150607 - Clean up CompactHashtable Message-ID: <56FE0A77.6010604@oracle.com> Please review http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ Bug: Clean up CompactHashtable https://bugs.openjdk.java.net/browse/JDK-8150607 Summary of fix: [1] Instead of reading/writing the table bit-by-bit, which is tedious and error prone, use SimpleCompactHashtable::serialize(), which is more structural. [2] Split up the _buckets and _entries into two separate arrays, so the dumping and walking code is easier to understand (see comments above SimpleCompactHashtable declaration) These 2 arrays are now allocated from the RO region (used to be in RW) [3] Renamed a few things COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE (having something called "compact" in CompactHashtable is confusing) The old names "dump_table" (actually dumping the buckets) and "dump_buckets" (actually dumping the entries) were conflicting with terminology used elsewhere. Now the terminology is unified: "buckets" = the main index, "entries" = the second level. lookup_entry -> decode_entry (it wasn't doing any lookup) [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be checked with assert. [5] Replaced all juint to u4 (suggested by Coleen) [6] templatize the iterator (see CompactHashtable::symbols_do -> SimpleCompactHashtable::iterate) [7] I also added a test case using Serviceability Agent -- due to the lack of a regression test, the walking of the compact hashtable in SA had been broken for a while before it was fixed in JDK-8151368, so having a test case would make the code more maintainable. Tests: Hotspot JTREG tests Thanks - Ioi From cheleswer.sahu at oracle.com Fri Apr 1 06:10:17 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 31 Mar 2016 23:10:17 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56FD7B30.8020105@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC647.6020704@oracle.com> <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> <56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com> <56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com> <56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com> <56F4489D.10107@oracle.com> <56FD727B.1000209@oracle.com> <56FD7B30.8020105@oracle.com> Message-ID: Thanks Dmitry, Kevin for review. Regards, Cheleswer -----Original Message----- From: Kevin Walls Sent: Friday, April 01, 2016 1:02 AM To: Dmitry Samersoff; Cheleswer Sahu; Mattis Castegren; David Holmes; Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters Yes, looks good. 8-) On 31/03/2016 19:54, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me! (R) > > -Dmitry > > > On 2016-03-31 12:46, Cheleswer Sahu wrote: >> Hi , >> >> I would like to go with the "print_raw()" option as this can print >> any length of thread name. I have modified the code and written a >> test case also for this bug. Please review the code changes from the >> below link >> >> http://cr.openjdk.java.net/~csahu/8151442/webrev.01/ >> >> Regards, >> Cheleswer >> >> -----Original Message----- >> From: Mattis Castegren >> Sent: Wednesday, March 30, 2016 10:42 PM >> To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; >> Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Cc: Mattis Castegren >> Subject: RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation >> marks properly with threads' name greater than 1996 characters >> >> Hi >> >> It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name. >> >> I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are). >> >> I suggest we move ahead with the print_raw approach. >> >> If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kevin Walls >> Sent: den 24 mars 2016 21:06 >> To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; >> hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation >> marks properly with threads' name greater than 1996 characters >> >> >> Hi >> >> I didn't think of %.XXXXs when Cheleswer and I discussed this briefly. >> I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name. We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken. >> >> As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call. We might guess as low as 1024? >> >> (Retaining one st->print() also minimises any risk of concurrent >> prints jumbling up the output.) >> >> Thanks >> Kevin >> >> >> On 21/03/2016 21:24, David Holmes wrote: >>> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote: >>>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>>> I still see %.Ns as the simplest solution - but whatever. >>>>> It spreads artificial limitation of thread name length across >>>>> hotspot sources. >>>>> >>>>> Brief grepping[1] shows couple of other places with the same >>>>> problem and if some days we decide to change default O_BUFLEN, we >>>>> have to not forget to change .N value in couple of places as well. >>>> There should be a way to pass the precision value as a parameter >>>> instead of hardcoding it in the format string. Something like: >>>> >>>> sprintf("%.*s", precision_value, string); >>> Yes the length limit can be passed as a variable. But I think Dmitry >>> just wants to allow for unlimited lengths. Not sure how to achieve >>> that at the lowest level though as we need to avoid complex >>> allocations etc in these print routines. >>> >>> David >>> >>> >>>> Dan >>>> >>>>> 1. >>>>> ./share/vm/prims/jni.cpp >>>>> 673: "in thread \"%s\" ", thread->get_thread_name()); >>>>> >>>>> ./share/vm/runtime/thread.cpp >>>>> 1766: get_thread_profiler()->print(get_thread_name()); >>>>> 1974: get_thread_profiler()->print(get_thread_name()); >>>>> 2896: st->print("\"%s\" ", get_thread_name()); >>>>> 2926: st->print("%s", get_thread_name_string(buf, buflen)); >>>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, >>>>> buflen)); >>>>> >>>>> >>>>> ./share/vm/services/threadService.cpp >>>>> 882: ... st->print_cr("\"%s\":", >>>>> currentThread->get_thread_name()); >>>>> 919: ..."%s \"%s\"", owner_desc, >>>>> currentThread->get_thread_name()); >>>>> 932: ... st->print_cr("\"%s\":", >>>>> currentThread->get_thread_name()); >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2016-03-19 00:37, David Holmes wrote: >>>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote: >>>>>>> David, >>>>>>> >>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just >>>>>>>> add the desired precision value to the %s than to split into >>>>>>>> two print statements. Or bite the bullet now and make the >>>>>>>> length immaterial by breaking the name into chunks. It's as >>>>>>>> easy to fix as to write the RFE :) >>>>>>> For this particular case the simplest solution is to use print_raw: >>>>>>> >>>>>>> print_raw("\""\"); print_raw(get_thread_name()); >>>>>>> print_raw("\""\"); >>>>>> I still see %.Ns as the simplest solution - but whatever. >>>>>> >>>>>>> But as soon as print() finally ends up with: >>>>>>> >>>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ... >>>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output >>>>>>> truncated");) >>>>>>> >>>>>>> Complete fix should be something like: >>>>>>> >>>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if >>>>>>> (desired_size > O_BUFLEN) { >>>>>>> malloc >>>>>>> .... >>>>>>> } >>>>>>> >>>>>>> but it has performance penalty, so we should use some tricks to >>>>>>> cover most common %s/%d/%p cases. >>>>>> So you want to remove the internal limitation instead of have the >>>>>> clients deal with it? Not sure it is worth the effort - IIRC that >>>>>> code can be used at sensitive times hence the simple approach to >>>>>> buffer management. >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2016-03-18 15:51, David Holmes wrote: >>>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes >>>>>>>>> Sent: Friday, March 18, 2016 2:42 PM >>>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close >>>>>>>>> quotation marks properly with threads' name greater than 1996 >>>>>>>>> characters >>>>>>>>> >>>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the code changes for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442. >>>>>>>>>> >>>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/ >>>>>>>>>> >>>>>>>>>> Bug Brief: >>>>>>>>>> >>>>>>>>>> In jstack thread dumps , thread name greater than 1996 >>>>>>>>>> characters doesn't close quotation marks properly. >>>>>>>>> Anyone giving a thread a name that long deserves to get a core >>>>>>>>> dump! >>>>>>>>> ;-) >>>>>>>>> >>>>>>>>>> Problem Identified: >>>>>>>>>> >>>>>>>>>> Jstack is using below code to print thread name >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>>>>>>>>> void JavaThread::print_on(outputStream *st) const { >>>>>>>>>> >>>>>>>>>> st->print("\"%s\" ", get_thread_name()); >>>>>>>>>> >>>>>>>>>> Here "st->print()" internally uses max buffer length as >>>>>>>>>> O_BUFLEN (2000). >>>>>>>>>> >>>>>>>>>> void >>>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(co >>>>>>>>>> ns >>>>>>>>>> t >>>>>>>>>> char* format, va_list ap, bool add_cr) { >>>>>>>>>> >>>>>>>>>> char buffer[O_BUFLEN]; >>>>>>>>>> >>>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls >>>>>>>>>> "vsnprintf()" which truncates the anything greater >>>>>>>>>> than the max size(2000). In this case thread's name(> 1996) >>>>>>>>>> along with quotation marks (2) >>>>>>>>>> >>>>>>>>>> plus one terminating character exceeds the max buffer size >>>>>>>>>> (2000), therefore the closing quotation marks gets truncated. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> >>>>>>>>>> Split the "st->print("\"%s\" ", get_thread_name())" in two >>>>>>>>>> statements >>>>>>>>>> >>>>>>>>>> 1.st->print("\"%s", get_thread_name()); >>>>>>>>>> >>>>>>>>>> 2.st->print("\" "); >>>>>>>>>> >>>>>>>>>> This will ensure presence of closing quotation mark always. >>>>>>>>> Can't we just limit the number of characters read by %s? >>>>>>>>> >>>>>>>>> Yes we can do it, but just one thing which I think of is, if >>>>>>>>> the truncation of output inside output stream issue get >>>>>>>>> resolves as Dmritry suggested or O_BUFFLEN size gets increased >>>>>>>>> in any future fix then we have to again make changes in this >>>>>>>>> code, as limiting the no. >>>>>>>>> of character read by %s will give truncated output . In such >>>>>>>>> case present fix will have no effect. >>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just >>>>>>>> add the desired precision value to the %s than to split into >>>>>>>> two print statements. Or bite the bullet now and make the >>>>>>>> length immaterial by breaking the name into chunks. It's as >>>>>>>> easy to fix as to write the RFE :) >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Cheleswer >>>>>>>>>> > From robbin.ehn at oracle.com Fri Apr 1 10:54:11 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 1 Apr 2016 12:54:11 +0200 Subject: RFR (S): 8153174: Remove trailing comma from log configuration listings In-Reply-To: <56FCFE9B.80509@oracle.com> References: <56FCFE9B.80509@oracle.com> Message-ID: <56FE5353.4050800@oracle.com> Hi Marcus, Thanks, looks good! /Robbin On 03/31/2016 12:40 PM, Marcus Larsson wrote: > Hi, > > Please review the following small patch to avoid adding a trailing comma > in the tagset and level listings in the configuration string for log > outputs. Removing this comma allows the string to be used without > modification when configuring logging (with -Xlog or similar). > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8153174/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8153174 > > Thanks, > Marcus From marcus.larsson at oracle.com Fri Apr 1 11:06:05 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 1 Apr 2016 13:06:05 +0200 Subject: RFR (S): 8153174: Remove trailing comma from log configuration listings In-Reply-To: <56FE5353.4050800@oracle.com> References: <56FCFE9B.80509@oracle.com> <56FE5353.4050800@oracle.com> Message-ID: <56FE561D.4000201@oracle.com> Thanks Robbin! On 04/01/2016 12:54 PM, Robbin Ehn wrote: > Hi Marcus, > > Thanks, looks good! > > /Robbin > > On 03/31/2016 12:40 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following small patch to avoid adding a trailing comma >> in the tagset and level listings in the configuration string for log >> outputs. Removing this comma allows the string to be used without >> modification when configuring logging (with -Xlog or similar). >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8153174/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8153174 >> >> Thanks, >> Marcus From cheleswer.sahu at oracle.com Fri Apr 1 12:30:58 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 1 Apr 2016 05:30:58 -0700 (PDT) Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" Message-ID: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else print the value in KB. Regards, Cheleswer -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 1 18:57:57 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 1 Apr 2016 20:57:57 +0200 Subject: RFR (S): 8153174: Remove trailing comma from log configuration listings In-Reply-To: <56FCFE9B.80509@oracle.com> References: <56FCFE9B.80509@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 31 mars 2016, at 12:40, Marcus Larsson wrote: > > Hi, > > Please review the following small patch to avoid adding a trailing comma in the tagset and level listings in the configuration string for log outputs. Removing this comma allows the string to be used without modification when configuring logging (with -Xlog or similar). > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8153174/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8153174 > > Thanks, > Marcus From Alan.Bateman at oracle.com Sat Apr 2 09:53:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 2 Apr 2016 10:53:02 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> Message-ID: <56FF967E.5090102@oracle.com> (cc'ing serviceability-dev as this is where this code is maintained). On 02/04/2016 00:32, Mandy Chung wrote: > Hi Chris, > > Would jdk.internal.vm be appropriate for this VMSupoprt class? I agree. > > VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. > > src/jdk.jdwp.agent/share/native/libjdwp/util.c > JDWP calls it and needs to be updated. If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. > > VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. It could although I assume this means that introducing a new shared library. -Alan > > Mandy > >> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >> >> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >> >> sun.misc.VMSupport is a utility class supporting two functions: >> 1) the initialization of management Agent properties, and >> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >> >> The initialization of Agent properties is used statically by the java.managment module, >> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >> The location of VM temporary files is a low-level interface between the libraries and VM. >> For these reasons, VMSupport should remain in the base module, but be moved to an >> internal package. >> >> http://cr.openjdk.java.net/~chegar/8153181/00/ >> https://bugs.openjdk.java.net/browse/JDK-8153181 >> >> -Chris. From mandy.chung at oracle.com Sat Apr 2 19:34:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 2 Apr 2016 12:34:09 -0700 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <56FF967E.5090102@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> Message-ID: <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> > On Apr 2, 2016, at 2:53 AM, Alan Bateman wrote: > > > (cc'ing serviceability-dev as this is where this code is maintained). > > >> On 02/04/2016 00:32, Mandy Chung wrote: >> Hi Chris, >> >> Would jdk.internal.vm be appropriate for this VMSupoprt class? > I agree. > >> >> VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. >> >> src/jdk.jdwp.agent/share/native/libjdwp/util.c >> JDWP calls it and needs to be updated. > If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. > >> >> VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. > It could although I assume this means that introducing a new shared library. jdk.internal.perf is in java.base. Another option is to move it to jdk.jvmstat that i considered but may not worth it since perf counter is still in java.base. Mandy > >> >> Mandy >> >>> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >>> >>> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >>> >>> sun.misc.VMSupport is a utility class supporting two functions: >>> 1) the initialization of management Agent properties, and >>> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >>> >>> The initialization of Agent properties is used statically by the java.managment module, >>> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >>> The location of VM temporary files is a low-level interface between the libraries and VM. >>> For these reasons, VMSupport should remain in the base module, but be moved to an >>> internal package. >>> >>> http://cr.openjdk.java.net/~chegar/8153181/00/ >>> https://bugs.openjdk.java.net/browse/JDK-8153181 >>> >>> -Chris. > From chris.hegarty at oracle.com Sun Apr 3 15:47:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 3 Apr 2016 16:47:54 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> Message-ID: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Updated webrev, as per comments: http://cr.openjdk.java.net/~chegar/8153181/01/ getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which would move its native implementation into the VM, perf.cpp, but it doesn?t seem worth it, unless future refactoring wanted to get rid of JVM_GetTemporaryDirectory. -Chris. On 2 Apr 2016, at 20:34, Mandy Chung wrote: >> >> On Apr 2, 2016, at 2:53 AM, Alan Bateman wrote: >> >> >> (cc'ing serviceability-dev as this is where this code is maintained). >> >> >>> On 02/04/2016 00:32, Mandy Chung wrote: >>> Hi Chris, >>> >>> Would jdk.internal.vm be appropriate for this VMSupoprt class? >> I agree. >> >>> >>> VMSupport::getAgentProperties simply calls JVM_InitAgentProperties. java.management could call JVM_InitAgentProperties directly. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/util.c >>> JDWP calls it and needs to be updated. >> If I recall correctly then this is so that the debugger transport details can be advertised. There is a process AttachingConnector that depends on that so I agree this needs to be updated. >> >>> >>> VMSupport.getVMTemporaryDirectory() is for jdk.jvmstat to use and I suggest to move this method to jdk.internal.perf.Perf. >> It could although I assume this means that introducing a new shared library. > > jdk.internal.perf is in java.base. Another option is to move it to jdk.jvmstat that i considered but may not worth it since perf counter is still in java.base. > > Mandy > >> >>> >>> Mandy >>> >>>> On Mar 31, 2016, at 9:02 AM, Chris Hegarty wrote: >>>> >>>> As part of JEP 260, all non-Critical APIs in sun.misc are being examined. >>>> >>>> sun.misc.VMSupport is a utility class supporting two functions: >>>> 1) the initialization of management Agent properties, and >>>> 2) the retrieval of the VM temporary directory used by the attach and perf data files. >>>> >>>> The initialization of Agent properties is used statically by the java.managment module, >>>> or can be provoked by a serviceability tool on a VM that has had an agent loaded in it. >>>> The location of VM temporary files is a low-level interface between the libraries and VM. >>>> For these reasons, VMSupport should remain in the base module, but be moved to an >>>> internal package. >>>> >>>> http://cr.openjdk.java.net/~chegar/8153181/00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8153181 >>>> >>>> -Chris. From Alan.Bateman at oracle.com Sun Apr 3 18:44:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 3 Apr 2016 19:44:27 +0100 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Message-ID: <5701648B.8060305@oracle.com> On 03/04/2016 16:47, Chris Hegarty wrote: > Updated webrev, as per comments: > http://cr.openjdk.java.net/~chegar/8153181/01/ > > getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which > would move its native implementation into the VM, perf.cpp, but it doesn?t > seem worth it, unless future refactoring wanted to get rid of > JVM_GetTemporaryDirectory. > This looks okay. -Alan From mandy.chung at oracle.com Mon Apr 4 01:06:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 3 Apr 2016 18:06:24 -0700 Subject: RFR [9] 8153181: Examine sun.misc.VMSupport In-Reply-To: <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> References: <85A7A426-8B74-49F5-9C43-B428BEF8B4E8@oracle.com> <56FF967E.5090102@oracle.com> <7DFFF28C-9562-405C-8C3F-B238C5950473@oracle.com> <75CEB036-1CE1-4FED-B667-7B79004E8C69@oracle.com> Message-ID: <5C64C8CB-F67E-4D2F-ADD8-D67B7664A219@oracle.com> > On Apr 3, 2016, at 8:47 AM, Chris Hegarty wrote: > > Updated webrev, as per comments: > http://cr.openjdk.java.net/~chegar/8153181/01/ > > getVMTemporaryDirectory could be moved into jdk.internal.perf.Perf, which > would move its native implementation into the VM, perf.cpp, but it doesn?t > seem worth it, unless future refactoring wanted to get rid of > JVM_GetTemporaryDirectory. > It looks okay. We should look into this when we look into future clean up work in this area. Mandy From robbin.ehn at oracle.com Mon Apr 4 15:09:07 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 4 Apr 2016 17:09:07 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests Message-ID: <57028393.5020104@oracle.com> Hi all, Please review, Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 Tested with internal vm test. Thanks! /Robbin From stefan.karlsson at oracle.com Mon Apr 4 15:23:42 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 4 Apr 2016 17:23:42 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <57028393.5020104@oracle.com> References: <57028393.5020104@oracle.com> Message-ID: <570286FE.5080503@oracle.com> Looks good. StefanK On 2016-04-04 17:09, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 > > Tested with internal vm test. > > Thanks! > > /Robbin From chris.plummer at oracle.com Mon Apr 4 16:09:45 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 4 Apr 2016 09:09:45 -0700 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported In-Reply-To: <56FD50C5.4020303@oracle.com> References: <56FCC1B9.3060007@oracle.com> <56FCD404.8030601@oracle.com> <56FD50C5.4020303@oracle.com> Message-ID: <570291C9.30801@oracle.com> Ping! Still looking for one more reviewer. thanks, Chris On 3/31/16 9:31 AM, Chris Plummer wrote: > Hi Serguei, > > Thanks for the review. I'll make all the changes you suggested. > > cheers, > > Chris > > On 3/31/16 12:38 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> >> It looks pretty good, thanks! >> >> Just some minor comments below. >> >> src/share/vm/ci/ciMethod.cpp >> >> The only file with old Copyright year. >> >> src/share/vm/oops/instanceKlass.hpp >> >> 907 // Breakpoint support (see methods on Method* for details) >> 908 #if INCLUDE_JVMTI >> 909 BreakpointInfo* breakpoints() const { return _breakpoints; }; >> 910 void set_breakpoints(BreakpointInfo* bps) { _breakpoints = bps; }; >> 911 #endif >> Better to move the comment at the L907 inside the ifdef block. >> >> 1280 // RedefineClasses support >> 1281 #if INCLUDE_JVMTI >> 1282 void link_previous_versions(InstanceKlass* pv) { _previous_versions = pv; } >> 1283 void mark_newly_obsolete_methods(Array* old_methods, int emcp_method_count); >> 1284 #endif >> Better to move the comment at the L1280 inside the ifdef block. >> >> >> src/share/vm/oops/method.hpp >> 1041 /// Fast Breakpoints. >> 1042 >> 1043 // If this structure gets more complicated (because bpts get numerous), >> 1044 // move it into its own header. >> 1045 >> 1046 // There is presently no provision for concurrent access >> 1047 // to breakpoint lists, which is only OK for JVMTI because >> 1048 // breakpoints are written only at safepoints, and are read >> 1049 // concurrently only outside of safepoints. >> 1050 >> 1051 #if INCLUDE_JVMTI >> Better to move the comments at the L1041-1949 inside the ifdef block. >> >> Consider it reviewed, I do not need to see another webrev. >> >> >> Thanks, >> Serguei >> >> >> On 3/30/16 23:20, Chris Plummer wrote: >>> Please review the following for removing some fields that are not >>> needed when not supporting JVMTI. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148195 >>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/ >>> >>> I had passed a preliminary review around a month or so ago. The >>> webrev is here: >>> >>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/ >>> >>> I made a number of changes since then. I tried to reduce the number >>> of #ifdefs, but at the same time include less unnecessary code in >>> the INCLUDE_JVMTI=0 build. For example, BreakpointInfo is now >>> completely gone when not including JVMTI. I didn't really succeed at >>> the former since #ifdefs seem to have just moved around, but there >>> is a lot more code conditionally compiled out now, and I think it's >>> cleaner this way. >>> >>> Also since the previous webrev, I added some fixes for SA, although >>> these aren't possible to test right now. Currently the minimal VM is >>> the only one that supports excluding JVMTI, but it also excludes SA, >>> so that makes it hard to test conditionally removing some JVMTI >>> support from SA. I tried doing a client VM build without JVMTI, but >>> that's currently broken (can't build with INCLUDE_JVMTI=0 and >>> INCLUDE_SERVICES=1). It's a known issue that's already being worked on. >>> >>> Testing I've done: >>> >>> - jprt -testset hotspot >>> - jck vm tests with minimal vm on linux-x86 >>> - hotspot/test/:compact2_minimal with minimal vm on linux-x86 >>> - all the serviceability tests I could find supported by RBT. Ran >>> with client vm >>> on linux-x86 and server vm on linux-x64. >>> >>> I'm going to try to do more minimal VM testing. I need to figure out >>> more test suites I can run with minimal and not get a ton of errors >>> due to the tests using excluded functionality. >>> >>> thanks, >>> >>> Chris >> > From alexhenrie24 at gmail.com Mon Apr 4 16:50:28 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Mon, 04 Apr 2016 10:50:28 -0600 Subject: [PATCH resend] 8145278: Fix memory leak in splitPathList Message-ID: <8021a03115817aa9c641.1459788628@wolverine> # HG changeset patch # User Alex Henrie # Date 1447827030 25200 # Tue Nov 17 23:10:30 2015 -0700 # Node ID 8021a03115817aa9c641333848e2f483516f06a7 # Parent 0007e5d265a849b73114c98b3d4f55dde83a57ea 8145278: Fix memory leak in splitPathList diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c @@ -513,28 +513,32 @@ eventHandlerClassFileLoadHook( jvmtiEnv * The attribute value is in UTF8 but cannot contain NUL. Also non US-ASCII * characters must be escaped (URI syntax) so safe to iterate through the * value as a C string. */ static void splitPathList(const char* str, int* pathCount, char*** paths) { int count = 0; char** segments = NULL; + char** new_segments; char* c = (char*) str; while (*c != '\0') { while (*c == ' ') c++; /* skip leading spaces */ if (*c == '\0') { break; } - if (segments == NULL) { - segments = (char**)malloc( sizeof(char**) ); - } else { - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); + new_segments = (char**)realloc(segments, (count+1)*sizeof(char*)); + if (new_segments == NULL) { + jplis_assert(0); + free(segments); + count = 0; + segments = NULL; + break; } - jplis_assert(segments != (char**)NULL); + segments = new_segments; segments[count++] = c; c = strchr(c, ' '); if (c == NULL) { break; } *c = '\0'; c++; } From robbin.ehn at oracle.com Tue Apr 5 06:20:12 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 5 Apr 2016 08:20:12 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <570286FE.5080503@oracle.com> References: <57028393.5020104@oracle.com> <570286FE.5080503@oracle.com> Message-ID: <5703591C.5060601@oracle.com> Thanks Stefan! /Robbin On 04/04/2016 05:23 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-04 17:09, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 >> >> Tested with internal vm test. >> >> Thanks! >> >> /Robbin > From bengt.rutisson at oracle.com Tue Apr 5 08:27:23 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 5 Apr 2016 10:27:23 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <57028393.5020104@oracle.com> References: <57028393.5020104@oracle.com> Message-ID: <570376EB.1090504@oracle.com> Hi Robbin, On 2016-04-04 17:09, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 Looks good. Bengt > > Tested with internal vm test. > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 5 08:46:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 5 Apr 2016 10:46:00 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <570376EB.1090504@oracle.com> References: <57028393.5020104@oracle.com> <570376EB.1090504@oracle.com> Message-ID: <57037B48.3000305@oracle.com> Thanks Bengt! /Robbin On 04/05/2016 10:27 AM, Bengt Rutisson wrote: > > > Hi Robbin, > > On 2016-04-04 17:09, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 > > Looks good. > > Bengt > >> >> Tested with internal vm test. >> >> Thanks! >> >> /Robbin > From cheleswer.sahu at oracle.com Tue Apr 5 10:23:16 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 5 Apr 2016 03:23:16 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Message-ID: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ Bug Brief: Test is failing on some platforms. Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. Regards, Cheleswer -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at gmail.com Tue Apr 5 11:14:35 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 5 Apr 2016 14:14:35 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: Hi Cheleswer, is it possible to use j.u.c.CountDownLatch for synchronization instead of sleep? Regards, Filipp. On Tue, Apr 5, 2016 at 1:23 PM, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished > its execution before main thread calls ?jstack?, which result in test > failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make > sure that ?jstack ? tool always gets executed after ? NamedThread? is > started. > > > > > > Regards, > > Cheleswer > > > > From alexander.kulyakhtin at oracle.com Tue Apr 5 11:54:09 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 5 Apr 2016 04:54:09 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Message-ID: Hi Cheleswer, I doubt Thread.sleep() can ensure a program state. As Philip has pointed out, some synchronization object would, probably, be more appropriate. + // Ensuring that Jstack will always run after NamedThread is started + Thread.sleep(2000); Best regards, Alexander ----- Original Message ----- From: cheleswer.sahu at oracle.com To: hotspot-runtime-dev at openjdk.java.net, serviceability-dev at openjdk.java.net Sent: Tuesday, April 5, 2016 1:23:57 PM GMT +03:00 Iraq Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319 . Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ Bug Brief: Test is failing on some platforms. Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls ?jstack?, which result in test failure. Solution Proposed: Set the child thread in sleep state for forever and make sure that ?jstack ? tool always gets executed after ? NamedThread? is started. Regards, Cheleswer -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Tue Apr 5 13:29:53 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 5 Apr 2016 16:29:53 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: <5703BDD1.5090108@oracle.com> Hi I don't think that sleep is a good way to ensure that thread is started. It is not reliable on the slow host / VM under stress and just waste of time on fast host. Is it possible just to add any explicit synchronization to ensure that NamedThread is started? Leonid On 05.04.2016 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. > > > > > > Regards, > > Cheleswer > > > > From dmitry.samersoff at oracle.com Tue Apr 5 15:24:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 5 Apr 2016 18:24:43 +0300 Subject: RFR: JDK-8152435: (CL)HSDB should be started with no argument In-Reply-To: <56FA6EEF.3080207@gmail.com> References: <56F15B6C.3080102@gmail.com> <56FA6EEF.3080207@gmail.com> Message-ID: <5703D8BB.1080208@oracle.com> Yasumasa, SAGetoptException should be internal for SAGetopt. So please use DebuggerException in SALauncher. PS: Besides that the changes looks OK for me and I'll sponsor the push. -Dmitry On 2016-03-29 15:02, Yasumasa Suenaga wrote: > PING: Could you review it? > > > Yasumasa > > > On 2016/03/22 23:49, Yasumasa Suenaga wrote: >> HI all, >> >> After JDK-8151709, CLHSDB and HSDB cannot be started with no argument via jhsdb. >> CLHSDB and HSDB can attach process / core after starting. >> jhsdb should support it. >> >> I uploaded webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152435/webrev.00/ >> >> This patch passed jtreg test sun/tools/jhsdb in jdk repos. >> Could you review it? >> >> I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From dmitry.samersoff at oracle.com Tue Apr 5 15:31:01 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 5 Apr 2016 18:31:01 +0300 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <56FA6EC9.90107@gmail.com> References: <56FA6EC9.90107@gmail.com> Message-ID: <5703DA35.2070408@oracle.com> Yasumasa, 1. It's better to change JSnap code to produce meaningful error message instead of NPE. 2. We should check that no other consumer of perf counters rely on the fact it's NULL after call to destroy(). I'm not sure that this part of the fix is not dangerous. -Dmitry On 2016-03-29 15:02, Yasumasa Suenaga wrote: > PING: Could you review it? > > > Yasumasa > > > On 2016/03/22 21:24, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >> Yasumasa >> >> 2016/03/14 23:39 "Yasumasa Suenaga" > >: >> >> Hi all, >> >> When I use `jhsdb jsnap` to get PerfCounter from core images, I >> encountered NPE: >> ------------- >> Exception in thread "main" java.lang.NullPointerException >> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >> at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >> ------------- >> >> PerfMemory::destroy() clears all members which are used in JSnap. >> Thus NPE is occurred. >> >> I uploaded webrev for this issue. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >> >> I cannot access JPRT. >> So I need a Sponsor. >> >> >> Thanks, >> >> Yasumasa >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From yasuenag at gmail.com Tue Apr 5 23:15:13 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 6 Apr 2016 08:15:13 +0900 Subject: RFR: JDK-8152435: (CL)HSDB should be started with no argument In-Reply-To: <5703D8BB.1080208@oracle.com> References: <56F15B6C.3080102@gmail.com> <56FA6EEF.3080207@gmail.com> <5703D8BB.1080208@oracle.com> Message-ID: <57044701.2010607@gmail.com> Hi Dmitry, Thanks for your comment. > So please use DebuggerException in SALauncher. DebuggerException will be thrown from many point in hotspot/src/jdk.hotspot.agent . If SALauncher catches DebuggerException, it will show help message in each time. Is it allowed? Thanks, Yasumasa On 2016/04/06 0:24, Dmitry Samersoff wrote: > Yasumasa, > > SAGetoptException should be internal for SAGetopt. > > So please use DebuggerException in SALauncher. > > PS: Besides that the changes looks OK for me and I'll sponsor the push. > > -Dmitry > > On 2016-03-29 15:02, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >> >> Yasumasa >> >> >> On 2016/03/22 23:49, Yasumasa Suenaga wrote: >>> HI all, >>> >>> After JDK-8151709, CLHSDB and HSDB cannot be started with no argument via jhsdb. >>> CLHSDB and HSDB can attach process / core after starting. >>> jhsdb should support it. >>> >>> I uploaded webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152435/webrev.00/ >>> >>> This patch passed jtreg test sun/tools/jhsdb in jdk repos. >>> Could you review it? >>> >>> I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> > > From yasuenag at gmail.com Wed Apr 6 03:42:40 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 6 Apr 2016 12:42:40 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <5703DA35.2070408@oracle.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> Message-ID: <570485B0.70200@gmail.com> Hi Dmitry, Thanks for your comment. I uploaded a new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ On 2016/04/06 0:31, Dmitry Samersoff wrote: > Yasumasa, > > 1. It's better to change JSnap code to produce meaningful error message > instead of NPE. I added null check and set message to PerfMemory.java . > 2. We should check that no other consumer of perf counters rely on the > fact it's NULL after call to destroy(). I'm not sure that this part of > the fix is not dangerous. I added new flag (_destroyed) in PerfMemory class. This flag set true at PerfMemory::destroy(). _start, _end, and more field which I removed from destroy() are private member of PerfMemory. I implemented that the getter functions of them check _destroyed flag, and returns same value before this change. So I think this change does not affect other place. Thanks, Yasumasa > -Dmitry > > On 2016-03-29 15:02, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >> >> Yasumasa >> >> >> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> >>> Yasumasa >>> >>> 2016/03/14 23:39 "Yasumasa Suenaga" >> >: >>> >>> Hi all, >>> >>> When I use `jhsdb jsnap` to get PerfCounter from core images, I >>> encountered NPE: >>> ------------- >>> Exception in thread "main" java.lang.NullPointerException >>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>> at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>> ------------- >>> >>> PerfMemory::destroy() clears all members which are used in JSnap. >>> Thus NPE is occurred. >>> >>> I uploaded webrev for this issue. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>> >>> I cannot access JPRT. >>> So I need a Sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> > > From cheleswer.sahu at oracle.com Wed Apr 6 06:15:30 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 5 Apr 2016 23:15:30 -0700 (PDT) Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" In-Reply-To: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> References: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> Message-ID: <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> Hi, This fix is waiting for review, can somebody please review this change. Regards, Cheleswer From: Cheleswer Sahu Sent: Friday, April 01, 2016 6:01 PM To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Cc: Mattis Castegren Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else print the value in KB. Regards, Cheleswer -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Wed Apr 6 06:46:08 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 6 Apr 2016 08:46:08 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. Message-ID: <5704B0B0.4010404@oracle.com> Hi, Please review the following patch to add a warning for when tag selections in -Xlog or VM.log don't match any tag sets used in the VM. Webrev: http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8150894 Testing: Internal VM tests with RBT Thanks, Marcus From dmitry.samersoff at oracle.com Wed Apr 6 08:01:23 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Apr 2016 11:01:23 +0300 Subject: RFR: JDK-8152435: (CL)HSDB should be started with no argument In-Reply-To: <57044701.2010607@gmail.com> References: <56F15B6C.3080102@gmail.com> <56FA6EEF.3080207@gmail.com> <5703D8BB.1080208@oracle.com> <57044701.2010607@gmail.com> Message-ID: <5704C253.1050500@oracle.com> Yasumasa, > Is it allowed? Hmm. Lets go ahead with SAGetoptException. -Dmitry On 2016-04-06 02:15, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thanks for your comment. > >> So please use DebuggerException in SALauncher. > > DebuggerException will be thrown from many point in > hotspot/src/jdk.hotspot.agent . > If SALauncher catches DebuggerException, it will show help message in > each time. > > Is it allowed? > > > Thanks, > > Yasumasa > > > On 2016/04/06 0:24, Dmitry Samersoff wrote: >> Yasumasa, >> >> SAGetoptException should be internal for SAGetopt. >> >> So please use DebuggerException in SALauncher. >> >> PS: Besides that the changes looks OK for me and I'll sponsor the push. >> >> -Dmitry >> >> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> >>> >>> Yasumasa >>> >>> >>> On 2016/03/22 23:49, Yasumasa Suenaga wrote: >>>> HI all, >>>> >>>> After JDK-8151709, CLHSDB and HSDB cannot be started with no >>>> argument via jhsdb. >>>> CLHSDB and HSDB can attach process / core after starting. >>>> jhsdb should support it. >>>> >>>> I uploaded webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152435/webrev.00/ >>>> >>>> This patch passed jtreg test sun/tools/jhsdb in jdk repos. >>>> Could you review it? >>>> >>>> I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From per.liden at oracle.com Wed Apr 6 09:32:51 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 6 Apr 2016 11:32:51 +0200 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME Message-ID: <5704D7C3.1010905@oracle.com> Summary: This patch updates the tests in serviceability/tmtools/jstat/ to use a fixed (and relatively small) heap size. Without this these tests tend to run out of memory on machines with VM overcommit disabled. This has happened in nightly testing. The patch also moves a misplaced @ignore tag and cleans out an unused method. Testing: Without this patch I can easily get these tests to OOM on my local workstation by just disabling VM overcommit. They pass with this patch applied. Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ cheers, Per From dmitry.samersoff at oracle.com Wed Apr 6 09:46:14 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Apr 2016 12:46:14 +0300 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <5704D7C3.1010905@oracle.com> References: <5704D7C3.1010905@oracle.com> Message-ID: <5704DAE6.9040503@oracle.com> Per, The fix looks good for me. Copyright year of these tests is not updated. GcCapacityTest.java GcCauseTest01.java GcTest02.java -Dmitry On 2016-04-06 12:32, Per Liden wrote: > Summary: This patch updates the tests in serviceability/tmtools/jstat/ > to use a fixed (and relatively small) heap size. Without this these > tests tend to run out of memory on machines with VM overcommit disabled. > This has happened in nightly testing. > > The patch also moves a misplaced @ignore tag and cleans out an unused > method. > > Testing: Without this patch I can easily get these tests to OOM on my > local workstation by just disabling VM overcommit. They pass with this > patch applied. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 > Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ > > cheers, > Per > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Wed Apr 6 09:46:34 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 6 Apr 2016 02:46:34 -0700 (PDT) Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour Message-ID: <882e5886-b5a2-420c-b9a2-937873f3672f@default> Hi, Could you, please, review, the following test-only changes (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. Best regards, Alexander From Alan.Bateman at oracle.com Wed Apr 6 09:51:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Apr 2016 10:51:42 +0100 Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour In-Reply-To: <882e5886-b5a2-420c-b9a2-937873f3672f@default> References: <882e5886-b5a2-420c-b9a2-937873f3672f@default> Message-ID: <5704DC2E.3040004@oracle.com> On 06/04/2016 10:46, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review, the following test-only changes (adding a new test). > > CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ > > The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. > In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. > The tests for JDI are in the jdk repo, would it be saner to put additional tests there so that they aren't split between two repos? -Alan From dmitry.samersoff at oracle.com Wed Apr 6 09:55:57 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Apr 2016 12:55:57 +0300 Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour In-Reply-To: <882e5886-b5a2-420c-b9a2-937873f3672f@default> References: <882e5886-b5a2-420c-b9a2-937873f3672f@default> Message-ID: <5704DD2D.4030500@oracle.com> Alexander, The test looks good for me. But, as Alan says if the test is for JDI (but not SAJDI), please place it to .../jdk/test/com/sun/jdi -Dmitry On 2016-04-06 12:46, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review, the following test-only changes (adding a new test). > > CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ > > The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. > In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. > > Best regards, > Alexander > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Wed Apr 6 09:56:48 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 6 Apr 2016 02:56:48 -0700 (PDT) Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour Message-ID: <2ded1c63-6ef3-4ff9-a4ad-f326c576fa0a@default> Alan, What would be, the most suitable location for the test? I'm going to make sure this new test does not duplicate any existing one and, if not, will change the patch accordingly then. Best regards, Alexander ----- Original Message ----- From: Alan.Bateman at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Wednesday, April 6, 2016 12:51:44 PM GMT +03:00 Iraq Subject: Re: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour On 06/04/2016 10:46, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review, the following test-only changes (adding a new test). > > CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ > > The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. > In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. > The tests for JDI are in the jdk repo, would it be saner to put additional tests there so that they aren't split between two repos? -Alan From serguei.spitsyn at oracle.com Wed Apr 6 10:00:50 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Apr 2016 03:00:50 -0700 Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour In-Reply-To: <2ded1c63-6ef3-4ff9-a4ad-f326c576fa0a@default> References: <2ded1c63-6ef3-4ff9-a4ad-f326c576fa0a@default> Message-ID: <5704DE52.5000001@oracle.com> As Dmitry noted: jdk/test/com/sun/jdi Sorry, we did not point to it in the internal review. Thanks, Serguei On 4/6/16 02:56, Alexander Kulyakhtin wrote: > Alan, > > What would be, the most suitable location for the test? I'm going to make sure this new test does not duplicate any existing one and, if not, will change the patch accordingly then. > > Best regards, > Alexander > > > ----- Original Message ----- > From: Alan.Bateman at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Sent: Wednesday, April 6, 2016 12:51:44 PM GMT +03:00 Iraq > Subject: Re: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour > > On 06/04/2016 10:46, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review, the following test-only changes (adding a new test). >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ >> >> The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. >> In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. >> > The tests for JDI are in the jdk repo, would it be saner to put > additional tests there so that they aren't split between two repos? > > -Alan From alexander.kulyakhtin at oracle.com Wed Apr 6 10:13:27 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 6 Apr 2016 03:13:27 -0700 (PDT) Subject: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour Message-ID: <5e425503-4fd3-45a2-b7cf-2b79f39b8282@default> I've moved the test to the jdk repo. Webrev: http://cr.openjdk.java.net/~akulyakh/8153584_02/ Thank you very much for your help. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com, Alan.Bateman at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Wednesday, April 6, 2016 1:00:47 PM GMT +03:00 Iraq Subject: Re: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour As Dmitry noted: jdk/test/com/sun/jdi Sorry, we did not point to it in the internal review. Thanks, Serguei On 4/6/16 02:56, Alexander Kulyakhtin wrote: > Alan, > > What would be, the most suitable location for the test? I'm going to make sure this new test does not duplicate any existing one and, if not, will change the patch accordingly then. > > Best regards, > Alexander > > > ----- Original Message ----- > From: Alan.Bateman at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Sent: Wednesday, April 6, 2016 12:51:44 PM GMT +03:00 Iraq > Subject: Re: RFR:8153584:New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour > > On 06/04/2016 10:46, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review, the following test-only changes (adding a new test). >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify PathSearchingVirutalMachine.bootClassPath() behaviour" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/ >> >> The new test verifies that in the JDK9 PathSearchingVirutalMachine.bootClassPath() always returns an empty string list, regardless of the, now obsolete, sun.boot.class.path property. >> In the JDK 8 bootClassPath() used to be verified by a closed test (therefore the CR is closed). We are changing the test and moving it to the open as it verifies the open, public API. >> > The tests for JDI are in the jdk repo, would it be saner to put > additional tests there so that they aren't split between two repos? > > -Alan From stefan.johansson at oracle.com Wed Apr 6 11:02:12 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 6 Apr 2016 13:02:12 +0200 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <5704D7C3.1010905@oracle.com> References: <5704D7C3.1010905@oracle.com> Message-ID: <5704ECB4.807@oracle.com> Looks good, StefanJ On 2016-04-06 11:32, Per Liden wrote: > Summary: This patch updates the tests in serviceability/tmtools/jstat/ > to use a fixed (and relatively small) heap size. Without this these > tests tend to run out of memory on machines with VM overcommit > disabled. This has happened in nightly testing. > > The patch also moves a misplaced @ignore tag and cleans out an unused > method. > > Testing: Without this patch I can easily get these tests to OOM on my > local workstation by just disabling VM overcommit. They pass with this > patch applied. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 > Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ > > cheers, > Per > From per.liden at oracle.com Wed Apr 6 11:02:55 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 6 Apr 2016 13:02:55 +0200 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <5704DAE6.9040503@oracle.com> References: <5704D7C3.1010905@oracle.com> <5704DAE6.9040503@oracle.com> Message-ID: <5704ECDF.1080207@oracle.com> On 2016-04-06 11:46, Dmitry Samersoff wrote: > Per, > > The fix looks good for me. Thanks Dima. > > Copyright year of these tests is not updated. > > GcCapacityTest.java > GcCauseTest01.java > GcTest02.java These already have 2016 in their copyright. cheers, Per > > -Dmitry > > On 2016-04-06 12:32, Per Liden wrote: >> Summary: This patch updates the tests in serviceability/tmtools/jstat/ >> to use a fixed (and relatively small) heap size. Without this these >> tests tend to run out of memory on machines with VM overcommit disabled. >> This has happened in nightly testing. >> >> The patch also moves a misplaced @ignore tag and cleans out an unused >> method. >> >> Testing: Without this patch I can easily get these tests to OOM on my >> local workstation by just disabling VM overcommit. They pass with this >> patch applied. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 >> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ >> >> cheers, >> Per >> > > From mikael.gerdin at oracle.com Wed Apr 6 11:09:19 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 6 Apr 2016 13:09:19 +0200 Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" In-Reply-To: <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> References: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> Message-ID: <5704EE5F.1000109@oracle.com> Hi, this is GC code and the rewview should go to hotspot-gc-dev. I'm redirecting this mail there. /Mikael On 2016-04-06 08:15, Cheleswer Sahu wrote: > Hi, > > > > This fix is waiting for review, can somebody please review this change. > > > > Regards, > > Cheleswer > > > > From: Cheleswer Sahu > Sent: Friday, April 01, 2016 6:01 PM > To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Cc: Mattis Castegren > Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" > > > > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. > > > > Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ > > > > Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. > > > > Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. > > > > Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else > > print the value in KB. > > > > > > > > Regards, > > Cheleswer > > > From per.liden at oracle.com Wed Apr 6 11:17:56 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 6 Apr 2016 13:17:56 +0200 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <5704ECB4.807@oracle.com> References: <5704D7C3.1010905@oracle.com> <5704ECB4.807@oracle.com> Message-ID: <5704F064.4040701@oracle.com> Thanks Stefan. Per On 2016-04-06 13:02, Stefan Johansson wrote: > Looks good, > StefanJ > > On 2016-04-06 11:32, Per Liden wrote: >> Summary: This patch updates the tests in serviceability/tmtools/jstat/ >> to use a fixed (and relatively small) heap size. Without this these >> tests tend to run out of memory on machines with VM overcommit >> disabled. This has happened in nightly testing. >> >> The patch also moves a misplaced @ignore tag and cleans out an unused >> method. >> >> Testing: Without this patch I can easily get these tests to OOM on my >> local workstation by just disabling VM overcommit. They pass with this >> patch applied. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 >> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ >> >> cheers, >> Per >> > From dmitry.samersoff at oracle.com Wed Apr 6 11:21:33 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Apr 2016 14:21:33 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: <5704F13D.1050400@oracle.com> Cheleswer, Some times ago I invented LingeredAppWithDeadlock for tests like this one. Please take a look at: .../jdk/test/sun/tools/jstack/DeadlockDetectionTest.java .../hotspot/test/serviceability/sa/DeadlockDetectionTest.java -Dmitry On 2016-04-05 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is > finished its execution before main thread calls ?jstack?, which result > in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and > make sure that ?jstack ? tool always gets executed after ? NamedThread? > is started. > > > > > > Regards, > > Cheleswer > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Wed Apr 6 23:11:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:11:59 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Message-ID: <570597BF.8070703@oracle.com> Greetings, It appears that the fix for this bug: JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-4858370 has been causing intermittent test failures in the JDK9-hs-rt nightly. ************************************************************ I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. ************************************************************ This bug is being using to backout JDK-4858370: JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-8153673 Here is the backout webrev URL: http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ Here are the changeset link for JDK-4858370: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 Jesper and Serguei, thanks, in advance, for the reviews! Gory details below... Dan Here's my jdk repo sanity check note: Daniel Daugherty added a comment - 1 hour ago Sanity checks for backing out this fix and its test: $ hg log -r 277d7584fa03 changeset: 13880:277d7584fa03 parent: 13877:645a9be6eddb user: sgehwolf date: Mon Mar 21 11:24:09 2016 +0100 summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command $ hg status M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c R test/com/sun/jdi/OomDebugTest.java ? files.list $ hg diff -r 13877 `cat files.list ` $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 +0200 +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 -0700 @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ } return error; -} - -/* - * Delete global references from the request which got put there before a - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() - * impls. - */ -static void -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) -{ - void *cursor; - jint argIndex = 0; - jvalue *argument = request->arguments; - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); - - if (request->clazz != NULL) { - tossGlobalRef(env, &(request->clazz)); - } - if (request->instance != NULL) { - tossGlobalRef(env, &(request->instance)); - } - /* Delete global argument references */ - while (argIndex < request->argumentCount) { - if ((argumentTag == JDWP_TAG(OBJECT)) || - (argumentTag == JDWP_TAG(ARRAY))) { - if (argument->l != NULL) { - tossGlobalRef(env, &(argument->l)); - } - } - argument++; - argIndex++; - argumentTag = nextArgumentTypeTag(&cursor); - } - /* Delete potentially saved return values */ - if ((request->invokeType == INVOKE_CONSTRUCTOR) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { - if (request->returnValue.l != NULL) { - tossGlobalRef(env, &(request->returnValue.l)); - } - } } static jvmtiError @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th (void)outStream_writeObjectRef(env, &out, exc); outStream_sendReply(&out); } - - /* - * At this time, there's no need to retain global references on - * arguments since the reply is processed. No one will deal with - * this request ID anymore, so we must call deleteGlobalRefs(). - */ - deleteGlobalRefs(env, request); } jboolean $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c From daniel.daugherty at oracle.com Wed Apr 6 23:34:50 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:34:50 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Message-ID: <57059D1A.4060000@oracle.com> Resending with Jesper and Serguei on directly... Greetings, It appears that the fix for this bug: JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-4858370 has been causing intermittent test failures in the JDK9-hs-rt nightly. ************************************************************ I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. ************************************************************ This bug is being using to backout JDK-4858370: JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-8153673 Here is the backout webrev URL: http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ Here are the changeset link for JDK-4858370: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 Jesper and Serguei, thanks, in advance, for the reviews! Gory details below... Dan Here's my jdk repo sanity check note: Daniel Daugherty added a comment - 1 hour ago Sanity checks for backing out this fix and its test: $ hg log -r 277d7584fa03 changeset: 13880:277d7584fa03 parent: 13877:645a9be6eddb user: sgehwolf date: Mon Mar 21 11:24:09 2016 +0100 summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command $ hg status M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c R test/com/sun/jdi/OomDebugTest.java ? files.list $ hg diff -r 13877 `cat files.list ` $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 +0200 +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 -0700 @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ } return error; -} - -/* - * Delete global references from the request which got put there before a - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() - * impls. - */ -static void -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) -{ - void *cursor; - jint argIndex = 0; - jvalue *argument = request->arguments; - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); - - if (request->clazz != NULL) { - tossGlobalRef(env, &(request->clazz)); - } - if (request->instance != NULL) { - tossGlobalRef(env, &(request->instance)); - } - /* Delete global argument references */ - while (argIndex < request->argumentCount) { - if ((argumentTag == JDWP_TAG(OBJECT)) || - (argumentTag == JDWP_TAG(ARRAY))) { - if (argument->l != NULL) { - tossGlobalRef(env, &(argument->l)); - } - } - argument++; - argIndex++; - argumentTag = nextArgumentTypeTag(&cursor); - } - /* Delete potentially saved return values */ - if ((request->invokeType == INVOKE_CONSTRUCTOR) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { - if (request->returnValue.l != NULL) { - tossGlobalRef(env, &(request->returnValue.l)); - } - } } static jvmtiError @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th (void)outStream_writeObjectRef(env, &out, exc); outStream_sendReply(&out); } - - /* - * At this time, there's no need to retain global references on - * arguments since the reply is processed. No one will deal with - * this request ID anymore, so we must call deleteGlobalRefs(). - */ - deleteGlobalRefs(env, request); } jboolean $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c From jesper.wilhelmsson at oracle.com Wed Apr 6 23:43:55 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 7 Apr 2016 01:43:55 +0200 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059D1A.4060000@oracle.com> References: <57059D1A.4060000@oracle.com> Message-ID: <57059F3B.1030705@oracle.com> Looks good! /Jesper Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty: > Resending with Jesper and Serguei on directly... > > Greetings, > > It appears that the fix for this bug: > > JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing > invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-4858370 > > has been causing intermittent test failures in the JDK9-hs-rt nightly. > > > ************************************************************ > I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. > ************************************************************ > > > This bug is being using to backout JDK-4858370: > > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when > processing invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-8153673 > > Here is the backout webrev URL: > > http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ > > Here are the changeset link for JDK-4858370: > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 > > Jesper and Serguei, thanks, in advance, for the reviews! > > Gory details below... > > Dan > > > > Here's my jdk repo sanity check note: > > Daniel Daugherty added a comment - 1 hour ago > Sanity checks for backing out this fix and its test: > > $ hg log -r 277d7584fa03 > changeset: 13880:277d7584fa03 > parent: 13877:645a9be6eddb > user: sgehwolf > date: Mon Mar 21 11:24:09 2016 +0100 > summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing > invokeMethod command > > $ hg status > M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > R test/com/sun/jdi/OomDebugTest.java > ? files.list > > $ hg diff -r 13877 `cat files.list ` > > > $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 > +0200 > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 > -0700 > @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ > } > > return error; > -} > - > -/* > - * Delete global references from the request which got put there before a > - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() > - * impls. > - */ > -static void > -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) > -{ > - void *cursor; > - jint argIndex = 0; > - jvalue *argument = request->arguments; > - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); > - > - if (request->clazz != NULL) { > - tossGlobalRef(env, &(request->clazz)); > - } > - if (request->instance != NULL) { > - tossGlobalRef(env, &(request->instance)); > - } > - /* Delete global argument references */ > - while (argIndex < request->argumentCount) { > - if ((argumentTag == JDWP_TAG(OBJECT)) || > - (argumentTag == JDWP_TAG(ARRAY))) { > - if (argument->l != NULL) { > - tossGlobalRef(env, &(argument->l)); > - } > - } > - argument++; > - argIndex++; > - argumentTag = nextArgumentTypeTag(&cursor); > - } > - /* Delete potentially saved return values */ > - if ((request->invokeType == INVOKE_CONSTRUCTOR) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { > - if (request->returnValue.l != NULL) { > - tossGlobalRef(env, &(request->returnValue.l)); > - } > - } > } > > static jvmtiError > @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th > (void)outStream_writeObjectRef(env, &out, exc); > outStream_sendReply(&out); > } > - > - /* > - * At this time, there's no need to retain global references on > - * arguments since the reply is processed. No one will deal with > - * this request ID anymore, so we must call deleteGlobalRefs(). > - */ > - deleteGlobalRefs(env, request); > } > > jboolean > > $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > > From daniel.daugherty at oracle.com Wed Apr 6 23:45:49 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:45:49 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059F3B.1030705@oracle.com> References: <57059D1A.4060000@oracle.com> <57059F3B.1030705@oracle.com> Message-ID: <57059FAD.2080105@oracle.com> Thanks! Dan On 4/6/16 5:43 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty: >> Resending with Jesper and Serguei on directly... >> >> Greetings, >> >> It appears that the fix for this bug: >> >> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-4858370 >> >> has been causing intermittent test failures in the JDK9-hs-rt nightly. >> >> >> ************************************************************ >> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >> ************************************************************ >> >> >> This bug is being using to backout JDK-4858370: >> >> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never >> deleted when >> processing invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-8153673 >> >> Here is the backout webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >> >> Here are the changeset link for JDK-4858370: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >> >> Jesper and Serguei, thanks, in advance, for the reviews! >> >> Gory details below... >> >> Dan >> >> >> >> Here's my jdk repo sanity check note: >> >> Daniel Daugherty added a comment - 1 hour ago >> Sanity checks for backing out this fix and its test: >> >> $ hg log -r 277d7584fa03 >> changeset: 13880:277d7584fa03 >> parent: 13877:645a9be6eddb >> user: sgehwolf >> date: Mon Mar 21 11:24:09 2016 +0100 >> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> >> $ hg status >> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> R test/com/sun/jdi/OomDebugTest.java >> ? files.list >> >> $ hg diff -r 13877 `cat files.list ` >> >> >> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >> 05:30:48 2016 >> +0200 >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >> 14:57:33 2016 >> -0700 >> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >> } >> >> return error; >> -} >> - >> -/* >> - * Delete global references from the request which got put there >> before a >> - * invoke request was carried out. See fillInvokeRequest() and >> invoker invoke*() >> - * impls. >> - */ >> -static void >> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >> -{ >> - void *cursor; >> - jint argIndex = 0; >> - jvalue *argument = request->arguments; >> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >> &cursor); >> - >> - if (request->clazz != NULL) { >> - tossGlobalRef(env, &(request->clazz)); >> - } >> - if (request->instance != NULL) { >> - tossGlobalRef(env, &(request->instance)); >> - } >> - /* Delete global argument references */ >> - while (argIndex < request->argumentCount) { >> - if ((argumentTag == JDWP_TAG(OBJECT)) || >> - (argumentTag == JDWP_TAG(ARRAY))) { >> - if (argument->l != NULL) { >> - tossGlobalRef(env, &(argument->l)); >> - } >> - } >> - argument++; >> - argIndex++; >> - argumentTag = nextArgumentTypeTag(&cursor); >> - } >> - /* Delete potentially saved return values */ >> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >> - if (request->returnValue.l != NULL) { >> - tossGlobalRef(env, &(request->returnValue.l)); >> - } >> - } >> } >> >> static jvmtiError >> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >> (void)outStream_writeObjectRef(env, &out, exc); >> outStream_sendReply(&out); >> } >> - >> - /* >> - * At this time, there's no need to retain global references on >> - * arguments since the reply is processed. No one will deal with >> - * this request ID anymore, so we must call deleteGlobalRefs(). >> - */ >> - deleteGlobalRefs(env, request); >> } >> >> jboolean >> >> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> >> From serguei.spitsyn at oracle.com Wed Apr 6 23:45:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Apr 2016 16:45:41 -0700 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059D1A.4060000@oracle.com> References: <57059D1A.4060000@oracle.com> Message-ID: <57059FA5.9030806@oracle.com> Hi Dan, The fix looks right. Thank you for taking care about the hs-rt stability! It makes sense to back the fix of the 4858370 out at least because it introduced new test that started failing intermittently. The following 3 bugs have similar manifestation and related to the remote invocation of a method or a constructor in the target VM: https://bugs.openjdk.java.net/browse/JDK-8152586 https://bugs.openjdk.java.net/browse/JDK-8152686 https://bugs.openjdk.java.net/browse/JDK-8152985 I'm still in process of isolation of the JDK-8152586 regression. I took a wrong path at some point and need to redo some of my steps. Thanks, Serguei On 4/6/16 16:34, Daniel D. Daugherty wrote: > Resending with Jesper and Serguei on directly... > > Greetings, > > It appears that the fix for this bug: > > JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when > processing > invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-4858370 > > has been causing intermittent test failures in the JDK9-hs-rt nightly. > > > ************************************************************ > I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. > ************************************************************ > > > This bug is being using to backout JDK-4858370: > > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted > when > processing invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-8153673 > > Here is the backout webrev URL: > > http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ > > Here are the changeset link for JDK-4858370: > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 > > Jesper and Serguei, thanks, in advance, for the reviews! > > Gory details below... > > Dan > > > > Here's my jdk repo sanity check note: > > Daniel Daugherty added a comment - 1 hour ago > Sanity checks for backing out this fix and its test: > > $ hg log -r 277d7584fa03 > changeset: 13880:277d7584fa03 > parent: 13877:645a9be6eddb > user: sgehwolf > date: Mon Mar 21 11:24:09 2016 +0100 > summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when > processing invokeMethod command > > $ hg status > M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > R test/com/sun/jdi/OomDebugTest.java > ? files.list > > $ hg diff -r 13877 `cat files.list ` > > > $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 > 05:30:48 2016 +0200 > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 > 14:57:33 2016 -0700 > @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ > } > > return error; > -} > - > -/* > - * Delete global references from the request which got put there > before a > - * invoke request was carried out. See fillInvokeRequest() and > invoker invoke*() > - * impls. > - */ > -static void > -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) > -{ > - void *cursor; > - jint argIndex = 0; > - jvalue *argument = request->arguments; > - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, > &cursor); > - > - if (request->clazz != NULL) { > - tossGlobalRef(env, &(request->clazz)); > - } > - if (request->instance != NULL) { > - tossGlobalRef(env, &(request->instance)); > - } > - /* Delete global argument references */ > - while (argIndex < request->argumentCount) { > - if ((argumentTag == JDWP_TAG(OBJECT)) || > - (argumentTag == JDWP_TAG(ARRAY))) { > - if (argument->l != NULL) { > - tossGlobalRef(env, &(argument->l)); > - } > - } > - argument++; > - argIndex++; > - argumentTag = nextArgumentTypeTag(&cursor); > - } > - /* Delete potentially saved return values */ > - if ((request->invokeType == INVOKE_CONSTRUCTOR) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { > - if (request->returnValue.l != NULL) { > - tossGlobalRef(env, &(request->returnValue.l)); > - } > - } > } > > static jvmtiError > @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th > (void)outStream_writeObjectRef(env, &out, exc); > outStream_sendReply(&out); > } > - > - /* > - * At this time, there's no need to retain global references on > - * arguments since the reply is processed. No one will deal with > - * this request ID anymore, so we must call deleteGlobalRefs(). > - */ > - deleteGlobalRefs(env, request); > } > > jboolean > > $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Apr 6 23:51:35 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:51:35 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059FA5.9030806@oracle.com> References: <57059D1A.4060000@oracle.com> <57059FA5.9030806@oracle.com> Message-ID: <5705A107.1030105@oracle.com> On 4/6/16 5:45 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks right. Thanks! > Thank you for taking care about the hs-rt stability! You are very welcome. > It makes sense to back the fix of the 4858370 out at least because > it introduced new test that started failing intermittently. > > The following 3 bugs have similar manifestation and related to the > remote invocation > of a method or a constructor in the target VM: > https://bugs.openjdk.java.net/browse/JDK-8152586 > https://bugs.openjdk.java.net/browse/JDK-8152686 > https://bugs.openjdk.java.net/browse/JDK-8152985 I wasn't sure that JDK-8152586 was part of the mix because I thought it was first spotted before JDK-4858370 was pushed... but I based that guess on your notes... I suspect that the cleanup of the global refs is happening too early and some things that were relying on those globals refs are now unhappy... but it has been a long time since I've been in that code... Dan > > > I'm still in process of isolation of the JDK-8152586 regression. > I took a wrong path at some point and need to redo some of my steps. > > Thanks, > Serguei > > > On 4/6/16 16:34, Daniel D. Daugherty wrote: >> Resending with Jesper and Serguei on directly... >> >> Greetings, >> >> It appears that the fix for this bug: >> >> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-4858370 >> >> has been causing intermittent test failures in the JDK9-hs-rt nightly. >> >> >> ************************************************************ >> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >> ************************************************************ >> >> >> This bug is being using to backout JDK-4858370: >> >> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted >> when >> processing invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-8153673 >> >> Here is the backout webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >> >> Here are the changeset link for JDK-4858370: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >> >> Jesper and Serguei, thanks, in advance, for the reviews! >> >> Gory details below... >> >> Dan >> >> >> >> Here's my jdk repo sanity check note: >> >> Daniel Daugherty added a comment - 1 hour ago >> Sanity checks for backing out this fix and its test: >> >> $ hg log -r 277d7584fa03 >> changeset: 13880:277d7584fa03 >> parent: 13877:645a9be6eddb >> user: sgehwolf >> date: Mon Mar 21 11:24:09 2016 +0100 >> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >> processing invokeMethod command >> >> $ hg status >> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> R test/com/sun/jdi/OomDebugTest.java >> ? files.list >> >> $ hg diff -r 13877 `cat files.list ` >> >> >> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >> 05:30:48 2016 +0200 >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >> 14:57:33 2016 -0700 >> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >> } >> >> return error; >> -} >> - >> -/* >> - * Delete global references from the request which got put there >> before a >> - * invoke request was carried out. See fillInvokeRequest() and >> invoker invoke*() >> - * impls. >> - */ >> -static void >> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >> -{ >> - void *cursor; >> - jint argIndex = 0; >> - jvalue *argument = request->arguments; >> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >> &cursor); >> - >> - if (request->clazz != NULL) { >> - tossGlobalRef(env, &(request->clazz)); >> - } >> - if (request->instance != NULL) { >> - tossGlobalRef(env, &(request->instance)); >> - } >> - /* Delete global argument references */ >> - while (argIndex < request->argumentCount) { >> - if ((argumentTag == JDWP_TAG(OBJECT)) || >> - (argumentTag == JDWP_TAG(ARRAY))) { >> - if (argument->l != NULL) { >> - tossGlobalRef(env, &(argument->l)); >> - } >> - } >> - argument++; >> - argIndex++; >> - argumentTag = nextArgumentTypeTag(&cursor); >> - } >> - /* Delete potentially saved return values */ >> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >> - if (request->returnValue.l != NULL) { >> - tossGlobalRef(env, &(request->returnValue.l)); >> - } >> - } >> } >> >> static jvmtiError >> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >> (void)outStream_writeObjectRef(env, &out, exc); >> outStream_sendReply(&out); >> } >> - >> - /* >> - * At this time, there's no need to retain global references on >> - * arguments since the reply is processed. No one will deal with >> - * this request ID anymore, so we must call deleteGlobalRefs(). >> - */ >> - deleteGlobalRefs(env, request); >> } >> >> jboolean >> >> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 6 23:58:30 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Apr 2016 16:58:30 -0700 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5705A107.1030105@oracle.com> References: <57059D1A.4060000@oracle.com> <57059FA5.9030806@oracle.com> <5705A107.1030105@oracle.com> Message-ID: <5705A2A6.60505@oracle.com> On 4/6/16 16:51, Daniel D. Daugherty wrote: > On 4/6/16 5:45 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> The fix looks right. > > Thanks! > > >> Thank you for taking care about the hs-rt stability! > > You are very welcome. > > >> It makes sense to back the fix of the 4858370 out at least because >> it introduced new test that started failing intermittently. >> >> The following 3 bugs have similar manifestation and related to the >> remote invocation >> of a method or a constructor in the target VM: >> https://bugs.openjdk.java.net/browse/JDK-8152586 >> https://bugs.openjdk.java.net/browse/JDK-8152686 >> https://bugs.openjdk.java.net/browse/JDK-8152985 > > I wasn't sure that JDK-8152586 was part of the mix because I > thought it was first spotted before JDK-4858370 was pushed... > but I based that guess on your notes... > > I suspect that the cleanup of the global refs is happening > too early and some things that were relying on those globals > refs are now unhappy... but it has been a long time since I've > been in that code... I meditated on the JDK-4858370 fix for some time but did not find anything specifically wrong and was of guesses. One issue with this fix is that it is impossible to track the issue back. Earlier jprt builds fail with OOM on new test as it checks that GlobalRefs are properly deleted. Thanks, Serguei > > Dan > > >> >> >> I'm still in process of isolation of the JDK-8152586 regression. >> I took a wrong path at some point and need to redo some of my steps. >> >> Thanks, >> Serguei >> >> >> On 4/6/16 16:34, Daniel D. Daugherty wrote: >>> Resending with Jesper and Serguei on directly... >>> >>> Greetings, >>> >>> It appears that the fix for this bug: >>> >>> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >>> processing >>> invokeMethod command >>> https://bugs.openjdk.java.net/browse/JDK-4858370 >>> >>> has been causing intermittent test failures in the JDK9-hs-rt nightly. >>> >>> >>> ************************************************************ >>> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >>> ************************************************************ >>> >>> >>> This bug is being using to backout JDK-4858370: >>> >>> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never >>> deleted when >>> processing invokeMethod command >>> https://bugs.openjdk.java.net/browse/JDK-8153673 >>> >>> Here is the backout webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >>> >>> Here are the changeset link for JDK-4858370: >>> >>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >>> >>> Jesper and Serguei, thanks, in advance, for the reviews! >>> >>> Gory details below... >>> >>> Dan >>> >>> >>> >>> Here's my jdk repo sanity check note: >>> >>> Daniel Daugherty added a comment - 1 hour ago >>> Sanity checks for backing out this fix and its test: >>> >>> $ hg log -r 277d7584fa03 >>> changeset: 13880:277d7584fa03 >>> parent: 13877:645a9be6eddb >>> user: sgehwolf >>> date: Mon Mar 21 11:24:09 2016 +0100 >>> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >>> processing invokeMethod command >>> >>> $ hg status >>> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> R test/com/sun/jdi/OomDebugTest.java >>> ? files.list >>> >>> $ hg diff -r 13877 `cat files.list ` >>> >>> >>> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >>> 05:30:48 2016 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >>> 14:57:33 2016 -0700 >>> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >>> } >>> >>> return error; >>> -} >>> - >>> -/* >>> - * Delete global references from the request which got put there >>> before a >>> - * invoke request was carried out. See fillInvokeRequest() and >>> invoker invoke*() >>> - * impls. >>> - */ >>> -static void >>> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >>> -{ >>> - void *cursor; >>> - jint argIndex = 0; >>> - jvalue *argument = request->arguments; >>> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >>> &cursor); >>> - >>> - if (request->clazz != NULL) { >>> - tossGlobalRef(env, &(request->clazz)); >>> - } >>> - if (request->instance != NULL) { >>> - tossGlobalRef(env, &(request->instance)); >>> - } >>> - /* Delete global argument references */ >>> - while (argIndex < request->argumentCount) { >>> - if ((argumentTag == JDWP_TAG(OBJECT)) || >>> - (argumentTag == JDWP_TAG(ARRAY))) { >>> - if (argument->l != NULL) { >>> - tossGlobalRef(env, &(argument->l)); >>> - } >>> - } >>> - argument++; >>> - argIndex++; >>> - argumentTag = nextArgumentTypeTag(&cursor); >>> - } >>> - /* Delete potentially saved return values */ >>> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >>> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >>> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >>> - if (request->returnValue.l != NULL) { >>> - tossGlobalRef(env, &(request->returnValue.l)); >>> - } >>> - } >>> } >>> >>> static jvmtiError >>> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >>> (void)outStream_writeObjectRef(env, &out, exc); >>> outStream_sendReply(&out); >>> } >>> - >>> - /* >>> - * At this time, there's no need to retain global references on >>> - * arguments since the reply is processed. No one will deal with >>> - * this request ID anymore, so we must call deleteGlobalRefs(). >>> - */ >>> - deleteGlobalRefs(env, request); >>> } >>> >>> jboolean >>> >>> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.fazunenko at oracle.com Thu Apr 7 11:24:54 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 7 Apr 2016 14:24:54 +0300 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <5704D7C3.1010905@oracle.com> References: <5704D7C3.1010905@oracle.com> Message-ID: <57064386.9080402@oracle.com> Hi Per, The fix looks good, but a couple of suggestions regarding: GcCapacityTest.java.frames.html 1) -Xmx128 --> -Xmx128m 2) Remove @ignore 8149778 Adding -Xmx should fix 8149778 as well. Thanks, Dima On 06.04.2016 12:32, Per Liden wrote: > Summary: This patch updates the tests in serviceability/tmtools/jstat/ > to use a fixed (and relatively small) heap size. Without this these > tests tend to run out of memory on machines with VM overcommit > disabled. This has happened in nightly testing. > > The patch also moves a misplaced @ignore tag and cleans out an unused > method. > > Testing: Without this patch I can easily get these tests to OOM on my > local workstation by just disabling VM overcommit. They pass with this > patch applied. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 > Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ > > cheers, > Per > From per.liden at oracle.com Thu Apr 7 11:55:22 2016 From: per.liden at oracle.com (Per Liden) Date: Thu, 7 Apr 2016 13:55:22 +0200 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <57064386.9080402@oracle.com> References: <5704D7C3.1010905@oracle.com> <57064386.9080402@oracle.com> Message-ID: <57064AAA.2060405@oracle.com> On 2016-04-07 13:24, Dmitry Fazunenko wrote: > Hi Per, > > The fix looks good, but a couple of suggestions regarding: Thanks Dima! > GcCapacityTest.java.frames.html > > 1) -Xmx128 --> -Xmx128m Ah, thanks for catching that! > > 2) Remove @ignore 8149778 > Adding -Xmx should fix 8149778 as well. I looked at 8149778, but I couldn't convince myself that those timeouts are caused by the same issue. At a glance it looked more like an other bug in the tests. I got the feeling that with -Xcomp C2 optimizes provokeGC() in a way which causes it to not retain the list of objects it's creating. IIRC, the output from the jstat OU counter seems to indicate that the live set was very small, so you'll never reach 70% heap usage and just loop forever. My analysis here could be wrong, but I'd like to keep that tag in this commit, and let Alexander (who is assigned to 8149778) figure out what the fix should be. Ok? cheers, Per > > Thanks, > Dima > > > > On 06.04.2016 12:32, Per Liden wrote: >> Summary: This patch updates the tests in serviceability/tmtools/jstat/ >> to use a fixed (and relatively small) heap size. Without this these >> tests tend to run out of memory on machines with VM overcommit >> disabled. This has happened in nightly testing. >> >> The patch also moves a misplaced @ignore tag and cleans out an unused >> method. >> >> Testing: Without this patch I can easily get these tests to OOM on my >> local workstation by just disabling VM overcommit. They pass with this >> patch applied. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 >> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ >> >> cheers, >> Per >> > From dmitry.fazunenko at oracle.com Thu Apr 7 11:55:17 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 7 Apr 2016 14:55:17 +0300 Subject: RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME In-Reply-To: <57064AAA.2060405@oracle.com> References: <5704D7C3.1010905@oracle.com> <57064386.9080402@oracle.com> <57064AAA.2060405@oracle.com> Message-ID: <57064AA5.2070902@oracle.com> Per, On 07.04.2016 14:55, Per Liden wrote: > On 2016-04-07 13:24, Dmitry Fazunenko wrote: >> Hi Per, >> >> The fix looks good, but a couple of suggestions regarding: > > Thanks Dima! > >> GcCapacityTest.java.frames.html >> >> 1) -Xmx128 --> -Xmx128m > > Ah, thanks for catching that! > >> >> 2) Remove @ignore 8149778 >> Adding -Xmx should fix 8149778 as well. > > I looked at 8149778, but I couldn't convince myself that those > timeouts are caused by the same issue. At a glance it looked more like > an other bug in the tests. I got the feeling that with -Xcomp C2 > optimizes provokeGC() in a way which causes it to not retain the list > of objects it's creating. IIRC, the output from the jstat OU counter > seems to indicate that the live set was very small, so you'll never > reach 70% heap usage and just loop forever. My analysis here could be > wrong, but I'd like to keep that tag in this commit, and let Alexander > (who is assigned to 8149778) figure out what the fix should be. Ok? Okay, let's keep @ignore there. Thanks for looking at the bug. -- Dima > > cheers, > Per > >> >> Thanks, >> Dima >> >> >> >> On 06.04.2016 12:32, Per Liden wrote: >>> Summary: This patch updates the tests in serviceability/tmtools/jstat/ >>> to use a fixed (and relatively small) heap size. Without this these >>> tests tend to run out of memory on machines with VM overcommit >>> disabled. This has happened in nightly testing. >>> >>> The patch also moves a misplaced @ignore tag and cleans out an unused >>> method. >>> >>> Testing: Without this patch I can easily get these tests to OOM on my >>> local workstation by just disabling VM overcommit. They pass with this >>> patch applied. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989 >>> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/ >>> >>> cheers, >>> Per >>> >> From cheleswer.sahu at oracle.com Thu Apr 7 13:50:21 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 7 Apr 2016 06:50:21 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <5703BDD1.5090108@oracle.com> References: <5703BDD1.5090108@oracle.com> Message-ID: Hi , Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ Regards, Cheleswer -----Original Message----- From: Leonid Mesnik Sent: Tuesday, April 05, 2016 7:00 PM To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Hi I don't think that sleep is a good way to ensure that thread is started. It is not reliable on the slow host / VM under stress and just waste of time on fast host. Is it possible just to add any explicit synchronization to ensure that NamedThread is started? Leonid On 05.04.2016 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. > > > > > > Regards, > > Cheleswer > > > > From Leonid.Mesnik at oracle.com Thu Apr 7 13:53:56 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 7 Apr 2016 16:53:56 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: <5703BDD1.5090108@oracle.com> Message-ID: <57066674.9080502@oracle.com> Hi Thank you for improving test stability. I am fine with fix. I am not 'R'eviewer so you still need to get official review. Leonid On 07.04.2016 16:50, Cheleswer Sahu wrote: > Hi , > Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link > > http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ > > > Regards, > Cheleswer > -----Original Message----- > From: Leonid Mesnik > Sent: Tuesday, April 05, 2016 7:00 PM > To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails > > Hi > > I don't think that sleep is a good way to ensure that thread is started. > It is not reliable on the slow host / VM under stress and just waste of time on fast host. > Is it possible just to add any explicit synchronization to ensure that NamedThread is started? > > Leonid > > On 05.04.2016 13:23, Cheleswer Sahu wrote: >> Hi, >> >> >> >> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >> >> >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >> >> >> >> >> >> Bug Brief: Test is failing on some platforms. >> >> >> >> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >> >> >> >> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >> >> >> >> >> >> Regards, >> >> Cheleswer >> >> >> >> From dmitry.samersoff at oracle.com Thu Apr 7 14:12:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 7 Apr 2016 17:12:08 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: <5703BDD1.5090108@oracle.com> Message-ID: <57066AB8.4000808@oracle.com> Cheleswer, Looks good for me. Reviewed. -Dmitry On 2016-04-07 16:50, Cheleswer Sahu wrote: > Hi , > Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link > > http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ > > > Regards, > Cheleswer > -----Original Message----- > From: Leonid Mesnik > Sent: Tuesday, April 05, 2016 7:00 PM > To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails > > Hi > > I don't think that sleep is a good way to ensure that thread is started. > It is not reliable on the slow host / VM under stress and just waste of time on fast host. > Is it possible just to add any explicit synchronization to ensure that NamedThread is started? > > Leonid > > On 05.04.2016 13:23, Cheleswer Sahu wrote: >> Hi, >> >> >> >> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >> >> >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >> >> >> >> >> >> Bug Brief: Test is failing on some platforms. >> >> >> >> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >> >> >> >> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >> >> >> >> >> >> Regards, >> >> Cheleswer >> >> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu Apr 7 14:22:27 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Apr 2016 08:22:27 -0600 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <57066AB8.4000808@oracle.com> References: <5703BDD1.5090108@oracle.com> <57066AB8.4000808@oracle.com> Message-ID: <57066D23.4090505@oracle.com> Cheleswer, When you re-sync with the current JDK9-hs-rt, you'll have to re-enable this test. It was quarantined yesterday with this fix: JDK-8153671 Quarantine serviceability/tmtools/jstack/JstackThreadTest.java until JDK-8153319 is fixed https://bugs.openjdk.java.net/browse/JDK-8153671 You just need to remove the @ignore line. Dan On 4/7/16 8:12 AM, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me. Reviewed. > > -Dmitry > > On 2016-04-07 16:50, Cheleswer Sahu wrote: >> Hi , >> Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link >> >> http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ >> >> >> Regards, >> Cheleswer >> -----Original Message----- >> From: Leonid Mesnik >> Sent: Tuesday, April 05, 2016 7:00 PM >> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails >> >> Hi >> >> I don't think that sleep is a good way to ensure that thread is started. >> It is not reliable on the slow host / VM under stress and just waste of time on fast host. >> Is it possible just to add any explicit synchronization to ensure that NamedThread is started? >> >> Leonid >> >> On 05.04.2016 13:23, Cheleswer Sahu wrote: >>> Hi, >>> >>> >>> >>> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >>> >>> >>> >>> >>> >>> Bug Brief: Test is failing on some platforms. >>> >>> >>> >>> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >>> >>> >>> >>> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> >>> >>> >>> > From cheleswer.sahu at oracle.com Thu Apr 7 15:23:28 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 7 Apr 2016 08:23:28 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <57066D23.4090505@oracle.com> References: <5703BDD1.5090108@oracle.com> <57066AB8.4000808@oracle.com> <57066D23.4090505@oracle.com> Message-ID: <6a053489-2529-44a3-9385-876df6957a42@default> Thanks Dmitry and Leonid for review. Thanks Dan for information, I will do the needful before pushing this fix. Regards, Cheleswer -----Original Message----- From: Daniel D. Daugherty Sent: Thursday, April 07, 2016 7:52 PM To: Dmitry Samersoff; Cheleswer Sahu; Leonid Mesnik; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; Filipp Zhinkin Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Cheleswer, When you re-sync with the current JDK9-hs-rt, you'll have to re-enable this test. It was quarantined yesterday with this fix: JDK-8153671 Quarantine serviceability/tmtools/jstack/JstackThreadTest.java until JDK-8153319 is fixed https://bugs.openjdk.java.net/browse/JDK-8153671 You just need to remove the @ignore line. Dan On 4/7/16 8:12 AM, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me. Reviewed. > > -Dmitry > > On 2016-04-07 16:50, Cheleswer Sahu wrote: >> Hi , >> Thanks for your review and suggestion. I agree that sleep is not the >> best and reliable way to achieve the objective of test case. I also >> found the idea of using j.u.c.CountDownLatch very easy and >> effective. I have made some changes in the code. Please review the >> code changes in the below link >> >> http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ >> >> >> Regards, >> Cheleswer >> -----Original Message----- >> From: Leonid Mesnik >> Sent: Tuesday, April 05, 2016 7:00 PM >> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8153319: new test >> serviceability/tmtools/jstack/JstackThreadTest.java fails >> >> Hi >> >> I don't think that sleep is a good way to ensure that thread is started. >> It is not reliable on the slow host / VM under stress and just waste of time on fast host. >> Is it possible just to add any explicit synchronization to ensure that NamedThread is started? >> >> Leonid >> >> On 05.04.2016 13:23, Cheleswer Sahu wrote: >>> Hi, >>> >>> >>> >>> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >>> >>> >>> >>> >>> >>> Bug Brief: Test is failing on some platforms. >>> >>> >>> >>> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >>> >>> >>> >>> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> >>> >>> >>> > From chris.hegarty at oracle.com Thu Apr 7 17:14:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Apr 2016 18:14:56 +0100 Subject: RFR [9] 8153737: Unsupported Module Message-ID: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized ). The jdk.unsupported module will be present in full JRE and JDK images. http://cr.openjdk.java.net/~chegar/8153737/ https://bugs.openjdk.java.net/browse/JDK-8153737 Summary of the changes: - Restructure, what remains of, the sources in sun/misc to reflect the new modular layout. There are still a few non-Critical APIs in sun.misc that will be addressed later. - Add dependencies from several JDK modules to jdk.unsupported. All dependencies have issues tracking them, and should be removed in 9. - The test library in the top-level repo provides a convenience to tests to retrieve Unsafe. This has been updated to the "real" internal Unsafe, so there are many many tests that require to be updated, mostly the @modules tags. ( The Unsafe dependency in the library should probably be revisited at some point, as it requires many tests, not wishing to use Unsafe, to require an explicit dependency on it ) Note: with recent work from Mikael [2], sun.misc.Unsafe is now just a delegate for the "real" internal Unsafe, so it is time to move the tests to use it directly. - Cleanup any tests unnecessarily/incorrectly declaring a dependency on sun.misc ( this could have been unnecessarily added, been refactored out at one point, or the library upon which the tests depends refactored, that the dependency is no longer required ). I'm sure further cleanup could be done, but this is sufficient for now. - A small number of test in hotspot/test/compiler/unsafe, which are generated, have been updated, along with the generation script, to depend on jdk.unsupported/sun.misc ( they explicitly test the sun.misc version ) All 'core', 'pit', and 'hotspot' testsets have been successfully run on Mac, Linux, Windows, and Solaris. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8149159 From dmitry.samersoff at oracle.com Thu Apr 7 17:56:11 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 7 Apr 2016 20:56:11 +0300 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing Message-ID: <57069F3B.4020908@oracle.com> Everybody, Please review small changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ Test that is not expected to work on OS X, detect OS X and exits. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From tim.bell at oracle.com Thu Apr 7 18:13:49 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 07 Apr 2016 11:13:49 -0700 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <57069F3B.4020908@oracle.com> References: <57069F3B.4020908@oracle.com> Message-ID: <5706A35D.60301@oracle.com> On 04/07/16 10:56, Dmitry Samersoff wrote: > Everybody, > > Please review small changes. Note: I am not a "R"eviewer in Serviceability. Free advice follows: > http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ > > Test that is not expected to work on OS X, detect OS X and exits. 84 // Coredump stackwalking is not implemented for Darwin 85 System.err.println("Error! This test is not expected to work on OS X."); It is not implemented, so landing here during a test run on Mac OS should not be surprising. Rather than printing 'Error!' I suggest removing that alarming string, as on line 107 . My 0x02 cents. Tim From serguei.spitsyn at oracle.com Thu Apr 7 18:35:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Apr 2016 11:35:18 -0700 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <5706A35D.60301@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> Message-ID: <5706A866.7050406@oracle.com> Dmitry, I agree with Tim. The message at L85 should not be alarming but look similar to the one at L107. Something, like this: 85 System.out.println("This test is not expected to work on OS X. Skipping"); Thanks, Serguei On 4/7/16 11:13, Tim Bell wrote: > On 04/07/16 10:56, Dmitry Samersoff wrote: >> Everybody, >> >> Please review small changes. > > Note: I am not a "R"eviewer in Serviceability. Free advice follows: > >> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >> >> Test that is not expected to work on OS X, detect OS X and exits. > > 84 // Coredump stackwalking is not implemented for Darwin > 85 System.err.println("Error! This test is not expected > to work on OS X."); > > > It is not implemented, so landing here during a test run on Mac OS > should not be surprising. > > Rather than printing 'Error!' I suggest removing that alarming string, > as on line 107 . > > My 0x02 cents. > > Tim > > From Alan.Bateman at oracle.com Thu Apr 7 18:57:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Apr 2016 19:57:24 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <5706AD94.8030701@oracle.com> On 07/04/2016 18:14, Chris Hegarty wrote: > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ It's great to get to this milestone. I looked over the webrev and I don't see any issues. I'm surprised by the number of tests that had @modules java.base/sun.misc even though they aren't using anything in sun.misc. I see Phil has pushed JDK-8147544 to jdk9/client rather than jdk9/dev so it means that the module-info.java for java.desktop will need to be fixed up when it gets to jdk9/dev. I think we should bump the priority of all the issues that cause you to add `requires jdk.unsupported`we should at least get all of them resolved by FC as we shouldn't have any standard modules with this dependence. -Alan. From mandy.chung at oracle.com Fri Apr 8 02:52:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Apr 2016 19:52:03 -0700 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> > On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 I?m glad to see jdk.unsupported module be created. jdeps tests are intended to test references to sun.misc and flagged as internal API. The jdeps test changes should be reverted. It?s exported to allow existing applications to continue to run on JDK 9 while sun.misc and other critical internal APIs remains to be internal APIs. jdeps -jdkinternals should flag them and get developers? attention to prepare to migrate when the replacements are available. Other than that, looks good. There are so many tests that have @modules java.base sun/misc but unused. It?s good that you clean that up. I agree with Alan that JDK modules depending on jdk.unsupported should get the priority to get eliminated by FC. thanks Mandy From robbin.ehn at oracle.com Fri Apr 8 08:08:36 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 10:08:36 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) Message-ID: <57076704.6020700@oracle.com> Hi all, Please review, Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 Tested with internal vm test (inc a new test for just this). Thanks! /Robbin From staffan.larsen at oracle.com Fri Apr 8 08:10:35 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Apr 2016 10:10:35 +0200 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <5706A866.7050406@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> <5706A866.7050406@oracle.com> Message-ID: <625D8F31-BECB-4055-B630-44C80324D61F@oracle.com> Why did this test start failing? > On 7 apr. 2016, at 20:35, serguei.spitsyn at oracle.com wrote: > > Dmitry, > > I agree with Tim. > The message at L85 should not be alarming but look similar to the one at L107. > Something, like this: > 85 System.out.println("This test is not expected to work on OS X. Skipping"); > > > Thanks, > Serguei > > > On 4/7/16 11:13, Tim Bell wrote: >> On 04/07/16 10:56, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review small changes. >> >> Note: I am not a "R"eviewer in Serviceability. Free advice follows: >> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >>> >>> Test that is not expected to work on OS X, detect OS X and exits. >> >> 84 // Coredump stackwalking is not implemented for Darwin >> 85 System.err.println("Error! This test is not expected to work on OS X."); >> >> >> It is not implemented, so landing here during a test run on Mac OS should not be surprising. >> >> Rather than printing 'Error!' I suggest removing that alarming string, as on line 107 . >> >> My 0x02 cents. >> >> Tim >> >> > From dmitry.samersoff at oracle.com Fri Apr 8 09:54:07 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 8 Apr 2016 12:54:07 +0300 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <625D8F31-BECB-4055-B630-44C80324D61F@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> <5706A866.7050406@oracle.com> <625D8F31-BECB-4055-B630-44C80324D61F@oracle.com> Message-ID: <57077FBF.8020801@oracle.com> Staffan, I suspect its because of root/non-root. OS X attach doesn't work for non-root user. Test check it and skips silently. But if the test run under root, it tries to run and then fail. -Dmitry On 2016-04-08 11:10, Staffan Larsen wrote: > Why did this test start failing? > >> On 7 apr. 2016, at 20:35, serguei.spitsyn at oracle.com wrote: >> >> Dmitry, >> >> I agree with Tim. >> The message at L85 should not be alarming but look similar to the one at L107. >> Something, like this: >> 85 System.out.println("This test is not expected to work on OS X. Skipping"); >> >> >> Thanks, >> Serguei >> >> >> On 4/7/16 11:13, Tim Bell wrote: >>> On 04/07/16 10:56, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review small changes. >>> >>> Note: I am not a "R"eviewer in Serviceability. Free advice follows: >>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >>>> >>>> Test that is not expected to work on OS X, detect OS X and exits. >>> >>> 84 // Coredump stackwalking is not implemented for Darwin >>> 85 System.err.println("Error! This test is not expected to work on OS X."); >>> >>> >>> It is not implemented, so landing here during a test run on Mac OS should not be surprising. >>> >>> Rather than printing 'Error!' I suggest removing that alarming string, as on line 107 . >>> >>> My 0x02 cents. >>> >>> Tim >>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri Apr 8 10:01:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 8 Apr 2016 13:01:34 +0300 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <5706A866.7050406@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> <5706A866.7050406@oracle.com> Message-ID: <5707817E.6040103@oracle.com> Tim, Serguei, Thank you for the review. The message updated (in-place, press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ -Dmitry On 2016-04-07 21:35, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I agree with Tim. > The message at L85 should not be alarming but look similar to the one at > L107. > Something, like this: > 85 System.out.println("This test is not expected to work on OS > X. Skipping"); > > > Thanks, > Serguei > > > On 4/7/16 11:13, Tim Bell wrote: >> On 04/07/16 10:56, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review small changes. >> >> Note: I am not a "R"eviewer in Serviceability. Free advice follows: >> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >>> >>> Test that is not expected to work on OS X, detect OS X and exits. >> >> 84 // Coredump stackwalking is not implemented for Darwin >> 85 System.err.println("Error! This test is not expected >> to work on OS X."); >> >> >> It is not implemented, so landing here during a test run on Mac OS >> should not be surprising. >> >> Rather than printing 'Error!' I suggest removing that alarming string, >> as on line 107 . >> >> My 0x02 cents. >> >> Tim >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Apr 8 10:04:43 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Apr 2016 03:04:43 -0700 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <5707817E.6040103@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> <5706A866.7050406@oracle.com> <5707817E.6040103@oracle.com> Message-ID: <5707823B.8010905@oracle.com> Dmitry, + System.err.println("This test is not expected to work on OS X. Skipping"); I think, it has to be System.out, not System err (the same as at L107). No need to re-review if you fix it. Thanks, Serguei On 4/8/16 03:01, Dmitry Samersoff wrote: > Tim, Serguei, > > Thank you for the review. > > The message updated (in-place, press shift-reload) > > http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ > > -Dmitry > > On 2016-04-07 21:35, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> I agree with Tim. >> The message at L85 should not be alarming but look similar to the one at >> L107. >> Something, like this: >> 85 System.out.println("This test is not expected to work on OS >> X. Skipping"); >> >> >> Thanks, >> Serguei >> >> >> On 4/7/16 11:13, Tim Bell wrote: >>> On 04/07/16 10:56, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review small changes. >>> Note: I am not a "R"eviewer in Serviceability. Free advice follows: >>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >>>> >>>> Test that is not expected to work on OS X, detect OS X and exits. >>> 84 // Coredump stackwalking is not implemented for Darwin >>> 85 System.err.println("Error! This test is not expected >>> to work on OS X."); >>> >>> >>> It is not implemented, so landing here during a test run on Mac OS >>> should not be surprising. >>> >>> Rather than printing 'Error!' I suggest removing that alarming string, >>> as on line 107 . >>> >>> My 0x02 cents. >>> >>> Tim >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Fri Apr 8 10:24:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 12:24:08 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: > On 7 Apr 2016, at 19:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > And in the modular world it?s necessary to explicitly declare a requirement on idk.unsupported. > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 > +1 An important milestone. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.larsen at oracle.com Fri Apr 8 10:27:49 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Apr 2016 12:27:49 +0200 Subject: RFR(XS): JDK-8152679 DeadlockDetectionTest.java fails due to expected output missing In-Reply-To: <57077FBF.8020801@oracle.com> References: <57069F3B.4020908@oracle.com> <5706A35D.60301@oracle.com> <5706A866.7050406@oracle.com> <625D8F31-BECB-4055-B630-44C80324D61F@oracle.com> <57077FBF.8020801@oracle.com> Message-ID: <2B8201D0-34FA-4BCE-A952-BA2890A8F51A@oracle.com> I see - thanks! > On 8 apr. 2016, at 11:54, Dmitry Samersoff wrote: > > Staffan, > > I suspect its because of root/non-root. OS X attach doesn't work for > non-root user. Test check it and skips silently. But if the test run > under root, it tries to run and then fail. > > -Dmitry > > On 2016-04-08 11:10, Staffan Larsen wrote: >> Why did this test start failing? >> >>> On 7 apr. 2016, at 20:35, serguei.spitsyn at oracle.com wrote: >>> >>> Dmitry, >>> >>> I agree with Tim. >>> The message at L85 should not be alarming but look similar to the one at L107. >>> Something, like this: >>> 85 System.out.println("This test is not expected to work on OS X. Skipping"); >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/7/16 11:13, Tim Bell wrote: >>>> On 04/07/16 10:56, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review small changes. >>>> >>>> Note: I am not a "R"eviewer in Serviceability. Free advice follows: >>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8152679/webrev.01/ >>>>> >>>>> Test that is not expected to work on OS X, detect OS X and exits. >>>> >>>> 84 // Coredump stackwalking is not implemented for Darwin >>>> 85 System.err.println("Error! This test is not expected to work on OS X."); >>>> >>>> >>>> It is not implemented, so landing here during a test run on Mac OS should not be surprising. >>>> >>>> Rather than printing 'Error!' I suggest removing that alarming string, as on line 107 . >>>> >>>> My 0x02 cents. >>>> >>>> Tim >>>> >>>> >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Fri Apr 8 11:54:16 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 13:54:16 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert Message-ID: <57079BE8.5000507@oracle.com> Hi all, Please review, Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 Tested with jprt. diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level is incorrect"); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks! /Robbin From stefan.karlsson at oracle.com Fri Apr 8 12:02:40 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 8 Apr 2016 14:02:40 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57076704.6020700@oracle.com> References: <57076704.6020700@oracle.com> Message-ID: <57079DE0.2080103@oracle.com> Looks good. StefanK On 2016-04-08 10:08, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 > > Tested with internal vm test (inc a new test for just this). > > Thanks! > > /Robbin From robbin.ehn at oracle.com Fri Apr 8 12:11:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:11:51 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57079DE0.2080103@oracle.com> References: <57076704.6020700@oracle.com> <57079DE0.2080103@oracle.com> Message-ID: <5707A007.8000602@oracle.com> Thanks Stefan! /Robbin On 04/08/2016 02:02 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-08 10:08, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 >> >> Tested with internal vm test (inc a new test for just this). >> >> Thanks! >> >> /Robbin > From marcus.larsson at oracle.com Fri Apr 8 12:19:59 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 14:19:59 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <57079BE8.5000507@oracle.com> References: <57079BE8.5000507@oracle.com> Message-ID: <5707A1EF.6080306@oracle.com> Hi Robbin, On 04/08/2016 01:54 PM, Robbin Ehn wrote: > > Hi all, > > Please review, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 > > Tested with jprt. > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 > +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 > +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log > level is incorrect"); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > Can we make the assert check "level >= LogLevel::First && level <= LogLevel::Last" instead? Thanks, Marcus > > Thanks! > > /Robbin From bengt.rutisson at oracle.com Fri Apr 8 12:16:45 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 8 Apr 2016 14:16:45 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A1EF.6080306@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> Message-ID: <5707A12D.50903@oracle.com> Hi Robbin, On 2016-04-08 14:19, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >> level is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> > > Can we make the assert check "level >= LogLevel::First && level <= > LogLevel::Last" instead? And can we make the error message include the actual value of "level" so we know why the assert failed? Thanks, Bengt > > Thanks, > Marcus > >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 12:22:10 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:22:10 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A1EF.6080306@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> Message-ID: <5707A272.90207@oracle.com> Hi Marcus On 04/08/2016 02:19 PM, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >> level is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> > > Can we make the assert check "level >= LogLevel::First && level <= > LogLevel::Last" instead? Yes, I have no issues with that. /Robbin > > Thanks, > Marcus > >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 12:24:15 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:24:15 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A12D.50903@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> <5707A12D.50903@oracle.com> Message-ID: <5707A2EF.3090201@oracle.com> Hi Bengt, On 04/08/2016 02:16 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:19, Marcus Larsson wrote: >> Hi Robbin, >> >> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>> >>> Hi all, >>> >>> Please review, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>> >>> Tested with jprt. >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>> level is incorrect"); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> >> >> Can we make the assert check "level >= LogLevel::First && level <= >> LogLevel::Last" instead? > > And can we make the error message include the actual value of "level" so > we know why the assert failed? > Yes, no problem. Thanks! /Robbin > Thanks, > Bengt > >> >> Thanks, >> Marcus >> >>> >>> Thanks! >>> >>> /Robbin >> > From robbin.ehn at oracle.com Fri Apr 8 12:28:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:28:00 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <57079BE8.5000507@oracle.com> References: <57079BE8.5000507@oracle.com> Message-ID: <5707A3D0.8010207@oracle.com> Hi all, Updated after reviews: diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log level:%d is incorrect", level); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks! /Robbin On 04/08/2016 01:54 PM, Robbin Ehn wrote: > > Hi all, > > Please review, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 > > Tested with jprt. > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level > is incorrect"); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > > > Thanks! > > /Robbin From robbin.ehn at oracle.com Fri Apr 8 12:44:21 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:44:21 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5704B0B0.4010404@oracle.com> References: <5704B0B0.4010404@oracle.com> Message-ID: <5707A7A5.5010302@oracle.com> Hi Marcus Your change looks good. Thanks! /Robbin On 04/06/2016 08:46 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add a warning for when tag > selections in -Xlog or VM.log don't match any tag sets used in the VM. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8150894 > > Testing: > Internal VM tests with RBT > > Thanks, > Marcus From robbin.ehn at oracle.com Fri Apr 8 12:45:45 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:45:45 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A3D0.8010207@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> Message-ID: <5707A7F9.70701@oracle.com> Hi again, I missed LogLevel:Off, it should be: diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log level:%d is incorrect", level); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks ! /Robbin On 04/08/2016 02:28 PM, Robbin Ehn wrote: > Hi all, > > Updated after reviews: > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log > level:%d is incorrect", level); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > Thanks! > > /Robbin > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >> is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> >> >> Thanks! >> >> /Robbin From marcus.larsson at oracle.com Fri Apr 8 12:48:02 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 14:48:02 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57076704.6020700@oracle.com> References: <57076704.6020700@oracle.com> Message-ID: <5707A882.6040900@oracle.com> Hi Robbin, On 04/08/2016 10:08 AM, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ I just have one suggestion for a slightly better assert message: "Combination limit (" SIZE_FORMAT ") not sufficient for configuring all available tag sets (" SIZE_FORMAT ")" Other than that, this looks good. Thanks for fixing this! I don't need to see another webrev. Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 > > Tested with internal vm test (inc a new test for just this). > > Thanks! > > /Robbin From robbin.ehn at oracle.com Fri Apr 8 13:23:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:23:17 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <5707A882.6040900@oracle.com> References: <57076704.6020700@oracle.com> <5707A882.6040900@oracle.com> Message-ID: <5707B0C5.1080108@oracle.com> Hi Marcus On 04/08/2016 02:48 PM, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 10:08 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ > > I just have one suggestion for a slightly better assert message: > "Combination limit (" SIZE_FORMAT ") not sufficient for configuring all > available tag sets (" SIZE_FORMAT ")" > I'll change the message, thanks! /Robbin > Other than that, this looks good. Thanks for fixing this! I don't need > to see another webrev. > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 >> >> Tested with internal vm test (inc a new test for just this). >> >> Thanks! >> >> /Robbin > From bengt.rutisson at oracle.com Fri Apr 8 13:26:50 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 8 Apr 2016 15:26:50 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A7F9.70701@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> Message-ID: <5707B19A.1070005@oracle.com> Hi Robbin, On 2016-04-08 14:45, Robbin Ehn wrote: > Hi again, > > I missed LogLevel:Off, it should be: > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 > +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 > +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log > level:%d is incorrect", level); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); Looks good. Bengt > > > Thanks ! > > /Robbin > > On 04/08/2016 02:28 PM, Robbin Ehn wrote: >> Hi all, >> >> Updated after reviews: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> Thanks! >> >> /Robbin >> >> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>> >>> Hi all, >>> >>> Please review, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>> >>> Tested with jprt. >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >>> is incorrect"); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> >>> >>> Thanks! >>> >>> /Robbin From robbin.ehn at oracle.com Fri Apr 8 13:38:20 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:38:20 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B19A.1070005@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> Message-ID: <5707B44C.8060007@oracle.com> Thanks Bengt! /Robbin On 04/08/2016 03:26 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:45, Robbin Ehn wrote: >> Hi again, >> >> I missed LogLevel:Off, it should be: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); > > Looks good. > > Bengt > >> >> >> Thanks ! >> >> /Robbin >> >> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated after reviews: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>> >>>> Hi all, >>>> >>>> Please review, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>> >>>> Tested with jprt. >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >>>> is incorrect"); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> >>>> >>>> Thanks! >>>> >>>> /Robbin > From marcus.larsson at oracle.com Fri Apr 8 13:41:25 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 15:41:25 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B19A.1070005@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> Message-ID: <5707B505.1090506@oracle.com> On 04/08/2016 03:26 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:45, Robbin Ehn wrote: >> Hi again, >> >> I missed LogLevel:Off, it should be: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); > > Looks good. +1 Marcus > > Bengt > >> >> >> Thanks ! >> >> /Robbin >> >> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated after reviews: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>> >>>> Hi all, >>>> >>>> Please review, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>> >>>> Tested with jprt. >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>>> level >>>> is incorrect"); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> >>>> >>>> Thanks! >>>> >>>> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 13:40:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:40:57 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B505.1090506@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> <5707B505.1090506@oracle.com> Message-ID: <5707B4E9.3070502@oracle.com> Thanks Marcus! /Robbin On 04/08/2016 03:41 PM, Marcus Larsson wrote: > > > On 04/08/2016 03:26 PM, Bengt Rutisson wrote: >> >> Hi Robbin, >> >> On 2016-04-08 14:45, Robbin Ehn wrote: >>> Hi again, >>> >>> I missed LogLevel:Off, it should be: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >> >> Looks good. > > +1 > > Marcus > >> >> Bengt >> >>> >>> >>> Thanks ! >>> >>> /Robbin >>> >>> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Updated after reviews: >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>>> level:%d is incorrect", level); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>>> >>>>> Tested with jprt. >>>>> >>>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>>> +0200 >>>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>>> +0200 >>>>> @@ -98,6 +98,7 @@ >>>>> const size_t vwrite_buffer_size = 512; >>>>> >>>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>>> args) { >>>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>>>> level >>>>> is incorrect"); >>>>> char buf[vwrite_buffer_size]; >>>>> va_list saved_args; // For re-format on buf overflow. >>>>> va_copy(saved_args, args); >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >> > From marcus.larsson at oracle.com Fri Apr 8 14:24:15 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 16:24:15 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5707A7A5.5010302@oracle.com> References: <5704B0B0.4010404@oracle.com> <5707A7A5.5010302@oracle.com> Message-ID: <5707BF0F.9020603@oracle.com> Thanks Robbin! Marcus On 04/08/2016 02:44 PM, Robbin Ehn wrote: > Hi Marcus > > Your change looks good. > > Thanks! > > /Robbin > > On 04/06/2016 08:46 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add a warning for when tag >> selections in -Xlog or VM.log don't match any tag sets used in the VM. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8150894 >> >> Testing: >> Internal VM tests with RBT >> >> Thanks, >> Marcus From peter.levart at gmail.com Fri Apr 8 14:31:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 8 Apr 2016 16:31:32 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <5707C0C4.1070209@gmail.com> On 04/08/2016 12:24 PM, Paul Sandoz wrote: >> On 7 Apr 2016, at 19:14, Chris Hegarty wrote: >> >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> > And in the modular world it?s necessary to explicitly declare a requirement on idk.unsupported. Will jdk.unsupported be "required public" by java.se? Will you have to explicitly -addmodule jdk.unsupported for class-path programs too? Regards, Peter > >> http://cr.openjdk.java.net/~chegar/8153737/ >> https://bugs.openjdk.java.net/browse/JDK-8153737 >> > +1 > > An important milestone. > > Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Apr 8 14:37:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 15:37:39 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707C0C4.1070209@gmail.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5707C0C4.1070209@gmail.com> Message-ID: <5707C233.6010509@oracle.com> On 08/04/16 15:31, Peter Levart wrote: > > > On 04/08/2016 12:24 PM, Paul Sandoz wrote: >>> On 7 Apr 2016, at 19:14, Chris Hegarty wrote: >>> >>> Enough technical debt has been paid down that we can now create the new >>> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >>> This module will initially contain, and export, the sun.misc package, >>> and will eventually export the sun.reflect package too ( once it has >>> been sanitized ). The jdk.unsupported module will be present in full JRE >>> and JDK images. >>> >> And in the modular world it?s necessary to explicitly declare a >> requirement on idk.unsupported. > > Will jdk.unsupported be "required public" by java.se? No. Since jdk.unsupported will be in the JDK and JRE images, and it exports sun.misc, then it will be available ( see below ). > Will you have to > explicitly -addmodule jdk.unsupported for class-path programs too? Applications running on the class path will be able to access sun.misc without any command line flags, since it is exported. Modular applications, if they wish to use sun.misc, will have to 'require jdk.unsupported'. -Chris. > Regards, Peter > >> >>> http://cr.openjdk.java.net/~chegar/8153737/ >>> https://bugs.openjdk.java.net/browse/JDK-8153737 >>> >> +1 >> >> An important milestone. >> >> Paul. > From Alan.Bateman at oracle.com Fri Apr 8 14:42:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Apr 2016 15:42:27 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707C0C4.1070209@gmail.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5707C0C4.1070209@gmail.com> Message-ID: <5707C353.8030902@oracle.com> On 08/04/2016 15:31, Peter Levart wrote: > > Will jdk.unsupported be "required public" by java.se? No because jdk.* are JDK-specific and should never be required by standard modules. > Will you have to explicitly -addmodule jdk.unsupported for class-path > programs too? It exports an API and therefore will be treated as a root module, so no -addmods. If you develop your own module that uses sun.misc.Unsafe then it will of course need to declare its dependency on jdk.unsupported. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Apr 8 15:22:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 16:22:56 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5706AD94.8030701@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5706AD94.8030701@oracle.com> Message-ID: <5707CCD0.30005@oracle.com> On 07/04/16 19:57, Alan Bateman wrote: > On 07/04/2016 18:14, Chris Hegarty wrote: >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> >> http://cr.openjdk.java.net/~chegar/8153737/ > It's great to get to this milestone. > > I looked over the webrev and I don't see any issues. Thanks for the Review. > I'm surprised by > the number of tests that had @modules java.base/sun.misc even though > they aren't using anything in sun.misc. It was surprising to me too. > I see Phil has pushed JDK-8147544 to jdk9/client rather than jdk9/dev so > it means that the module-info.java for java.desktop will need to be > fixed up when it gets to jdk9/dev. Right. I have my eye on that, and will fix it once in jdk9/dev. > I think we should bump the priority of all the issues that cause you to > add `requires jdk.unsupported`we should at least get all of them > resolved by FC as we shouldn't have any standard modules with this > dependence. I bumped the priority, and targeted the issues to 9. -Chris. From chris.hegarty at oracle.com Fri Apr 8 15:35:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 16:35:23 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> Message-ID: <5707CFBB.8020809@oracle.com> On 08/04/16 03:52, Mandy Chung wrote: > >> On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: >> >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> >> http://cr.openjdk.java.net/~chegar/8153737/ >> https://bugs.openjdk.java.net/browse/JDK-8153737 > > I?m glad to see jdk.unsupported module be created. > > jdeps tests are intended to test references to sun.misc and flagged as internal API. The jdeps test changes should be reverted. > > It?s exported to allow existing applications to continue to run on JDK 9 while sun.misc and other critical internal APIs remains to be internal APIs. jdeps -jdkinternals should flag them and get developers? attention to prepare to migrate when the replacements are available. I moved the tests from a directory named 'jdk.unsupported' to unsupported', as other tests, in test/tools/jdeps/module, use test/tools/jdeps as a test library, and the directory/test lib name is conflicting with the module name. jtreg fails immediately. The updates I made check that jdeps identifies both jdk.internal.misc and sun.misc Unsafe as internal APIs. > Other than that, looks good. Thanks for the Review. > There are so many tests that have @modules java.base sun/misc but unused. It?s good that you clean that up. I agree with Alan that JDK modules depending on jdk.unsupported should get the priority to get eliminated by FC. I bumped the priority, and target the issues to 9. -Chris. From mandy.chung at oracle.com Fri Apr 8 15:48:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Apr 2016 08:48:30 -0700 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707CFBB.8020809@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> Message-ID: > On Apr 8, 2016, at 8:35 AM, Chris Hegarty wrote: > > > I moved the tests from a directory named 'jdk.unsupported' to > unsupported', as other tests, in test/tools/jdeps/module, use > test/tools/jdeps as a test library, and the directory/test lib > name is conflicting with the module name. jtreg fails immediately. > The updates I made check that jdeps identifies both jdk.internal.misc > and sun.misc Unsafe as internal APIs. Thanks for explaining why you did the rename. Your change now makes sense to me. I may reorganize the jdeps tests to avoid the module name you ran into in the future. All looks good. Mandy From serguei.spitsyn at oracle.com Fri Apr 8 23:04:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Apr 2016 16:04:17 -0700 Subject: RFR (XS): 8153902 remove com/sun/jdi/InterfaceMethodsTest.java, com/sun/jdi/InvokeTest.java from ProblemList In-Reply-To: <56F3D98E.4050805@oracle.com> References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default> <56F3D98E.4050805@oracle.com> Message-ID: <570838F1.9000204@oracle.com> Please, review this trivial, test-only change (enabling previously excluded tests). Bug: https://bugs.openjdk.java.net/browse/JDK-8153902 Summary: The tests need to be enabled again after the fix of: JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Below is the patch: diff -r 8f6aab6360a3 test/ProblemList.txt --- a/test/ProblemList.txt Fri Apr 08 12:26:47 2016 -0700 +++ b/test/ProblemList.txt Fri Apr 08 15:57:28 2016 -0700 @@ -333,10 +333,6 @@ com/sun/jdi/GetLocalVariables4Test.sh 8067354 windows-all -com/sun/jdi/InterfaceMethodsTest.java 8152586 generic-all - -com/sun/jdi/InvokeTest.java 8152586 generic-all - ############################################################################ # jdk_util Thanks, Serguei On 3/24/16 05:11, serguei.spitsyn at oracle.com wrote: > Hi Alexander, > > Looks good. > > Thanks, > Serguei > > > On 3/24/16 04:46, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review this trivial, test-only change (enabling a >> previously excluded test) >> >> Webrev: >> http://cr.openjdk.java.net/~akulyakh/8147987/test/ProblemList.txt.udiff.html >> CR: https://bugs.openjdk.java.net/browse/JDK-8147987 "Remove >> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from >> problemList" >> >> Best regards, >> Alexander >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 8 23:07:11 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Apr 2016 16:07:11 -0700 Subject: RFR (XS): 8153902 remove com/sun/jdi/InterfaceMethodsTest.java, com/sun/jdi/InvokeTest.java from ProblemList In-Reply-To: <570838F1.9000204@oracle.com> References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default> <56F3D98E.4050805@oracle.com> <570838F1.9000204@oracle.com> Message-ID: <5708399F.4000103@oracle.com> Removed unneeded attachment below. Sorry for the confusion. Thanks, Serguei On 4/8/16 16:04, serguei.spitsyn at oracle.com wrote: > Please, review this trivial, test-only change (enabling previously > excluded tests). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153902 > > Summary: > The tests need to be enabled again after the fix of: > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted > when processing invokeMethod command > > > Below is the patch: > > diff -r 8f6aab6360a3 test/ProblemList.txt > --- a/test/ProblemList.txt Fri Apr 08 12:26:47 2016 -0700 > +++ b/test/ProblemList.txt Fri Apr 08 15:57:28 2016 -0700 > @@ -333,10 +333,6 @@ > > com/sun/jdi/GetLocalVariables4Test.sh 8067354 windows-all > > -com/sun/jdi/InterfaceMethodsTest.java 8152586 generic-all > - > -com/sun/jdi/InvokeTest.java 8152586 generic-all > - > ############################################################################ > > # jdk_util > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Sat Apr 9 22:19:37 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 9 Apr 2016 23:19:37 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: This change has been pushed to jdk9/dev. The hotspot gatekeeper will bring it down into the hotspot forests. -Chris. > On 7 Apr 2016, at 18:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 > > Summary of the changes: > > - Restructure, what remains of, the sources in sun/misc to reflect the > new modular layout. There are still a few non-Critical APIs in sun.misc > that will be addressed later. > > - Add dependencies from several JDK modules to jdk.unsupported. All > dependencies have issues tracking them, and should be removed in 9. > > - The test library in the top-level repo provides a convenience to > tests to retrieve Unsafe. This has been updated to the "real" internal > Unsafe, so there are many many tests that require to be updated, mostly > the @modules tags. ( The Unsafe dependency in the library should > probably be revisited at some point, as it requires many tests, not > wishing to use Unsafe, to require an explicit dependency on it ) > > Note: with recent work from Mikael [2], sun.misc.Unsafe is now just a > delegate for the "real" internal Unsafe, so it is time to move the > tests to use it directly. > > - Cleanup any tests unnecessarily/incorrectly declaring a dependency > on sun.misc ( this could have been unnecessarily added, been refactored > out at one point, or the library upon which the tests depends refactored, > that the dependency is no longer required ). I'm sure further cleanup > could be done, but this is sufficient for now. > > - A small number of test in hotspot/test/compiler/unsafe, which are > generated, have been updated, along with the generation script, to > depend on jdk.unsupported/sun.misc ( they explicitly test the sun.misc > version ) > > All 'core', 'pit', and 'hotspot' testsets have been successfully run on > Mac, Linux, Windows, and Solaris. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > [2] https://bugs.openjdk.java.net/browse/JDK-8149159 From yasuenag at gmail.com Mon Apr 11 09:28:55 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Apr 2016 18:28:55 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <56FD2738.8050500@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> Message-ID: <570B6E57.2060707@gmail.com> PING: Could you review it? We need more reviewer. >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ Thanks, Yasumasa On 2016/03/31 22:33, Yasumasa Suenaga wrote: > CC'ed to serviceability-dev. > > Could you review it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/03/31 18:24, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>> You're missing an include of arguments.hpp in logFileOutput.cpp. >> >> arguments.hpp is included in precompiled.hpp . So build was succeeded. >> However, it should be included in logFileOutput.cpp . >> >> I uploaded a new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/31 16:48, Marcus Larsson wrote: >>> Hi, >>> >>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This request review is related to [1]. >>>> >>>> I want to set filesize option with k/m/g as below: >>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>> >>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>> I think we can use option parser in arguments.cpp . >>>> >>>> I uploaded webrev. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>> >>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>> >>> Apart from that, this looks good to me. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>> >>> From yasuenag at gmail.com Mon Apr 11 09:29:42 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Apr 2016 18:29:42 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <56FD2786.9020102@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> Message-ID: <570B6E86.6020507@gmail.com> PING: Could you review and sponsor it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ Thanks, Yasumasa On 2016/03/31 22:35, Yasumasa Suenaga wrote: > CC'ed to serviceability-dev. > > Could you review it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2016/03/30 23:09, Yasumasa Suenaga wrote: >> Hi all, >> >> This request review is related to [1]. >> >> I want to see output option (filecount, filesize) in VM.log jcmd. >> >> Output sample: >> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >> >> I uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >> >> From poonam.bajaj at oracle.com Mon Apr 11 19:15:19 2016 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 11 Apr 2016 12:15:19 -0700 Subject: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist Message-ID: <570BF7C7.6080204@oracle.com> Hello, Please review this simple fix. Bug JDK-8153252 : SA: Hotspot build on Windows fails if make/closed folder does not exist Problem: The problem is that the SA build on windows fails while building non-openjdk commercial sources that don't contain the make/closed folder. nmake -nologo -f D:\ws\8u-dev\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated cd generated && "d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f D:\ws\8u-dev\hotspot\make\windows\makefiles\ generated.make DIR=.\generated BUILD_FLAVOR=product D:\ws\8u-dev\hotspot/make/windows/makefiles/sa.make(54) : fatal error U1052: file 'D:\ws\8u-dev\hotspot/make/closed/windows/makefiles/sa.make' not found Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Fix: Add a check to ensure that the make/closed folder exists. Webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.00/ Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Mon Apr 11 20:06:03 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Apr 2016 16:06:03 -0400 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly Message-ID: <570C03AB.4020906@oracle.com> Summary: Constant pool merging is not thread safe for source_file_name. This change includes the change for the following bug because they are tested together. 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe for MethodHandleInError and MethodTypeInError. The parallel constant pool merges are mostly harmless because the old methods constant pool pointers aren't updated. The only case I found where it isn't harmless is that we rely on finding the source_file_name_index from the final merged constant pool, which could be any of the parallel merged constant pools. The code to attempt to dig out the name from redefined classes is removed. open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8151546 Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I tried to write a test with all the conditions of the failure but couldn't make it fail (so noreg-hard). Thanks, Coleen From serguei.spitsyn at oracle.com Tue Apr 12 01:17:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Apr 2016 18:17:00 -0700 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570C03AB.4020906@oracle.com> References: <570C03AB.4020906@oracle.com> Message-ID: <570C4C8C.5060300@oracle.com> Coleen, src/share/vm/prims/jvmtiRedefineClasses.cpp - // Update the version number of the constant pool + // Update the version number of the constant pools (may keep scratch_cp) merge_cp->increment_and_save_version(old_cp->version()); + scratch_cp->increment_and_save_version(old_cp->version()); Not sure, I understand the change above. Could you, please, explain why this change is needed? I suspect, the scratch_cp->version() is never used. + // NOTE: this doesn't work because you can redefine the same class in two + // threads, each getting their own constant pool data appended to the + // original constant pool. In order for the new methods to work when they + // become old methods, they need to keep their updated copy of the constant pool. + It feels like the statement in this note is too strong, and as such, confusing. Would it be better to tell something like "not always work"? Otherwise, the question is: why do we need this block of code if it doesn't work? Thanks, Serguei On 4/11/16 13:06, Coleen Phillimore wrote: > Summary: Constant pool merging is not thread safe for source_file_name. > > This change includes the change for the following bug because they are > tested together. > > 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert > failed: Corrupted constant pool > Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe > for MethodHandleInError and MethodTypeInError. > > The parallel constant pool merges are mostly harmless because the old > methods constant pool pointers aren't updated. The only case I found > where it isn't harmless is that we rely on finding the > source_file_name_index from the final merged constant pool, which > could be any of the parallel merged constant pools. The code to > attempt to dig out the name from redefined classes is removed. > > open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8151546 > > Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I > tried to write a test with all the conditions of the failure but > couldn't make it fail (so noreg-hard). > > Thanks, > Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Tue Apr 12 01:44:48 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 11 Apr 2016 18:44:48 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <56FE0A77.6010604@oracle.com> References: <56FE0A77.6010604@oracle.com> Message-ID: Hi Ioi, I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { 172 address base_address = address(MetaspaceShared::shared_rs()->base()); 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); - Why is the default RO space size increased? - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java Copyright year. Thanks, Jiangli > On Mar 31, 2016, at 10:43 PM, Ioi Lam wrote: > > Please review > > http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ > > Bug: Clean up CompactHashtable > > https://bugs.openjdk.java.net/browse/JDK-8150607 > > Summary of fix: > > [1] Instead of reading/writing the table bit-by-bit, which is tedious and > error prone, use SimpleCompactHashtable::serialize(), which is more > structural. > > [2] Split up the _buckets and _entries into two separate arrays, so the > dumping and walking code is easier to understand > > (see comments above SimpleCompactHashtable declaration) > These 2 arrays are now allocated from the RO region (used to be in RW) > > [3] Renamed a few things > > COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE > (having something called "compact" in CompactHashtable is confusing) > > The old names "dump_table" (actually dumping the buckets) and > "dump_buckets" (actually dumping the entries) were conflicting with > terminology used elsewhere. Now the terminology is unified: > "buckets" = the main index, "entries" = the second level. > > lookup_entry -> decode_entry (it wasn't doing any lookup) > > [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be > checked with assert. > > [5] Replaced all juint to u4 (suggested by Coleen) > > [6] templatize the iterator (see CompactHashtable::symbols_do -> > SimpleCompactHashtable::iterate) > > [7] I also added a test case using Serviceability Agent -- due to the lack of > a regression test, the walking of the compact hashtable in SA had been > broken for a while before it was fixed in JDK-8151368, so having a test > case would make the code more maintainable. > > Tests: > > Hotspot JTREG tests > > Thanks > - Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Tue Apr 12 02:11:52 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 Apr 2016 19:11:52 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: References: <56FE0A77.6010604@oracle.com> Message-ID: <570C5968.3000401@oracle.com> Hi Jiangli, Thanks for the review: On 4/11/16 6:44 PM, Jiangli Zhou wrote: > Hi Ioi, > > I like the more structural way of reading/writing the compact table > with SimpleCompactHashtable. It looks quite clean overall. > > - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive > than TINY_BUCKET_TYPE? > OK, I will make the change. > - The following assert in CompactSymbolTableWriter::add() limits the > total shared space size to be less than MAX_SHARED_DELTA > unnecessarily. Symbols are allocated from the RO space at dump time. > We only need to make sure the max delta between the ?base_address? and > the end of RO space is less than MAX_SHARED_DELTA. This is not a new > issue introduced by your change, you don?t have to address that as > part of this change if you prefer. I?ll file a separate RFE. > I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. > 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { > 172 address base_address = address(MetaspaceShared::shared_rs()->base()); > 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); > 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); > > - Why is the default RO space size increased? > That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. > - > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java > - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > Copyright year. Will fix. Thanks - Ioi > > Thanks, > Jiangli > >> On Mar 31, 2016, at 10:43 PM, Ioi Lam > > wrote: >> >> Please review >> >> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >> >> >> Bug: Clean up CompactHashtable >> >> https://bugs.openjdk.java.net/browse/JDK-8150607 >> >> Summary of fix: >> >> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >> error prone, use SimpleCompactHashtable::serialize(), which is more >> structural. >> >> [2] Split up the _buckets and _entries into two separate arrays, so the >> dumping and walking code is easier to understand >> >> (see comments above SimpleCompactHashtable declaration) >> These 2 arrays are now allocated from the RO region (used to be in RW) >> >> [3] Renamed a few things >> >> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >> (having something called "compact" in CompactHashtable is >> confusing) >> >> The old names "dump_table" (actually dumping the buckets) and >> "dump_buckets" (actually dumping the entries) were conflicting with >> terminology used elsewhere. Now the terminology is unified: >> "buckets" = the main index, "entries" = the second level. >> >> lookup_entry -> decode_entry (it wasn't doing any lookup) >> >> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >> checked with assert. >> >> [5] Replaced all juint to u4 (suggested by Coleen) >> >> [6] templatize the iterator (see CompactHashtable::symbols_do -> >> SimpleCompactHashtable::iterate) >> >> [7] I also added a test case using Serviceability Agent -- due to the >> lack of >> a regression test, the walking of the compact hashtable in SA had been >> broken for a while before it was fixed in JDK-8151368, so having a >> test >> case would make the code more maintainable. >> >> Tests: >> >> Hotspot JTREG tests >> >> Thanks >> - Ioi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 12 06:12:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Apr 2016 23:12:20 -0700 Subject: RFR (XS): 8153902 remove com/sun/jdi/InterfaceMethodsTest.java, com/sun/jdi/InvokeTest.java from ProblemList In-Reply-To: <570838F1.9000204@oracle.com> References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default> <56F3D98E.4050805@oracle.com> <570838F1.9000204@oracle.com> Message-ID: <570C91C4.1050809@oracle.com> Ping... Thanks, Serguei On 4/8/16 16:04, serguei.spitsyn at oracle.com wrote: > Please, review this trivial, test-only change (enabling previously > excluded tests). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8153902 > > Summary: > The tests need to be enabled again after the fix of: > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted > when processing invokeMethod command > > > Below is the patch: > > diff -r 8f6aab6360a3 test/ProblemList.txt > --- a/test/ProblemList.txt Fri Apr 08 12:26:47 2016 -0700 > +++ b/test/ProblemList.txt Fri Apr 08 15:57:28 2016 -0700 > @@ -333,10 +333,6 @@ > > com/sun/jdi/GetLocalVariables4Test.sh 8067354 windows-all > > -com/sun/jdi/InterfaceMethodsTest.java 8152586 generic-all > - > -com/sun/jdi/InvokeTest.java 8152586 generic-all > - > ############################################################################ > > # jdk_util > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Tue Apr 12 06:18:34 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 12 Apr 2016 11:48:34 +0530 Subject: RFR (XS): 8153902 remove com/sun/jdi/InterfaceMethodsTest.java, com/sun/jdi/InvokeTest.java from ProblemList In-Reply-To: <570C91C4.1050809@oracle.com> References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default> <56F3D98E.4050805@oracle.com> <570838F1.9000204@oracle.com> <570C91C4.1050809@oracle.com> Message-ID: <570C933A.6090006@oracle.com> +1 -Sundar On 4/12/2016 11:42 AM, serguei.spitsyn at oracle.com wrote: > Ping... > > Thanks, > Serguei > > > On 4/8/16 16:04, serguei.spitsyn at oracle.com wrote: >> Please, review this trivial, test-only change (enabling previously >> excluded tests). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8153902 >> >> Summary: >> The tests need to be enabled again after the fix of: >> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted >> when processing invokeMethod command >> >> >> Below is the patch: >> >> diff -r 8f6aab6360a3 test/ProblemList.txt >> --- a/test/ProblemList.txt Fri Apr 08 12:26:47 2016 -0700 >> +++ b/test/ProblemList.txt Fri Apr 08 15:57:28 2016 -0700 >> @@ -333,10 +333,6 @@ >> >> com/sun/jdi/GetLocalVariables4Test.sh >> 8067354 windows-all >> >> -com/sun/jdi/InterfaceMethodsTest.java 8152586 generic-all >> - >> -com/sun/jdi/InvokeTest.java 8152586 generic-all >> - >> ############################################################################ >> >> # jdk_util >> >> >> Thanks, >> Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 12 06:19:55 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Apr 2016 23:19:55 -0700 Subject: RFR (XS): 8153902 remove com/sun/jdi/InterfaceMethodsTest.java, com/sun/jdi/InvokeTest.java from ProblemList In-Reply-To: <570C933A.6090006@oracle.com> References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default> <56F3D98E.4050805@oracle.com> <570838F1.9000204@oracle.com> <570C91C4.1050809@oracle.com> <570C933A.6090006@oracle.com> Message-ID: <570C938B.2000003@oracle.com> Thanks, Sundar! Serguei On 4/11/16 23:18, Sundararajan Athijegannathan wrote: > +1 > > -Sundar > > On 4/12/2016 11:42 AM, serguei.spitsyn at oracle.com wrote: >> Ping... >> >> Thanks, >> Serguei >> >> >> On 4/8/16 16:04, serguei.spitsyn at oracle.com wrote: >>> Please, review this trivial, test-only change (enabling previously >>> excluded tests). >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8153902 >>> >>> Summary: >>> The tests need to be enabled again after the fix of: >>> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never >>> deleted when processing invokeMethod command >>> >>> >>> Below is the patch: >>> >>> diff -r 8f6aab6360a3 test/ProblemList.txt >>> --- a/test/ProblemList.txt Fri Apr 08 12:26:47 2016 -0700 >>> +++ b/test/ProblemList.txt Fri Apr 08 15:57:28 2016 -0700 >>> @@ -333,10 +333,6 @@ >>> >>> com/sun/jdi/GetLocalVariables4Test.sh 8067354 windows-all >>> >>> -com/sun/jdi/InterfaceMethodsTest.java 8152586 generic-all >>> - >>> -com/sun/jdi/InvokeTest.java 8152586 generic-all >>> - >>> ############################################################################ >>> >>> # jdk_util >>> >>> >>> Thanks, >>> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Apr 12 12:28:23 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Apr 2016 15:28:23 +0300 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 Message-ID: <570CE9E7.8010407@oracle.com> Everybody, Please review a small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ This fix doesn't fix root cause of the test fail but fix small test bug to get better diagnostic. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Apr 12 12:36:50 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Apr 2016 15:36:50 +0300 Subject: RFR(S): JDK-8152847 JDI use of sun.boot.class.path needs to be updated for Jigsaw Message-ID: <570CEBE1.1010201@oracle.com> Everybody, Please, review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8152847/webrev.01/ Public interface PathSearchingVirtualMachine.bootClassPath() left untouched, but VirtualMachineImpl.bootClassPath() returns an empty list. Tested with RBT -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Tue Apr 12 12:39:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Apr 2016 13:39:26 +0100 Subject: RFR(S): JDK-8152847 JDI use of sun.boot.class.path needs to be updated for Jigsaw In-Reply-To: <570CEBE1.1010201@oracle.com> References: <570CEBE1.1010201@oracle.com> Message-ID: <570CEC7E.2000407@oracle.com> On 12/04/2016 13:36, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8152847/webrev.01/ > > Public interface PathSearchingVirtualMachine.bootClassPath() left > untouched, but VirtualMachineImpl.bootClassPath() returns an empty list. > > This looks okay to me. -Alan From staffan.larsen at oracle.com Tue Apr 12 13:32:40 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Apr 2016 15:32:40 +0200 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 In-Reply-To: <570CE9E7.8010407@oracle.com> References: <570CE9E7.8010407@oracle.com> Message-ID: Can you explain what is going on here? It looks like the old code looked for the TTY process, whereas the new code accepts any process. What am I missing? > On 12 apr. 2016, at 14:28, Dmitry Samersoff wrote: > > Everybody, > > Please review a small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ > > This fix doesn't fix root cause of the test fail but fix small test bug > to get better diagnostic. > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Tue Apr 12 14:14:39 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Apr 2016 16:14:39 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5704B0B0.4010404@oracle.com> References: <5704B0B0.4010404@oracle.com> Message-ID: <570D02CF.7070708@oracle.com> Ping! On 04/06/2016 08:46 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add a warning for when tag > selections in -Xlog or VM.log don't match any tag sets used in the VM. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8150894 > > Testing: > Internal VM tests with RBT > > Thanks, > Marcus From dmitry.samersoff at oracle.com Tue Apr 12 14:32:56 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Apr 2016 17:32:56 +0300 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 In-Reply-To: References: <570CE9E7.8010407@oracle.com> Message-ID: <570D0718.4060104@oracle.com> Staffan, On 2016-04-12 16:32, Staffan Larsen wrote: > Can you explain what is going on here? It looks like the old code > looked for the TTY process, whereas the new code accepts any process. > What am I missing? Both code select jdbCmd first: ll. 926 jdbCmd=`$jdk/bin/jps -v | $grep $jdbKeyword` then old code expect: 12199 TTY -Dapplication.home=/opt/jdk1.8.0_77 -Xms8m but for latest JDK9 jps -v return full class name: 12281 com.sun.tools.example.debug.tty.TTY -Dapplication.home=/opt/jdk9 -Xms8m -Djdk.module.main=jdk.jdi i.e. we get com.sun.tools.example.debug.tty.TTY instead of just TTY new code accept both variants. -Dmitry > >> On 12 apr. 2016, at 14:28, Dmitry Samersoff >> wrote: >> >> Everybody, >> >> Please review a small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ >> >> This fix doesn't fix root cause of the test fail but fix small test >> bug to get better diagnostic. >> >> -Dmitry >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From andreas.eriksson at oracle.com Tue Apr 12 16:05:52 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 12 Apr 2016 18:05:52 +0200 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump Message-ID: <570D1CE0.1000108@oracle.com> Hi, Please review this fix for 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ The crash is because changes I did in JDK-8129419 do not work with solaris logic used for UseVMInterruptibleIO in some cases. This change reverts the changes I did to the solaris version of os::write, and changes heapDumper.cpp to use ::write and ::close directly, as it did before. Thanks, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Apr 12 16:07:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Apr 2016 19:07:43 +0300 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <570D1CE0.1000108@oracle.com> References: <570D1CE0.1000108@oracle.com> Message-ID: <570D1D4F.5000608@oracle.com> Andreas, Looks good for me! -Dmitry On 2016-04-12 19:05, Andreas Eriksson wrote: > Hi, > > Please review this fix for 8153641: assert(thread_state == > _thread_in_native) failed: Assumed thread_in_native while heap dump > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 > Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ > > The crash is because changes I did in JDK-8129419 > do not work with > solaris logic used for UseVMInterruptibleIO in some cases. > This change reverts the changes I did to the solaris version of > os::write, and changes heapDumper.cpp to use ::write and ::close > directly, as it did before. > > Thanks, > Andreas -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From andreas.eriksson at oracle.com Tue Apr 12 16:38:29 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 12 Apr 2016 18:38:29 +0200 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <570D1D4F.5000608@oracle.com> References: <570D1CE0.1000108@oracle.com> <570D1D4F.5000608@oracle.com> Message-ID: <570D2485.6020802@oracle.com> Thanks Dmitry! - Andreas On 2016-04-12 18:07, Dmitry Samersoff wrote: > Andreas, > > Looks good for me! > > -Dmitry > > On 2016-04-12 19:05, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for 8153641: assert(thread_state == >> _thread_in_native) failed: Assumed thread_in_native while heap dump >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ >> >> The crash is because changes I did in JDK-8129419 >> do not work with >> solaris logic used for UseVMInterruptibleIO in some cases. >> This change reverts the changes I did to the solaris version of >> os::write, and changes heapDumper.cpp to use ::write and ::close >> directly, as it did before. >> >> Thanks, >> Andreas > From serguei.spitsyn at oracle.com Tue Apr 12 18:46:23 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 11:46:23 -0700 Subject: RFR(S): JDK-8152847 JDI use of sun.boot.class.path needs to be updated for Jigsaw In-Reply-To: <570CEBE1.1010201@oracle.com> References: <570CEBE1.1010201@oracle.com> Message-ID: <570D427F.3060904@oracle.com> Dmitry, It looks good. Thanks, Serguei On 4/12/16 05:36, Dmitry Samersoff wrote: > Everybody, > > Please, review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8152847/webrev.01/ > > Public interface PathSearchingVirtualMachine.bootClassPath() left > untouched, but VirtualMachineImpl.bootClassPath() returns an empty list. > > Tested with RBT > > -Dmitry > From serguei.spitsyn at oracle.com Tue Apr 12 18:57:48 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 11:57:48 -0700 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <570D1CE0.1000108@oracle.com> References: <570D1CE0.1000108@oracle.com> Message-ID: <570D452C.6060806@oracle.com> Hi Andreas, The fix looks good. Thanks, Serguei On 4/12/16 09:05, Andreas Eriksson wrote: > Hi, > > Please review this fix for 8153641: assert(thread_state == > _thread_in_native) failed: Assumed thread_in_native while heap dump > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 > Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ > > The crash is because changes I did in JDK-8129419 > do not work with > solaris logic used for UseVMInterruptibleIO in some cases. > This change reverts the changes I did to the solaris version of > os::write, and changes heapDumper.cpp to use ::write and ::close > directly, as it did before. > > Thanks, > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Apr 12 19:06:05 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Apr 2016 21:06:05 +0200 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 In-Reply-To: <570D0718.4060104@oracle.com> References: <570CE9E7.8010407@oracle.com> <570D0718.4060104@oracle.com> Message-ID: <3F369530-693E-4842-9A03-1FD9D58A0BDC@oracle.com> Thanks for the explanation. The change looks good. Do you know if the change in jps output was intentional or caused by something else? > On 12 apr. 2016, at 16:32, Dmitry Samersoff wrote: > > Staffan, > > On 2016-04-12 16:32, Staffan Larsen wrote: >> Can you explain what is going on here? It looks like the old code >> looked for the TTY process, whereas the new code accepts any process. >> What am I missing? > > Both code select jdbCmd first: > > ll. 926 > jdbCmd=`$jdk/bin/jps -v | $grep $jdbKeyword` > > then old code expect: > > 12199 TTY -Dapplication.home=/opt/jdk1.8.0_77 -Xms8m > > but for latest JDK9 jps -v return full class name: > > 12281 com.sun.tools.example.debug.tty.TTY -Dapplication.home=/opt/jdk9 > -Xms8m -Djdk.module.main=jdk.jdi > > i.e. we get com.sun.tools.example.debug.tty.TTY instead of just TTY > > new code accept both variants. > > -Dmitry > > >> >>> On 12 apr. 2016, at 14:28, Dmitry Samersoff >>> wrote: >>> >>> Everybody, >>> >>> Please review a small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ >>> >>> This fix doesn't fix root cause of the test fail but fix small test >>> bug to get better diagnostic. >>> >>> -Dmitry >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * I would love to change the world, but they won't give me >>> the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexhenrie24 at gmail.com Tue Apr 12 19:28:41 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 12 Apr 2016 13:28:41 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList Message-ID: <66c6fa3b2280afa12a2d.1460489321@wolverine> # HG changeset patch # User Alex Henrie # Date 1447827030 25200 # Tue Nov 17 23:10:30 2015 -0700 # Node ID 66c6fa3b2280afa12a2d51ea668b6a781b5744b5 # Parent 1f8c4b1a301c989dc299cad63dbc530b1de3ed70 8145278: Fix memory leak in splitPathList diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c @@ -513,28 +513,32 @@ eventHandlerClassFileLoadHook( jvmtiEnv * The attribute value is in UTF8 but cannot contain NUL. Also non US-ASCII * characters must be escaped (URI syntax) so safe to iterate through the * value as a C string. */ static void splitPathList(const char* str, int* pathCount, char*** paths) { int count = 0; char** segments = NULL; + char** new_segments; char* c = (char*) str; while (*c != '\0') { while (*c == ' ') c++; /* skip leading spaces */ if (*c == '\0') { break; } - if (segments == NULL) { - segments = (char**)malloc( sizeof(char**) ); - } else { - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); + new_segments = (char**)realloc(segments, (count+1)*sizeof(char*)); + if (new_segments == NULL) { + jplis_assert(0); + free(segments); + count = 0; + segments = NULL; + break; } - jplis_assert(segments != (char**)NULL); + segments = new_segments; segments[count++] = c; c = strchr(c, ' '); if (c == NULL) { break; } *c = '\0'; c++; } From coleen.phillimore at oracle.com Tue Apr 12 19:29:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Apr 2016 15:29:41 -0400 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570C4C8C.5060300@oracle.com> References: <570C03AB.4020906@oracle.com> <570C4C8C.5060300@oracle.com> Message-ID: <570D4CA5.2070505@oracle.com> Hi Serguei, Thank you for looking at this change. On 4/11/16 9:17 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > src/share/vm/prims/jvmtiRedefineClasses.cpp > - // Update the version number of the constant pool > + // Update the version number of the constant pools (may keep scratch_cp) > merge_cp->increment_and_save_version(old_cp->version()); > + scratch_cp->increment_and_save_version(old_cp->version()); > > Not sure, I understand the change above. > Could you, please, explain why this change is needed? > I suspect, the scratch_cp->version() is never used. scratch_cp is used if it's equivalent to the old constant pool (see the code below this with the comments). But it could add entries. In this case, we want scratch_cp to have a new version number because scratch_class->_source_file_name_index may be an appended entry (old_cp->length() + n) which a parallel constant pool merge might append a different entry and be set to the constant pool after the safepoint. So source_file_name_index won't point to the first appended entry. So I need to update the version also in scratch_cp to detect this. Actually, I made this change because I was going to make a bigger change that compared constant pool entries if they were the same version (ie both old_cp->version + 1), indicating parallel constant pool merging. I decided this change was too much. > > > + // NOTE: this doesn't work because you can redefine the same class > in two > + // threads, each getting their own constant pool data appended to the > + // original constant pool. In order for the new methods to work when > they > + // become old methods, they need to keep their updated copy of the > constant pool. > + > It feels like the statement in this note is too strong, and as such, > confusing. > Would it be better to tell something like "not always work"? > Otherwise, the question is: why do we need this block of code if it > doesn't work? > The block of code is #if 0'ed out. In my debugging I figured out why it wouldn't work, so I thought I'd comment it. Thanks, Coleen > > Thanks, > Serguei > > > On 4/11/16 13:06, Coleen Phillimore wrote: >> Summary: Constant pool merging is not thread safe for source_file_name. >> >> This change includes the change for the following bug because they >> are tested together. >> >> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert >> failed: Corrupted constant pool >> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe >> for MethodHandleInError and MethodTypeInError. >> >> The parallel constant pool merges are mostly harmless because the old >> methods constant pool pointers aren't updated. The only case I found >> where it isn't harmless is that we rely on finding the >> source_file_name_index from the final merged constant pool, which >> could be any of the parallel merged constant pools. The code to >> attempt to dig out the name from redefined classes is removed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >> >> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >> tried to write a test with all the conditions of the failure but >> couldn't make it fail (so noreg-hard). >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Tue Apr 12 19:40:15 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 12 Apr 2016 12:40:15 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <570C5968.3000401@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> Message-ID: <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> Ioi, > On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: > > Hi Jiangli, > > > Thanks for the review: > > On 4/11/16 6:44 PM, Jiangli Zhou wrote: >> Hi Ioi, >> >> I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. >> >> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? >> > OK, I will make the change. > >> - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. >> > I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. I filed JDK-8154108 . > >> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { >> 172 address base_address = address(MetaspaceShared::shared_rs()->base()); >> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >> 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); >> >> - Why is the default RO space size increased? >> > That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. Ok. Thanks, Jiangli >> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >> Copyright year. > > Will fix. > > Thanks > - Ioi >> >> Thanks, >> Jiangli >> >>> On Mar 31, 2016, at 10:43 PM, Ioi Lam > wrote: >>> >>> Please review >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>> >>> Bug: Clean up CompactHashtable >>> >>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>> >>> Summary of fix: >>> >>> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >>> error prone, use SimpleCompactHashtable::serialize(), which is more >>> structural. >>> >>> [2] Split up the _buckets and _entries into two separate arrays, so the >>> dumping and walking code is easier to understand >>> >>> (see comments above SimpleCompactHashtable declaration) >>> These 2 arrays are now allocated from the RO region (used to be in RW) >>> >>> [3] Renamed a few things >>> >>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>> (having something called "compact" in CompactHashtable is confusing) >>> >>> The old names "dump_table" (actually dumping the buckets) and >>> "dump_buckets" (actually dumping the entries) were conflicting with >>> terminology used elsewhere. Now the terminology is unified: >>> "buckets" = the main index, "entries" = the second level. >>> >>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>> >>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>> checked with assert. >>> >>> [5] Replaced all juint to u4 (suggested by Coleen) >>> >>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>> SimpleCompactHashtable::iterate) >>> >>> [7] I also added a test case using Serviceability Agent -- due to the lack of >>> a regression test, the walking of the compact hashtable in SA had been >>> broken for a while before it was fixed in JDK-8151368, so having a test >>> case would make the code more maintainable. >>> >>> Tests: >>> >>> Hotspot JTREG tests >>> >>> Thanks >>> - Ioi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 12 20:07:42 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 13:07:42 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <66c6fa3b2280afa12a2d.1460489321@wolverine> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> Message-ID: <570D558E.9050407@oracle.com> Hi Alex, The fix looks good. Could you tell why this is important to you, what is the motivation? Do you really observe this problem, or it is based on a static analysis? Thanks, Serguei On 4/12/16 12:28, Alex Henrie wrote: > # HG changeset patch > # User Alex Henrie > # Date 1447827030 25200 > # Tue Nov 17 23:10:30 2015 -0700 > # Node ID 66c6fa3b2280afa12a2d51ea668b6a781b5744b5 > # Parent 1f8c4b1a301c989dc299cad63dbc530b1de3ed70 > 8145278: Fix memory leak in splitPathList > > diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > @@ -513,28 +513,32 @@ eventHandlerClassFileLoadHook( jvmtiEnv > * The attribute value is in UTF8 but cannot contain NUL. Also non US-ASCII > * characters must be escaped (URI syntax) so safe to iterate through the > * value as a C string. > */ > static void > splitPathList(const char* str, int* pathCount, char*** paths) { > int count = 0; > char** segments = NULL; > + char** new_segments; > char* c = (char*) str; > while (*c != '\0') { > while (*c == ' ') c++; /* skip leading spaces */ > if (*c == '\0') { > break; > } > - if (segments == NULL) { > - segments = (char**)malloc( sizeof(char**) ); > - } else { > - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); > + new_segments = (char**)realloc(segments, (count+1)*sizeof(char*)); > + if (new_segments == NULL) { > + jplis_assert(0); > + free(segments); > + count = 0; > + segments = NULL; > + break; > } > - jplis_assert(segments != (char**)NULL); > + segments = new_segments; > segments[count++] = c; > c = strchr(c, ' '); > if (c == NULL) { > break; > } > *c = '\0'; > c++; > } From alexhenrie24 at gmail.com Tue Apr 12 20:11:54 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 12 Apr 2016 14:11:54 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <570D558E.9050407@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D558E.9050407@oracle.com> Message-ID: 2016-04-12 14:07 GMT-06:00 serguei.spitsyn at oracle.com : > Hi Alex, > > The fix looks good. > Could you tell why this is important to you, what is the motivation? > Do you really observe this problem, or it is based on a static analysis? I was playing around with the codebase trying to find ways to improve performance. I found this memory leak with static analysis (scan-build), and figured that it would be a good place to start. -Alex From serguei.spitsyn at oracle.com Tue Apr 12 20:20:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 13:20:49 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D558E.9050407@oracle.com> Message-ID: <570D58A1.4090509@oracle.com> On 4/12/16 13:11, Alex Henrie wrote: > 2016-04-12 14:07 GMT-06:00 serguei.spitsyn at oracle.com > : >> Hi Alex, >> >> The fix looks good. >> Could you tell why this is important to you, what is the motivation? >> Do you really observe this problem, or it is based on a static analysis? > I was playing around with the codebase trying to find ways to improve > performance. I found this memory leak with static analysis > (scan-build), and figured that it would be a good place to start. Ok. I can sponsor your fix. Thank you for the explanation! Serguei > > -Alex From dmitry.samersoff at oracle.com Tue Apr 12 21:12:51 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Apr 2016 00:12:51 +0300 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <66c6fa3b2280afa12a2d.1460489321@wolverine> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> Message-ID: <570D64D3.8000005@oracle.com> Alex, The fix looks good for me. -Dmitry On 2016-04-12 22:28, Alex Henrie wrote: > # HG changeset patch > # User Alex Henrie > # Date 1447827030 25200 > # Tue Nov 17 23:10:30 2015 -0700 > # Node ID 66c6fa3b2280afa12a2d51ea668b6a781b5744b5 > # Parent 1f8c4b1a301c989dc299cad63dbc530b1de3ed70 > 8145278: Fix memory leak in splitPathList > > diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > @@ -513,28 +513,32 @@ eventHandlerClassFileLoadHook( jvmtiEnv > * The attribute value is in UTF8 but cannot contain NUL. Also non US-ASCII > * characters must be escaped (URI syntax) so safe to iterate through the > * value as a C string. > */ > static void > splitPathList(const char* str, int* pathCount, char*** paths) { > int count = 0; > char** segments = NULL; > + char** new_segments; > char* c = (char*) str; > while (*c != '\0') { > while (*c == ' ') c++; /* skip leading spaces */ > if (*c == '\0') { > break; > } > - if (segments == NULL) { > - segments = (char**)malloc( sizeof(char**) ); > - } else { > - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); > + new_segments = (char**)realloc(segments, (count+1)*sizeof(char*)); > + if (new_segments == NULL) { > + jplis_assert(0); > + free(segments); > + count = 0; > + segments = NULL; > + break; > } > - jplis_assert(segments != (char**)NULL); > + segments = new_segments; > segments[count++] = c; > c = strchr(c, ' '); > if (c == NULL) { > break; > } > *c = '\0'; > c++; > } > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Tue Apr 12 21:34:40 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Apr 2016 15:34:40 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <570D64D3.8000005@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> Message-ID: <570D69F0.3040504@oracle.com> I'm also good with the fix. At this point, I think everyone who has commented on this fix previously has chimed in... Dan On 4/12/16 3:12 PM, Dmitry Samersoff wrote: > Alex, > > The fix looks good for me. > > -Dmitry > > > On 2016-04-12 22:28, Alex Henrie wrote: >> # HG changeset patch >> # User Alex Henrie >> # Date 1447827030 25200 >> # Tue Nov 17 23:10:30 2015 -0700 >> # Node ID 66c6fa3b2280afa12a2d51ea668b6a781b5744b5 >> # Parent 1f8c4b1a301c989dc299cad63dbc530b1de3ed70 >> 8145278: Fix memory leak in splitPathList >> >> diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c >> --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c >> +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c >> @@ -513,28 +513,32 @@ eventHandlerClassFileLoadHook( jvmtiEnv >> * The attribute value is in UTF8 but cannot contain NUL. Also non US-ASCII >> * characters must be escaped (URI syntax) so safe to iterate through the >> * value as a C string. >> */ >> static void >> splitPathList(const char* str, int* pathCount, char*** paths) { >> int count = 0; >> char** segments = NULL; >> + char** new_segments; >> char* c = (char*) str; >> while (*c != '\0') { >> while (*c == ' ') c++; /* skip leading spaces */ >> if (*c == '\0') { >> break; >> } >> - if (segments == NULL) { >> - segments = (char**)malloc( sizeof(char**) ); >> - } else { >> - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); >> + new_segments = (char**)realloc(segments, (count+1)*sizeof(char*)); >> + if (new_segments == NULL) { >> + jplis_assert(0); >> + free(segments); >> + count = 0; >> + segments = NULL; >> + break; >> } >> - jplis_assert(segments != (char**)NULL); >> + segments = new_segments; >> segments[count++] = c; >> c = strchr(c, ' '); >> if (c == NULL) { >> break; >> } >> *c = '\0'; >> c++; >> } >> > From alexhenrie24 at gmail.com Tue Apr 12 21:56:29 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 12 Apr 2016 15:56:29 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <570D69F0.3040504@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> Message-ID: 2016-04-12 15:34 GMT-06:00 Daniel D. Daugherty : > I'm also good with the fix. At this point, I think everyone who > has commented on this fix previously has chimed in... Yeah, this change shouldn't be controversial, I'm just waiting for someone to push it to the Mercurial repository. -Alex From serguei.spitsyn at oracle.com Wed Apr 13 01:35:07 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 18:35:07 -0700 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570D4CA5.2070505@oracle.com> References: <570C03AB.4020906@oracle.com> <570C4C8C.5060300@oracle.com> <570D4CA5.2070505@oracle.com> Message-ID: <570DA24B.6010804@oracle.com> On 4/12/16 12:29, Coleen Phillimore wrote: > > Hi Serguei, > > Thank you for looking at this change. > > On 4/11/16 9:17 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> - // Update the version number of the constant pool >> + // Update the version number of the constant pools (may keep >> scratch_cp) >> merge_cp->increment_and_save_version(old_cp->version()); >> + scratch_cp->increment_and_save_version(old_cp->version()); >> >> Not sure, I understand the change above. >> Could you, please, explain why this change is needed? >> I suspect, the scratch_cp->version() is never used. > > scratch_cp is used if it's equivalent to the old constant pool (see > the code below this with the comments). But it could add entries. In > this case, we want scratch_cp to have a new version number because > scratch_class->_source_file_name_index may be an appended entry > (old_cp->length() + n) which a parallel constant pool merge might > append a different entry and be set to the constant pool after the > safepoint. So source_file_name_index won't point to the first > appended entry. So I need to update the version also in scratch_cp to > detect this. Thank you for the explanation. I'm Ok with this change, just wanted to understand. I think, we have to prevent multiple class redefinitions (prologues) of the same class at the same time. Otherwise, it is hard to isolate and fix all potential issues in this scenario. I doubt, the original goal was to allow this. I've never investigated this corner case. It is not clear what happens with two merged constant pools prepared concurrently. We do not merge them again, right? Most likely, the last redefinition wins with some side effects. If so, then there has to be a way to detect and prevent this kind of concurrency. > > Actually, I made this change because I was going to make a bigger > change that compared constant pool entries if they were the same > version (ie both old_cp->version + 1), indicating parallel constant > pool merging. I decided this change was too much. > >> >> >> + // NOTE: this doesn't work because you can redefine the same class >> in two >> + // threads, each getting their own constant pool data appended to the >> + // original constant pool. In order for the new methods to work >> when they >> + // become old methods, they need to keep their updated copy of the >> constant pool. >> + >> It feels like the statement in this note is too strong, and as such, >> confusing. >> Would it be better to tell something like "not always work"? >> Otherwise, the question is: why do we need this block of code if it >> doesn't work? >> > > The block of code is #if 0'ed out. In my debugging I figured out why > it wouldn't work, so I thought I'd comment it. Oh, I see. In this particular case, I looked at the Udiff that does not show all the context. Please, consider it reviewed. Thanks, Serguei > > Thanks, > Coleen > >> >> Thanks, >> Serguei >> >> >> On 4/11/16 13:06, Coleen Phillimore wrote: >>> Summary: Constant pool merging is not thread safe for source_file_name. >>> >>> This change includes the change for the following bug because they >>> are tested together. >>> >>> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: >>> assert failed: Corrupted constant pool >>> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe >>> for MethodHandleInError and MethodTypeInError. >>> >>> The parallel constant pool merges are mostly harmless because the >>> old methods constant pool pointers aren't updated. The only case I >>> found where it isn't harmless is that we rely on finding the >>> source_file_name_index from the final merged constant pool, which >>> could be any of the parallel merged constant pools. The code to >>> attempt to dig out the name from redefined classes is removed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >>> >>> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >>> tried to write a test with all the conditions of the failure but >>> couldn't make it fail (so noreg-hard). >>> >>> Thanks, >>> Coleen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Apr 13 01:43:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Apr 2016 21:43:44 -0400 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570DA24B.6010804@oracle.com> References: <570C03AB.4020906@oracle.com> <570C4C8C.5060300@oracle.com> <570D4CA5.2070505@oracle.com> <570DA24B.6010804@oracle.com> Message-ID: <570DA450.5060607@oracle.com> Hi Serguei, On 4/12/16 9:35 PM, serguei.spitsyn at oracle.com wrote: > On 4/12/16 12:29, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> Thank you for looking at this change. >> >> On 4/11/16 9:17 PM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> - // Update the version number of the constant pool >>> + // Update the version number of the constant pools (may keep >>> scratch_cp) >>> merge_cp->increment_and_save_version(old_cp->version()); >>> + scratch_cp->increment_and_save_version(old_cp->version()); >>> >>> Not sure, I understand the change above. >>> Could you, please, explain why this change is needed? >>> I suspect, the scratch_cp->version() is never used. >> >> scratch_cp is used if it's equivalent to the old constant pool (see >> the code below this with the comments). But it could add entries. >> In this case, we want scratch_cp to have a new version number because >> scratch_class->_source_file_name_index may be an appended entry >> (old_cp->length() + n) which a parallel constant pool merge might >> append a different entry and be set to the constant pool after the >> safepoint. So source_file_name_index won't point to the first >> appended entry. So I need to update the version also in scratch_cp to >> detect this. > > Thank you for the explanation. > I'm Ok with this change, just wanted to understand. > > I think, we have to prevent multiple class redefinitions (prologues) > of the same class at the same time. > Otherwise, it is hard to isolate and fix all potential issues in this > scenario. > I doubt, the original goal was to allow this. > > I've never investigated this corner case. > It is not clear what happens with two merged constant pools prepared > concurrently. > We do not merge them again, right? > Most likely, the last redefinition wins with some side effects. > If so, then there has to be a way to detect and prevent this kind of > concurrency. Yes, if there are two constant pools prepared concurrently, the last one wins and will not contain any entries added by the other constant pool. I tried a change to detect concurrency and give an error. It's quite easy to detect with the constant pool versioning fixed. It failed a lot of our tests which do the same redefinition concurrently. I then tried a change to detect that the concurrent redefinition is incompatible. This change worked and I almost sent it out but since I couldn't write a test to provoke a failure in this case (because the old methods running are using their older constant pools), I decided to stick with the simplest fix to not depend on the constant pool index to be correct for the InstanceKlass::_source_file_name_index. So that's what happened. The ultimate answer is to stop merging constant pools. I have a repository with this change that passes all our tests but it's too big and risky of a change, ie needs more testing and verification, for this late in jdk9. I'd like to prepare it once the next release opens. > >> >> Actually, I made this change because I was going to make a bigger >> change that compared constant pool entries if they were the same >> version (ie both old_cp->version + 1), indicating parallel constant >> pool merging. I decided this change was too much. >> >>> >>> >>> + // NOTE: this doesn't work because you can redefine the same class >>> in two >>> + // threads, each getting their own constant pool data appended to the >>> + // original constant pool. In order for the new methods to work >>> when they >>> + // become old methods, they need to keep their updated copy of the >>> constant pool. >>> + >>> It feels like the statement in this note is too strong, and as such, >>> confusing. >>> Would it be better to tell something like "not always work"? >>> Otherwise, the question is: why do we need this block of code if it >>> doesn't work? >>> >> >> The block of code is #if 0'ed out. In my debugging I figured out >> why it wouldn't work, so I thought I'd comment it. > > Oh, I see. > In this particular case, I looked at the Udiff that does not show all > the context. > > Please, consider it reviewed. Thank you. It's great that you know this code so well to review this! Coleen > > Thanks, > Serguei > > >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/11/16 13:06, Coleen Phillimore wrote: >>>> Summary: Constant pool merging is not thread safe for >>>> source_file_name. >>>> >>>> This change includes the change for the following bug because they >>>> are tested together. >>>> >>>> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: >>>> assert failed: Corrupted constant pool >>>> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe >>>> for MethodHandleInError and MethodTypeInError. >>>> >>>> The parallel constant pool merges are mostly harmless because the >>>> old methods constant pool pointers aren't updated. The only case I >>>> found where it isn't harmless is that we rely on finding the >>>> source_file_name_index from the final merged constant pool, which >>>> could be any of the parallel merged constant pools. The code to >>>> attempt to dig out the name from redefined classes is removed. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >>>> >>>> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >>>> tried to write a test with all the conditions of the failure but >>>> couldn't make it fail (so noreg-hard). >>>> >>>> Thanks, >>>> Coleen >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Apr 13 02:24:06 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Apr 2016 19:24:06 -0700 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570DA450.5060607@oracle.com> References: <570C03AB.4020906@oracle.com> <570C4C8C.5060300@oracle.com> <570D4CA5.2070505@oracle.com> <570DA24B.6010804@oracle.com> <570DA450.5060607@oracle.com> Message-ID: <570DADC6.40003@oracle.com> On 4/12/16 18:43, Coleen Phillimore wrote: > > Hi Serguei, > > On 4/12/16 9:35 PM, serguei.spitsyn at oracle.com wrote: >> On 4/12/16 12:29, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> Thank you for looking at this change. >>> >>> On 4/11/16 9:17 PM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> - // Update the version number of the constant pool >>>> + // Update the version number of the constant pools (may keep >>>> scratch_cp) >>>> merge_cp->increment_and_save_version(old_cp->version()); >>>> + scratch_cp->increment_and_save_version(old_cp->version()); >>>> >>>> Not sure, I understand the change above. >>>> Could you, please, explain why this change is needed? >>>> I suspect, the scratch_cp->version() is never used. >>> >>> scratch_cp is used if it's equivalent to the old constant pool (see >>> the code below this with the comments). But it could add entries. >>> In this case, we want scratch_cp to have a new version number >>> because scratch_class->_source_file_name_index may be an appended >>> entry (old_cp->length() + n) which a parallel constant pool merge >>> might append a different entry and be set to the constant pool after >>> the safepoint. So source_file_name_index won't point to the first >>> appended entry. So I need to update the version also in scratch_cp >>> to detect this. >> >> Thank you for the explanation. >> I'm Ok with this change, just wanted to understand. >> >> I think, we have to prevent multiple class redefinitions (prologues) >> of the same class at the same time. >> Otherwise, it is hard to isolate and fix all potential issues in this >> scenario. >> I doubt, the original goal was to allow this. >> >> I've never investigated this corner case. >> It is not clear what happens with two merged constant pools prepared >> concurrently. >> We do not merge them again, right? >> Most likely, the last redefinition wins with some side effects. >> If so, then there has to be a way to detect and prevent this kind of >> concurrency. > > Yes, if there are two constant pools prepared concurrently, the last > one wins and will not contain any entries added by the other constant > pool. > > I tried a change to detect concurrency and give an error. It's quite > easy to detect with the constant pool versioning fixed. It failed a > lot of our tests which do the same redefinition concurrently. I then > tried a change to detect that the concurrent redefinition is > incompatible. This change worked and I almost sent it out but since I > couldn't write a test to provoke a failure in this case (because the > old methods running are using their older constant pools), I decided > to stick with the simplest fix to not depend on the constant pool > index to be correct for the InstanceKlass::_source_file_name_index. > > So that's what happened. > > The ultimate answer is to stop merging constant pools. I have a > repository with this change that passes all our tests but it's too big > and risky of a change, ie needs more testing and verification, for > this late in jdk9. I'd like to prepare it once the next release opens. I think, even with the constant pool merge removal it is still too dangerous to have multiple prologues executed concurrently. We already have the following bug covering this topic: https://bugs.openjdk.java.net/browse/JDK-6227506 JVMTI Spec: Atomicity of RedefineClasses should be specified Thanks, Serguei >> >>> >>> Actually, I made this change because I was going to make a bigger >>> change that compared constant pool entries if they were the same >>> version (ie both old_cp->version + 1), indicating parallel constant >>> pool merging. I decided this change was too much. >>> >>>> >>>> >>>> + // NOTE: this doesn't work because you can redefine the same >>>> class in two >>>> + // threads, each getting their own constant pool data appended to the >>>> + // original constant pool. In order for the new methods to work >>>> when they >>>> + // become old methods, they need to keep their updated copy of >>>> the constant pool. >>>> + >>>> It feels like the statement in this note is too strong, and as >>>> such, confusing. >>>> Would it be better to tell something like "not always work"? >>>> Otherwise, the question is: why do we need this block of code if it >>>> doesn't work? >>>> >>> >>> The block of code is #if 0'ed out. In my debugging I figured out >>> why it wouldn't work, so I thought I'd comment it. >> >> Oh, I see. >> In this particular case, I looked at the Udiff that does not show all >> the context. >> >> Please, consider it reviewed. > > Thank you. It's great that you know this code so well to review this! > > Coleen > >> >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/11/16 13:06, Coleen Phillimore wrote: >>>>> Summary: Constant pool merging is not thread safe for >>>>> source_file_name. >>>>> >>>>> This change includes the change for the following bug because they >>>>> are tested together. >>>>> >>>>> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: >>>>> assert failed: Corrupted constant pool >>>>> Summary: ConstantPool::resolve_constant_at_impl() isn't thread >>>>> safe for MethodHandleInError and MethodTypeInError. >>>>> >>>>> The parallel constant pool merges are mostly harmless because the >>>>> old methods constant pool pointers aren't updated. The only case >>>>> I found where it isn't harmless is that we rely on finding the >>>>> source_file_name_index from the final merged constant pool, which >>>>> could be any of the parallel merged constant pools. The code to >>>>> attempt to dig out the name from redefined classes is removed. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >>>>> >>>>> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >>>>> tried to write a test with all the conditions of the failure but >>>>> couldn't make it fail (so noreg-hard). >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Wed Apr 13 05:50:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 13 Apr 2016 07:50:17 +0200 Subject: RFR: 8154064: JVMTI trace event crashes Message-ID: <570DDE19.7000403@oracle.com> Hi all, Please review this bug fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 Test with tonga. (the 5 crashed tonga test no longer crashes) Thanks! /Robbin diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 +0000 +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 +0200 @@ -2260,7 +2260,7 @@ if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject alloc sent %s", JvmtiTrace::safe_get_thread_name(thread), - object==NULL? "NULL" : java_lang_Class::as_Klass(object)->external_name())); + object==NULL? "NULL" : object->klass()->external_name())); JvmtiVMObjectAllocEventMark jem(thread, h()); JvmtiJavaThreadEventTransition jet(thread); From staffan.larsen at oracle.com Wed Apr 13 06:02:09 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Apr 2016 08:02:09 +0200 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <570DDE19.7000403@oracle.com> References: <570DDE19.7000403@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 13 apr. 2016, at 07:50, Robbin Ehn wrote: > > Hi all, > > Please review this bug fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 > > Test with tonga. (the 5 crashed tonga test no longer crashes) > > Thanks! > > /Robbin > > diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 +0000 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 +0200 > @@ -2260,7 +2260,7 @@ > if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { > EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject alloc sent %s", > JvmtiTrace::safe_get_thread_name(thread), > - object==NULL? "NULL" : java_lang_Class::as_Klass(object)->external_name())); > + object==NULL? "NULL" : object->klass()->external_name())); > > JvmtiVMObjectAllocEventMark jem(thread, h()); > JvmtiJavaThreadEventTransition jet(thread); From robbin.ehn at oracle.com Wed Apr 13 06:19:49 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 13 Apr 2016 08:19:49 +0200 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: References: <570DDE19.7000403@oracle.com> Message-ID: <570DE505.5020609@oracle.com> Hi Staffan, Thanks! /Robbin On 04/13/2016 08:02 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 13 apr. 2016, at 07:50, Robbin Ehn wrote: >> >> Hi all, >> >> Please review this bug fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 >> >> Test with tonga. (the 5 crashed tonga test no longer crashes) >> >> Thanks! >> >> /Robbin >> >> diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 +0000 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 +0200 >> @@ -2260,7 +2260,7 @@ >> if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { >> EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject alloc sent %s", >> JvmtiTrace::safe_get_thread_name(thread), >> - object==NULL? "NULL" : java_lang_Class::as_Klass(object)->external_name())); >> + object==NULL? "NULL" : object->klass()->external_name())); >> >> JvmtiVMObjectAllocEventMark jem(thread, h()); >> JvmtiJavaThreadEventTransition jet(thread); > From stefan.karlsson at oracle.com Wed Apr 13 06:34:59 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Apr 2016 08:34:59 +0200 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <570DDE19.7000403@oracle.com> References: <570DDE19.7000403@oracle.com> Message-ID: <570DE893.6010606@oracle.com> Looks good. StefanK On 2016-04-13 07:50, Robbin Ehn wrote: > Hi all, > > Please review this bug fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 > > Test with tonga. (the 5 crashed tonga test no longer crashes) > > Thanks! > > /Robbin > > diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 > +0000 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 > +0200 > @@ -2260,7 +2260,7 @@ > if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { > EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt > vmobject alloc sent %s", > > JvmtiTrace::safe_get_thread_name(thread), > - object==NULL? "NULL" : > java_lang_Class::as_Klass(object)->external_name())); > + object==NULL? "NULL" : > object->klass()->external_name())); > > JvmtiVMObjectAllocEventMark jem(thread, h()); > JvmtiJavaThreadEventTransition jet(thread); From robbin.ehn at oracle.com Wed Apr 13 06:35:39 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 13 Apr 2016 08:35:39 +0200 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <570DE893.6010606@oracle.com> References: <570DDE19.7000403@oracle.com> <570DE893.6010606@oracle.com> Message-ID: <570DE8BB.9010900@oracle.com> Thanks Stefan! /Robbin On 04/13/2016 08:34 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-13 07:50, Robbin Ehn wrote: >> Hi all, >> >> Please review this bug fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 >> >> Test with tonga. (the 5 crashed tonga test no longer crashes) >> >> Thanks! >> >> /Robbin >> >> diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 >> +0000 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 >> +0200 >> @@ -2260,7 +2260,7 @@ >> if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { >> EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt >> vmobject alloc sent %s", >> >> JvmtiTrace::safe_get_thread_name(thread), >> - object==NULL? "NULL" : >> java_lang_Class::as_Klass(object)->external_name())); >> + object==NULL? "NULL" : >> object->klass()->external_name())); >> >> JvmtiVMObjectAllocEventMark jem(thread, h()); >> JvmtiJavaThreadEventTransition jet(thread); > From andreas.eriksson at oracle.com Wed Apr 13 08:55:19 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 13 Apr 2016 10:55:19 +0200 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <570D452C.6060806@oracle.com> References: <570D1CE0.1000108@oracle.com> <570D452C.6060806@oracle.com> Message-ID: <570E0977.9050401@oracle.com> Thanks Serguei! - Andreas On 2016-04-12 20:57, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > The fix looks good. > > Thanks, > Serguei > > > On 4/12/16 09:05, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for 8153641: assert(thread_state == >> _thread_in_native) failed: Assumed thread_in_native while heap dump >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ >> >> The crash is because changes I did in JDK-8129419 >> do not work with >> solaris logic used for UseVMInterruptibleIO in some cases. >> This change reverts the changes I did to the solaris version of >> os::write, and changes heapDumper.cpp to use ::write and ::close >> directly, as it did before. >> >> Thanks, >> Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Apr 13 09:06:51 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Apr 2016 12:06:51 +0300 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 In-Reply-To: <3F369530-693E-4842-9A03-1FD9D58A0BDC@oracle.com> References: <570CE9E7.8010407@oracle.com> <570D0718.4060104@oracle.com> <3F369530-693E-4842-9A03-1FD9D58A0BDC@oracle.com> Message-ID: <570E0C2B.4080604@oracle.com> Staffan, > Do you know if the change in jps output was intentional or caused by > something else? Sorry, I don't know what change jps output. -Dmitry On 2016-04-12 22:06, Staffan Larsen wrote: > Thanks for the explanation. The change looks good. > > Do you know if the change in jps output was intentional or caused by > something else? > > >> On 12 apr. 2016, at 16:32, Dmitry Samersoff >> > wrote: >> >> Staffan, >> >> On 2016-04-12 16:32, Staffan Larsen wrote: >>> Can you explain what is going on here? It looks like the old code >>> looked for the TTY process, whereas the new code accepts any process. >>> What am I missing? >> >> Both code select jdbCmd first: >> >> ll. 926 >> jdbCmd=`$jdk/bin/jps -v | $grep $jdbKeyword` >> >> then old code expect: >> >> 12199 TTY -Dapplication.home=/opt/jdk1.8.0_77 -Xms8m >> >> but for latest JDK9 jps -v return full class name: >> >> 12281 com.sun.tools.example.debug.tty.TTY -Dapplication.home=/opt/jdk9 >> -Xms8m -Djdk.module.main=jdk.jdi >> >> i.e. we get com.sun.tools.example.debug.tty.TTY instead of just TTY >> >> new code accept both variants. >> >> -Dmitry >> >> >>> >>>> On 12 apr. 2016, at 14:28, Dmitry Samersoff >>>> > >>>> wrote: >>>> >>>> Everybody, >>>> >>>> Please review a small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ >>>> >>>> This fix doesn't fix root cause of the test fail but fix small test >>>> bug to get better diagnostic. >>>> >>>> -Dmitry >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * I would love to change the world, but they won't give me >>>> the sources. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Apr 13 11:47:26 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Apr 2016 13:47:26 +0200 Subject: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1 In-Reply-To: <570E0C2B.4080604@oracle.com> References: <570CE9E7.8010407@oracle.com> <570D0718.4060104@oracle.com> <3F369530-693E-4842-9A03-1FD9D58A0BDC@oracle.com> <570E0C2B.4080604@oracle.com> Message-ID: > On 13 apr. 2016, at 11:06, Dmitry Samersoff wrote: > > Staffan, > >> Do you know if the change in jps output was intentional or caused by >> something else? > > Sorry, I don't know what change jps output. The problem is that the sun.java.command property has changed format with jigsaw. If the main-class is in a module the property will be on the format "jdk.jdi/com.sun.tools.example.debug.tty.TTY?. MonitoredVmUtil.mainClass() fails in parsing this new format and returns the full classname even when not to. I wonder if this is good or bad, what other dependencies there are on sun.java.command and what the impact will be... > > -Dmitry > > > On 2016-04-12 22:06, Staffan Larsen wrote: >> Thanks for the explanation. The change looks good. >> >> Do you know if the change in jps output was intentional or caused by >> something else? >> >> >>> On 12 apr. 2016, at 16:32, Dmitry Samersoff >>> > wrote: >>> >>> Staffan, >>> >>> On 2016-04-12 16:32, Staffan Larsen wrote: >>>> Can you explain what is going on here? It looks like the old code >>>> looked for the TTY process, whereas the new code accepts any process. >>>> What am I missing? >>> >>> Both code select jdbCmd first: >>> >>> ll. 926 >>> jdbCmd=`$jdk/bin/jps -v | $grep $jdbKeyword` >>> >>> then old code expect: >>> >>> 12199 TTY -Dapplication.home=/opt/jdk1.8.0_77 -Xms8m >>> >>> but for latest JDK9 jps -v return full class name: >>> >>> 12281 com.sun.tools.example.debug.tty.TTY -Dapplication.home=/opt/jdk9 >>> -Xms8m -Djdk.module.main=jdk.jdi >>> >>> i.e. we get com.sun.tools.example.debug.tty.TTY instead of just TTY >>> >>> new code accept both variants. >>> >>> -Dmitry >>> >>> >>>> >>>>> On 12 apr. 2016, at 14:28, Dmitry Samersoff >>>>> > >>>>> wrote: >>>>> >>>>> Everybody, >>>>> >>>>> Please review a small fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8153856/webrev.01/ >>>>> >>>>> This fix doesn't fix root cause of the test fail but fix small test >>>>> bug to get better diagnostic. >>>>> >>>>> -Dmitry >>>>> >>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>>> Russia * I would love to change the world, but they won't give me >>>>> the sources. >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Wed Apr 13 12:20:25 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 13 Apr 2016 21:20:25 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <570485B0.70200@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> Message-ID: <570E3989.1090305@gmail.com> Hi all, Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ If it is not accepted, I think that we can add new field to PerfMemory for using in JSnap: ----------------------- diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 2016 +0000 +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 2016 +0900 @@ -45,11 +45,16 @@ UINT_CHARS + 1; char* PerfMemory::_start = NULL; +char* PerfMemory::_saved_start = NULL; char* PerfMemory::_end = NULL; +char* PerfMemory::_saved_end = NULL; char* PerfMemory::_top = NULL; +char* PerfMemory::_saved_top = NULL; size_t PerfMemory::_capacity = 0; +size_t PerfMemory::_saved_capacity = 0; jint PerfMemory::_initialized = false; PerfDataPrologue* PerfMemory::_prologue = NULL; +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; void perfMemory_init() { @@ -103,6 +108,8 @@ // allocate PerfData memory region create_memory_region(capacity); + _saved_start = _start; + _saved_capacity = _capacity; if (_start == NULL) { @@ -132,8 +139,11 @@ } _prologue = (PerfDataPrologue *)_start; + _saved_prologue = _prologue; _end = _start + _capacity; + _saved_end = _end; _top = _start + sizeof(PerfDataPrologue); + _saved_top = _top; } assert(_prologue != NULL, "prologue pointer must be initialized"); ----------------------- If it is better, I will upload a webrev. Thanks, Yasumasa On 2016/04/06 12:42, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thanks for your comment. > > I uploaded a new webrev. Could you review again? > http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ > > On 2016/04/06 0:31, Dmitry Samersoff wrote: >> Yasumasa, >> >> 1. It's better to change JSnap code to produce meaningful error message >> instead of NPE. > > I added null check and set message to PerfMemory.java . > > >> 2. We should check that no other consumer of perf counters rely on the >> fact it's NULL after call to destroy(). I'm not sure that this part of >> the fix is not dangerous. > > I added new flag (_destroyed) in PerfMemory class. > This flag set true at PerfMemory::destroy(). > > _start, _end, and more field which I removed from destroy() are private member of > PerfMemory. I implemented that the getter functions of them check _destroyed flag, > and returns same value before this change. > > So I think this change does not affect other place. > > > Thanks, > > Yasumasa > > >> -Dmitry >> >> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> >>> >>> Yasumasa >>> >>> >>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>> Yasumasa >>>> >>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>> >: >>>> >>>> Hi all, >>>> >>>> When I use `jhsdb jsnap` to get PerfCounter from core images, I >>>> encountered NPE: >>>> ------------- >>>> Exception in thread "main" java.lang.NullPointerException >>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>> at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>> ------------- >>>> >>>> PerfMemory::destroy() clears all members which are used in JSnap. >>>> Thus NPE is occurred. >>>> >>>> I uploaded webrev for this issue. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>> >>>> I cannot access JPRT. >>>> So I need a Sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >> >> From dmitry.samersoff at oracle.com Wed Apr 13 12:41:01 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Apr 2016 15:41:01 +0300 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <570E3989.1090305@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> Message-ID: <570E3E5D.9030801@oracle.com> Yasumasa, Yes. It's better. Please place all _saved_* declarations together and add a comment explaining what is the purpose of this variables. -Dmitry On 2016-04-13 15:20, Yasumasa Suenaga wrote: > Hi all, > > Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ > > If it is not accepted, I think that we can add new field to PerfMemory > for using in JSnap: > ----------------------- > diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp > --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 2016 +0000 > +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 2016 +0900 > @@ -45,11 +45,16 @@ > UINT_CHARS + 1; > > char* PerfMemory::_start = NULL; > +char* PerfMemory::_saved_start = NULL; > char* PerfMemory::_end = NULL; > +char* PerfMemory::_saved_end = NULL; > char* PerfMemory::_top = NULL; > +char* PerfMemory::_saved_top = NULL; > size_t PerfMemory::_capacity = 0; > +size_t PerfMemory::_saved_capacity = 0; > jint PerfMemory::_initialized = false; > PerfDataPrologue* PerfMemory::_prologue = NULL; > +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; > > void perfMemory_init() { > > @@ -103,6 +108,8 @@ > > // allocate PerfData memory region > create_memory_region(capacity); > + _saved_start = _start; > + _saved_capacity = _capacity; > > if (_start == NULL) { > > @@ -132,8 +139,11 @@ > } > > _prologue = (PerfDataPrologue *)_start; > + _saved_prologue = _prologue; > _end = _start + _capacity; > + _saved_end = _end; > _top = _start + sizeof(PerfDataPrologue); > + _saved_top = _top; > } > > assert(_prologue != NULL, "prologue pointer must be initialized"); > ----------------------- > > If it is better, I will upload a webrev. > > > Thanks, > > Yasumasa > > > On 2016/04/06 12:42, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> Thanks for your comment. >> >> I uploaded a new webrev. Could you review again? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >> >> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> 1. It's better to change JSnap code to produce meaningful error message >>> instead of NPE. >> >> I added null check and set message to PerfMemory.java . >> >> >>> 2. We should check that no other consumer of perf counters rely on the >>> fact it's NULL after call to destroy(). I'm not sure that this part of >>> the fix is not dangerous. >> >> I added new flag (_destroyed) in PerfMemory class. >> This flag set true at PerfMemory::destroy(). >> >> _start, _end, and more field which I removed from destroy() are >> private member of >> PerfMemory. I implemented that the getter functions of them check >> _destroyed flag, >> and returns same value before this change. >> >> So I think this change does not affect other place. >> >> >> Thanks, >> >> Yasumasa >> >> >>> -Dmitry >>> >>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>> PING: Could you review it? >>>>> >>>>> Yasumasa >>>>> >>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>> >: >>>>> >>>>> Hi all, >>>>> >>>>> When I use `jhsdb jsnap` to get PerfCounter from core images, I >>>>> encountered NPE: >>>>> ------------- >>>>> Exception in thread "main" java.lang.NullPointerException >>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>> at >>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>> at >>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>> ------------- >>>>> >>>>> PerfMemory::destroy() clears all members which are used in JSnap. >>>>> Thus NPE is occurred. >>>>> >>>>> I uploaded webrev for this issue. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>> >>>>> I cannot access JPRT. >>>>> So I need a Sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Wed Apr 13 13:22:58 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 13 Apr 2016 22:22:58 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <570E3E5D.9030801@oracle.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> Message-ID: <570E4832.9040701@gmail.com> Hi Dmitry, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ Thanks, Yasumasa On 2016/04/13 21:41, Dmitry Samersoff wrote: > Yasumasa, > > Yes. It's better. > > Please place all _saved_* declarations together and add a comment > explaining what is the purpose of this variables. > > -Dmitry > > > On 2016-04-13 15:20, Yasumasa Suenaga wrote: >> Hi all, >> >> Could you review and sponsor it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >> >> If it is not accepted, I think that we can add new field to PerfMemory >> for using in JSnap: >> ----------------------- >> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 2016 +0000 >> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 2016 +0900 >> @@ -45,11 +45,16 @@ >> UINT_CHARS + 1; >> >> char* PerfMemory::_start = NULL; >> +char* PerfMemory::_saved_start = NULL; >> char* PerfMemory::_end = NULL; >> +char* PerfMemory::_saved_end = NULL; >> char* PerfMemory::_top = NULL; >> +char* PerfMemory::_saved_top = NULL; >> size_t PerfMemory::_capacity = 0; >> +size_t PerfMemory::_saved_capacity = 0; >> jint PerfMemory::_initialized = false; >> PerfDataPrologue* PerfMemory::_prologue = NULL; >> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >> >> void perfMemory_init() { >> >> @@ -103,6 +108,8 @@ >> >> // allocate PerfData memory region >> create_memory_region(capacity); >> + _saved_start = _start; >> + _saved_capacity = _capacity; >> >> if (_start == NULL) { >> >> @@ -132,8 +139,11 @@ >> } >> >> _prologue = (PerfDataPrologue *)_start; >> + _saved_prologue = _prologue; >> _end = _start + _capacity; >> + _saved_end = _end; >> _top = _start + sizeof(PerfDataPrologue); >> + _saved_top = _top; >> } >> >> assert(_prologue != NULL, "prologue pointer must be initialized"); >> ----------------------- >> >> If it is better, I will upload a webrev. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>> Hi Dmitry, >>> >>> Thanks for your comment. >>> >>> I uploaded a new webrev. Could you review again? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>> >>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>> Yasumasa, >>>> >>>> 1. It's better to change JSnap code to produce meaningful error message >>>> instead of NPE. >>> >>> I added null check and set message to PerfMemory.java . >>> >>> >>>> 2. We should check that no other consumer of perf counters rely on the >>>> fact it's NULL after call to destroy(). I'm not sure that this part of >>>> the fix is not dangerous. >>> >>> I added new flag (_destroyed) in PerfMemory class. >>> This flag set true at PerfMemory::destroy(). >>> >>> _start, _end, and more field which I removed from destroy() are >>> private member of >>> PerfMemory. I implemented that the getter functions of them check >>> _destroyed flag, >>> and returns same value before this change. >>> >>> So I think this change does not affect other place. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> -Dmitry >>>> >>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>> PING: Could you review it? >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>> PING: Could you review it? >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>> >: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> When I use `jhsdb jsnap` to get PerfCounter from core images, I >>>>>> encountered NPE: >>>>>> ------------- >>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>> at >>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>> at >>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>> ------------- >>>>>> >>>>>> PerfMemory::destroy() clears all members which are used in JSnap. >>>>>> Thus NPE is occurred. >>>>>> >>>>>> I uploaded webrev for this issue. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>> >>>>>> I cannot access JPRT. >>>>>> So I need a Sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>> >>>> > > From daniel.daugherty at oracle.com Wed Apr 13 16:07:40 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Apr 2016 10:07:40 -0600 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570C03AB.4020906@oracle.com> References: <570C03AB.4020906@oracle.com> Message-ID: <570E6ECC.5050900@oracle.com> On 4/11/16 2:06 PM, Coleen Phillimore wrote: > Summary: Constant pool merging is not thread safe for source_file_name. > > This change includes the change for the following bug because they are > tested together. > > 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert > failed: Corrupted constant pool > Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe > for MethodHandleInError and MethodTypeInError. > > The parallel constant pool merges are mostly harmless because the old > methods constant pool pointers aren't updated. The only case I found > where it isn't harmless is that we rely on finding the > source_file_name_index from the final merged constant pool, which > could be any of the parallel merged constant pools. The code to > attempt to dig out the name from redefined classes is removed. > > open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev src/share/vm/classfile/javaClasses.inline.hpp Perhaps instead of this comment: L226: // Because constant pools can be merged in parallel, the source file name index L227: // may be merged over with something else in a previous version. please consider this one: // RedefineClasses() currently permits redefine operations to // happen in parallel using a "last one wins" philosophy. That // spec laxness allows the constant pool entry associated with // the source_file_name_index for any older constant pool version // to be unstable so we shouldn't try to use it. src/share/vm/oops/constantPool.hpp I think this file is all changes from 8148772 which I've already reviewed so no comments. src/share/vm/oops/constantPool.cpp I think this file is all changes from 8148772 which I've already reviewed so no comments. src/share/vm/prims/jvmtiRedefineClasses.cpp The version number in the constant pool is new to my brain since I last dove into this code in detail... Right now you do the version increment here: L1445: // Update the version number of the constant pools (may keep scratch_cp) L1446: merge_cp->increment_and_save_version(old_cp->version()); L1447: scratch_cp->increment_and_save_version(old_cp->version()); You could choose to only do it when you know that you're going to keep the scratch_cp, but maybe that's being too picky. Serguei's find of this very old bug is good: JDK-6227506 JVMTI Spec: Atomicity of RedefineClasses should be specified https://bugs.openjdk.java.net/browse/JDK-6227506 There's another bug out there will all the notes that Tim Bell took when we did the monster RedefineClasses code walk through. I believe in that bug, the lack of locking/atomicity was also called out. I'll see if I can find that bug... Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8151546 > > Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I > tried to write a test with all the conditions of the failure but > couldn't make it fail (so noreg-hard). > > Thanks, > Coleen From dmitry.samersoff at oracle.com Wed Apr 13 16:24:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 13 Apr 2016 19:24:18 +0300 Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS Message-ID: <570E72B2.404@oracle.com> Everybody. Please review a small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ I don't have a reproducer, so the fix is based on coredump analyzes. Tested with rbt -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Wed Apr 13 16:48:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Apr 2016 12:48:43 -0400 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570E6ECC.5050900@oracle.com> References: <570C03AB.4020906@oracle.com> <570E6ECC.5050900@oracle.com> Message-ID: <570E786B.2030701@oracle.com> Dan, Thank you for reviewing this. On 4/13/16 12:07 PM, Daniel D. Daugherty wrote: > On 4/11/16 2:06 PM, Coleen Phillimore wrote: >> Summary: Constant pool merging is not thread safe for source_file_name. >> >> This change includes the change for the following bug because they >> are tested together. >> >> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert >> failed: Corrupted constant pool >> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe >> for MethodHandleInError and MethodTypeInError. >> >> The parallel constant pool merges are mostly harmless because the old >> methods constant pool pointers aren't updated. The only case I found >> where it isn't harmless is that we rely on finding the >> source_file_name_index from the final merged constant pool, which >> could be any of the parallel merged constant pools. The code to >> attempt to dig out the name from redefined classes is removed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev > > src/share/vm/classfile/javaClasses.inline.hpp > Perhaps instead of this comment: > > L226: // Because constant pools can be merged in parallel, the > source file name index > L227: // may be merged over with something else in a previous > version. > > please consider this one: > > // RedefineClasses() currently permits redefine operations to > // happen in parallel using a "last one wins" philosophy. That > // spec laxness allows the constant pool entry associated with > // the source_file_name_index for any older constant pool version > // to be unstable so we shouldn't try to use it. Okay, your comment is more complete. I'll use your comment. > > src/share/vm/oops/constantPool.hpp > I think this file is all changes from 8148772 which I've already > reviewed so no comments. > > src/share/vm/oops/constantPool.cpp > I think this file is all changes from 8148772 which I've already > reviewed so no comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > The version number in the constant pool is new to my brain since > I last dove into this code in detail... > > Right now you do the version increment here: > > L1445: // Update the version number of the constant pools (may > keep scratch_cp) > L1446: merge_cp->increment_and_save_version(old_cp->version()); > L1447: scratch_cp->increment_and_save_version(old_cp->version()); > > You could choose to only do it when you know that you're going > to keep the scratch_cp, but maybe that's being too picky. > I'd have to set it in two places if I did that, so I picked just once. If we use the merged_cp, the scratch_cp is discarded so the version doesn't matter. > Serguei's find of this very old bug is good: > > JDK-6227506 JVMTI Spec: Atomicity of RedefineClasses should be specified > https://bugs.openjdk.java.net/browse/JDK-6227506 > > There's another bug out there will all the notes that Tim Bell > took when we did the monster RedefineClasses code walk through. > I believe in that bug, the lack of locking/atomicity was also > called out. I'll see if I can find that bug... > Yes, that would be good. There are a lot of statics in VM_RedefineClasses. I don't know why these don't cause bugs! Coleen > Dan > > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >> >> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >> tried to write a test with all the conditions of the failure but >> couldn't make it fail (so noreg-hard). >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Wed Apr 13 17:00:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Apr 2016 10:00:05 -0700 Subject: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly In-Reply-To: <570E786B.2030701@oracle.com> References: <570C03AB.4020906@oracle.com> <570E6ECC.5050900@oracle.com> <570E786B.2030701@oracle.com> Message-ID: <570E7B15.9030201@oracle.com> On 4/13/16 09:48, Coleen Phillimore wrote: > > Dan, Thank you for reviewing this. > > On 4/13/16 12:07 PM, Daniel D. Daugherty wrote: >> On 4/11/16 2:06 PM, Coleen Phillimore wrote: >>> Summary: Constant pool merging is not thread safe for source_file_name. >>> >>> This change includes the change for the following bug because they >>> are tested together. >>> >>> 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: >>> assert failed: Corrupted constant pool >>> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe >>> for MethodHandleInError and MethodTypeInError. >>> >>> The parallel constant pool merges are mostly harmless because the >>> old methods constant pool pointers aren't updated. The only case I >>> found where it isn't harmless is that we rely on finding the >>> source_file_name_index from the final merged constant pool, which >>> could be any of the parallel merged constant pools. The code to >>> attempt to dig out the name from redefined classes is removed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8151546.01/webrev >> >> src/share/vm/classfile/javaClasses.inline.hpp >> Perhaps instead of this comment: >> >> L226: // Because constant pools can be merged in parallel, the >> source file name index >> L227: // may be merged over with something else in a previous >> version. >> >> please consider this one: >> >> // RedefineClasses() currently permits redefine operations to >> // happen in parallel using a "last one wins" philosophy. That >> // spec laxness allows the constant pool entry associated with >> // the source_file_name_index for any older constant pool version >> // to be unstable so we shouldn't try to use it. > > Okay, your comment is more complete. I'll use your comment. >> >> src/share/vm/oops/constantPool.hpp >> I think this file is all changes from 8148772 which I've already >> reviewed so no comments. >> >> src/share/vm/oops/constantPool.cpp >> I think this file is all changes from 8148772 which I've already >> reviewed so no comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> The version number in the constant pool is new to my brain since >> I last dove into this code in detail... >> >> Right now you do the version increment here: >> >> L1445: // Update the version number of the constant pools (may >> keep scratch_cp) >> L1446: merge_cp->increment_and_save_version(old_cp->version()); >> L1447: scratch_cp->increment_and_save_version(old_cp->version()); >> >> You could choose to only do it when you know that you're going >> to keep the scratch_cp, but maybe that's being too picky. >> > > I'd have to set it in two places if I did that, so I picked just > once. If we use the merged_cp, the scratch_cp is discarded so the > version doesn't matter. > >> Serguei's find of this very old bug is good: >> >> JDK-6227506 JVMTI Spec: Atomicity of RedefineClasses should be specified >> https://bugs.openjdk.java.net/browse/JDK-6227506 >> >> There's another bug out there will all the notes that Tim Bell >> took when we did the monster RedefineClasses code walk through. >> I believe in that bug, the lack of locking/atomicity was also >> called out. I'll see if I can find that bug... >> > > Yes, that would be good. There are a lot of statics in > VM_RedefineClasses. > I don't know why these don't cause bugs! I think, they do but very rarely and intermittently. This is rare corner case when two agents or two threads of one agent do concurrent redefinitions. Thanks, Serguei > > Coleen > >> Dan >> >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8151546 >>> >>> Tested with rbt, java/lang/instrument tests, com/sun/jdi tests. I >>> tried to write a test with all the conditions of the failure but >>> couldn't make it fail (so noreg-hard). >>> >>> Thanks, >>> Coleen >> > From calvin.cheung at oracle.com Wed Apr 13 20:03:56 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Apr 2016 13:03:56 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> Message-ID: <570EA62C.4080605@oracle.com> Hi Ioi, Just a few minor comments. No need to see another webrev. compactHashtable.cpp: 71 _num_entries ++; extra space before ++ similarly in lines 80, 112, 123, 125 118 Entry tent = bucket->at(i); It is clearer if 'tent' is just 'ent' since the code in this block is not dealing with tiny entry. 249 while (entry Ioi, > >> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >> >> Hi Jiangli, >> >> >> Thanks for the review: >> >> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. >>> >>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? >>> >> OK, I will make the change. >> >>> - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. >>> >> I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. > I filed JDK-8154108. > >>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { >>> 172 address base_address = address(MetaspaceShared::shared_rs()->base()); >>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>> >>> - Why is the default RO space size increased? >>> >> That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. > Ok. > > Thanks, > Jiangli > >>> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>> Copyright year. >> Will fix. >> >> Thanks >> - Ioi >>> Thanks, >>> Jiangli >>> >>>> On Mar 31, 2016, at 10:43 PM, Ioi Lam> wrote: >>>> >>>> Please review >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>> >>>> Bug: Clean up CompactHashtable >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>> >>>> Summary of fix: >>>> >>>> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >>>> error prone, use SimpleCompactHashtable::serialize(), which is more >>>> structural. >>>> >>>> [2] Split up the _buckets and _entries into two separate arrays, so the >>>> dumping and walking code is easier to understand >>>> >>>> (see comments above SimpleCompactHashtable declaration) >>>> These 2 arrays are now allocated from the RO region (used to be in RW) >>>> >>>> [3] Renamed a few things >>>> >>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>> (having something called "compact" in CompactHashtable is confusing) >>>> >>>> The old names "dump_table" (actually dumping the buckets) and >>>> "dump_buckets" (actually dumping the entries) were conflicting with >>>> terminology used elsewhere. Now the terminology is unified: >>>> "buckets" = the main index, "entries" = the second level. >>>> >>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>> >>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>> checked with assert. >>>> >>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>> >>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>> SimpleCompactHashtable::iterate) >>>> >>>> [7] I also added a test case using Serviceability Agent -- due to the lack of >>>> a regression test, the walking of the compact hashtable in SA had been >>>> broken for a while before it was fixed in JDK-8151368, so having a test >>>> case would make the code more maintainable. >>>> >>>> Tests: >>>> >>>> Hotspot JTREG tests >>>> >>>> Thanks >>>> - Ioi From poonam.bajaj at oracle.com Wed Apr 13 20:49:07 2016 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Wed, 13 Apr 2016 13:49:07 -0700 Subject: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist In-Reply-To: <570BF7C7.6080204@oracle.com> References: <570BF7C7.6080204@oracle.com> Message-ID: <570EB0C3.9090400@oracle.com> Hello, As per Erik's suggestion not to remove the existing check for HS_ALT_MAKE, here is the updated webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.01/ Thanks, Poonam On 4/11/2016 12:15 PM, Poonam Bajaj Parhar wrote: > Hello, > > Please review this simple fix. > > Bug JDK-8153252 : > SA: Hotspot build on Windows fails if make/closed folder does not exist > > Problem: The problem is that the SA build on windows fails while > building non-openjdk commercial sources that don't contain the > make/closed folder. > nmake -nologo -f D:\ws\8u-dev\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 > nmake in ./generated > cd generated && "d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f D:\ws\8u-dev\hotspot\make\windows\makefiles\ > generated.make DIR=.\generated BUILD_FLAVOR=product > D:\ws\8u-dev\hotspot/make/windows/makefiles/sa.make(54) : fatal error U1052: file 'D:\ws\8u-dev\hotspot/make/closed/windows/makefiles/sa.make' not found > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Fix: Add a check to ensure that the make/closed folder exists. > > Webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.00/ > > Thanks, > Poonam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Apr 14 07:12:24 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Apr 2016 10:12:24 +0300 Subject: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist In-Reply-To: <570EB0C3.9090400@oracle.com> References: <570BF7C7.6080204@oracle.com> <570EB0C3.9090400@oracle.com> Message-ID: <570F42D8.60908@oracle.com> Poonam, Looks good for me! -Dmitry On 2016-04-13 23:49, Poonam Bajaj Parhar wrote: > Hello, > > As per Erik's suggestion not to remove the existing check for > HS_ALT_MAKE, here is the updated webrev: > http://cr.openjdk.java.net/~poonam/8153252/webrev.01/ > > Thanks, > Poonam > > On 4/11/2016 12:15 PM, Poonam Bajaj Parhar wrote: >> Hello, >> >> Please review this simple fix. >> >> Bug JDK-8153252 : >> SA: Hotspot build on Windows fails if make/closed folder does not exist >> >> Problem: The problem is that the SA build on windows fails while >> building non-openjdk commercial sources that don't contain the >> make/closed folder. >> nmake -nologo -f D:\ws\8u-dev\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 >> nmake in ./generated >> cd generated && "d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f D:\ws\8u-dev\hotspot\make\windows\makefiles\ >> generated.make DIR=.\generated BUILD_FLAVOR=product >> D:\ws\8u-dev\hotspot/make/windows/makefiles/sa.make(54) : fatal error U1052: file 'D:\ws\8u-dev\hotspot/make/closed/windows/makefiles/sa.make' not found >> Stop. >> NMAKE : fatal error U1077: 'cd' : return code '0x2' >> Fix: Add a check to ensure that the make/closed folder exists. >> >> Webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.00/ >> >> Thanks, >> Poonam >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Thu Apr 14 07:37:14 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Apr 2016 09:37:14 +0200 Subject: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist In-Reply-To: <570EB0C3.9090400@oracle.com> References: <570BF7C7.6080204@oracle.com> <570EB0C3.9090400@oracle.com> Message-ID: <570F48AA.60806@oracle.com> Looks good to me. /Erik On 2016-04-13 22:49, Poonam Bajaj Parhar wrote: > Hello, > > As per Erik's suggestion not to remove the existing check for > HS_ALT_MAKE, here is the updated webrev: > http://cr.openjdk.java.net/~poonam/8153252/webrev.01/ > > Thanks, > Poonam > > On 4/11/2016 12:15 PM, Poonam Bajaj Parhar wrote: >> Hello, >> >> Please review this simple fix. >> >> Bug JDK-8153252 : >> SA: Hotspot build on Windows fails if make/closed folder does not exist >> >> Problem: The problem is that the SA build on windows fails while >> building non-openjdk commercial sources that don't contain the >> make/closed folder. >> nmake -nologo -f D:\ws\8u-dev\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 >> nmake in ./generated >> cd generated && "d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f D:\ws\8u-dev\hotspot\make\windows\makefiles\ >> generated.make DIR=.\generated BUILD_FLAVOR=product >> D:\ws\8u-dev\hotspot/make/windows/makefiles/sa.make(54) : fatal error U1052: file 'D:\ws\8u-dev\hotspot/make/closed/windows/makefiles/sa.make' not found >> Stop. >> NMAKE : fatal error U1077: 'cd' : return code '0x2' >> Fix: Add a check to ensure that the make/closed folder exists. >> >> Webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.00/ >> >> Thanks, >> Poonam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 14 08:24:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 01:24:17 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events Message-ID: <570F53B1.90809@oracle.com> Please, review the Jigsaw-related fix for: https://bugs.openjdk.java.net/browse/JDK-8153749 Hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ Jdk webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ Summary: This is a Jigsaw related enhancement. Some agents need to get a CFLH event for classes loaded in the primordial phase. This is not possible in JDK 9 because existing agents may instrument code in the primordial or start phase before the module system has completed initialization. We introduce a new capability: can_generate_early_class_hook_events. If this capability and can_generate_all_class_hook_events are enabled then the CFLH event could be posted for classes loaded in the primordial phase. We leave can_generate_early_vmstart as is, no changes. This enhancement needs a CCC request filed. I will file it once the JVMTI spec changes are reviewed. Testing: Altered the nsk.jvmti co-located test nsk/jvmti/ClassFileLoadHook/classfloadhk002 to enable the can_generate_early_class_hook_events and checked that new CFLH events are posted in the primordial phase and also they are not posted otherwise. Thanks, Serguei From serguei.spitsyn at oracle.com Thu Apr 14 08:35:04 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 01:35:04 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> Message-ID: <570F5638.1030708@oracle.com> Alex, Your fix has been pushed. Thanks, Serguei On 4/12/16 14:56, Alex Henrie wrote: > 2016-04-12 15:34 GMT-06:00 Daniel D. Daugherty : >> I'm also good with the fix. At this point, I think everyone who >> has commented on this fix previously has chimed in... > Yeah, this change shouldn't be controversial, I'm just waiting for > someone to push it to the Mercurial repository. > > -Alex From dmitry.samersoff at oracle.com Thu Apr 14 09:24:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Apr 2016 12:24:34 +0300 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570F53B1.90809@oracle.com> References: <570F53B1.90809@oracle.com> Message-ID: <570F61D2.3070602@oracle.com> Serguei, Looks good for me. -Dmitry On 2016-04-14 11:24, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw-related fix for: > https://bugs.openjdk.java.net/browse/JDK-8153749 > > > Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ > > > > Summary: > > This is a Jigsaw related enhancement. > Some agents need to get a CFLH event for classes loaded in the > primordial phase. > This is not possible in JDK 9 because existing agents may instrument > code in the > primordial or start phase before the module system has completed > initialization. > > We introduce a new capability: can_generate_early_class_hook_events. > If this capability and can_generate_all_class_hook_events are enabled > then > the CFLH event could be posted for classes loaded in the primordial > phase. > We leave can_generate_early_vmstart as is, no changes. > > This enhancement needs a CCC request filed. > I will file it once the JVMTI spec changes are reviewed. > > > Testing: > Altered the nsk.jvmti co-located test > nsk/jvmti/ClassFileLoadHook/classfloadhk002 > to enable the can_generate_early_class_hook_events and checked that > new CFLH events > are posted in the primordial phase and also they are not posted > otherwise. > > > Thanks, > Serguei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu Apr 14 09:25:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 02:25:41 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570F61D2.3070602@oracle.com> References: <570F53B1.90809@oracle.com> <570F61D2.3070602@oracle.com> Message-ID: <570F6215.9020504@oracle.com> Thanks, Dmitry! Serguei On 4/14/16 02:24, Dmitry Samersoff wrote: > Serguei, > > Looks good for me. > > -Dmitry > > > On 2016-04-14 11:24, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw-related fix for: >> https://bugs.openjdk.java.net/browse/JDK-8153749 >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >> >> >> >> Summary: >> >> This is a Jigsaw related enhancement. >> Some agents need to get a CFLH event for classes loaded in the >> primordial phase. >> This is not possible in JDK 9 because existing agents may instrument >> code in the >> primordial or start phase before the module system has completed >> initialization. >> >> We introduce a new capability: can_generate_early_class_hook_events. >> If this capability and can_generate_all_class_hook_events are enabled >> then >> the CFLH event could be posted for classes loaded in the primordial >> phase. >> We leave can_generate_early_vmstart as is, no changes. >> >> This enhancement needs a CCC request filed. >> I will file it once the JVMTI spec changes are reviewed. >> >> >> Testing: >> Altered the nsk.jvmti co-located test >> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >> to enable the can_generate_early_class_hook_events and checked that >> new CFLH events >> are posted in the primordial phase and also they are not posted >> otherwise. >> >> >> Thanks, >> Serguei >> > From robbin.ehn at oracle.com Thu Apr 14 11:36:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 13:36:17 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging Message-ID: <570F80B1.5020602@oracle.com> Hi all, Please review: This moves jvmti trace output to the tag jvmti on trace level. The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have a lot of functionality, e.g. can filter on func, in/out, etc, so it if left as is. TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti tag is set. Webrev: http://cr.openjdk.java.net/~rehn/8154041/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 Thanks! /Robbin From robbin.ehn at oracle.com Thu Apr 14 11:52:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 13:52:57 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL Message-ID: <570F8499.7070604@oracle.com> Hi all, Please review: This moves jvmti object-tagging output to the tag-set jvmti,objecttagging on debug level. The TraceJVMTIObjectTagging argument is deprecated and aliased with: "-Xlog:jvmti+objecttagging=debug" Did this on top of: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html but only part common is the jvmti tag (logTag.hpp). Webrev: http://cr.openjdk.java.net/~rehn/8154059/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 Thanks! /Robbin From Alan.Bateman at oracle.com Thu Apr 14 13:53:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2016 14:53:44 +0100 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570F53B1.90809@oracle.com> References: <570F53B1.90809@oracle.com> Message-ID: <570FA0E8.5080606@oracle.com> On 14/04/2016 09:24, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw-related fix for: > https://bugs.openjdk.java.net/browse/JDK-8153749 > > > Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ > > This looks good, just a few suggests for the JVM TI spec For can_generate_early_class_hook_events then it might be better if the first sentence said "in the primordial phase" rather than "early". In CFLH then alternative wording is "When can_generate_early_class_hook_events and can_generate_early_class_hook_events are enabled then this event may be send before the VM is initialized (the start phase)". I think that might be more consistent with the long standing wording. -Alan. From serguei.spitsyn at oracle.com Thu Apr 14 18:35:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 11:35:08 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570FA0E8.5080606@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> Message-ID: <570FE2DC.4060601@oracle.com> On 4/14/16 06:53, Alan Bateman wrote: > > > On 14/04/2016 09:24, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw-related fix for: >> https://bugs.openjdk.java.net/browse/JDK-8153749 >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >> >> > This looks good, just a few suggests for the JVM TI spec > > For can_generate_early_class_hook_events then it might be better if > the first sentence said "in the primordial phase" rather than "early". Agreed, fixed. > > In CFLH then alternative wording is "When > can_generate_early_class_hook_events and > can_generate_early_class_hook_events are enabled then this event > may be send before the VM is initialized (the start phase)". I think > that might be more consistent with the long standing wording. Not sure, I understand the suggestion. This is what was before the fix: "This event may be sent before the VM is initialized (the start phase)". Now it is: "The timing of this event may depend on whether the agent has added the can_generate_early_class_hook_events capability or not. If the capability has been added then the VM posts the event in the primordial phase. Otherwise, this event may be sent before the VM is initialized (the start phase). " What part do we want to change? Would you like it to be like this: "The timing of this event may depend on whether the agent has added the can_generate_early_class_hook_events and can_generate_all_class_hook_events capabilities or not. If the capabilities have been added then the VM posts the event in the primordial phase. Otherwise, this event may be sent before the VM is initialized (the start phase). " or it is about something like this: "When can_generate_early_class_hook_events and can_generate_all_class_hook_events are enabled then this event may be sent in the primordial phase. Otherwise, this event may be sent before the VM is initialized (the start phase). " Thanks, Serguei > > -Alan. > From Alan.Bateman at oracle.com Thu Apr 14 20:00:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2016 21:00:24 +0100 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570FE2DC.4060601@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> <570FE2DC.4060601@oracle.com> Message-ID: <570FF6D8.8030404@oracle.com> On 14/04/2016 19:35, serguei.spitsyn at oracle.com wrote: > : > > > or it is about something like this: > "When can_generate_early_class_hook_events and > can_generate_all_class_hook_events > are enabled then this event may be sent in the primordial phase. > Otherwise, this event may be sent before the VM is initialized (the > start phase). " Sorry, I wasn't clear. This version is exactly what I meant. -Alan From serguei.spitsyn at oracle.com Thu Apr 14 20:02:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 13:02:58 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570FF6D8.8030404@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> <570FE2DC.4060601@oracle.com> <570FF6D8.8030404@oracle.com> Message-ID: <570FF772.3050004@oracle.com> On 4/14/16 13:00, Alan Bateman wrote: > > > On 14/04/2016 19:35, serguei.spitsyn at oracle.com wrote: >> : >> >> >> or it is about something like this: >> "When can_generate_early_class_hook_events and >> can_generate_all_class_hook_events >> are enabled then this event may be sent in the primordial phase. >> Otherwise, this event may be sent before the VM is initialized (the >> start phase). " > Sorry, I wasn't clear. This version is exactly what I meant. Nice. Thank you for the suggestion. Thanks, Serguei > > -Alan > From serguei.spitsyn at oracle.com Thu Apr 14 20:30:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Apr 2016 13:30:44 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570FA0E8.5080606@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> Message-ID: <570FFDF4.8080806@oracle.com> Alan, This is for sanity check: The updated hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/ Please, note that the *src/share/vm/prims/jvmtiEnvBase.hpp* was corrected too. Please, find the JVMTI spec here: http:://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/jvmti.html Thanks, Serguei On 4/14/16 06:53, Alan Bateman wrote: > > > On 14/04/2016 09:24, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw-related fix for: >> https://bugs.openjdk.java.net/browse/JDK-8153749 >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >> >> > This looks good, just a few suggests for the JVM TI spec > > For can_generate_early_class_hook_events then it might be better if > the first sentence said "in the primordial phase" rather than "early". > > In CFLH then alternative wording is "When > can_generate_early_class_hook_events and > can_generate_early_class_hook_events are enabled then this event > may be send before the VM is initialized (the start phase)". I think > that might be more consistent with the long standing wording. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Apr 15 11:00:32 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 15 Apr 2016 13:00:32 +0200 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <570D1CE0.1000108@oracle.com> References: <570D1CE0.1000108@oracle.com> Message-ID: <76C1D33C-DE07-4FBF-BFE9-BFC692FECD40@oracle.com> Looks good! Thanks, /Staffan > On 12 apr. 2016, at 18:05, Andreas Eriksson wrote: > > Hi, > > Please review this fix for 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 > Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ > > The crash is because changes I did in JDK-8129419 do not work with solaris logic used for UseVMInterruptibleIO in some cases. > This change reverts the changes I did to the solaris version of os::write, and changes heapDumper.cpp to use ::write and ::close directly, as it did before. > > Thanks, > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Apr 15 11:00:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Apr 2016 12:00:47 +0100 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570FFDF4.8080806@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> <570FFDF4.8080806@oracle.com> Message-ID: <5710C9DF.9090007@oracle.com> On 14/04/2016 21:30, serguei.spitsyn at oracle.com wrote: > Alan, > > This is for sanity check: > > The updated hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/ > > Please, note that the *src/share/vm/prims/jvmtiEnvBase.hpp* was > corrected too. > In can_generate_early_class_hook_events then "can be posted" or "may be posted" might be better than "could be posted". Also the end tag '>' at L10002 should be probably be on the proceeding line. Otherwise looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.eriksson at oracle.com Fri Apr 15 11:14:03 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Fri, 15 Apr 2016 13:14:03 +0200 Subject: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump In-Reply-To: <76C1D33C-DE07-4FBF-BFE9-BFC692FECD40@oracle.com> References: <570D1CE0.1000108@oracle.com> <76C1D33C-DE07-4FBF-BFE9-BFC692FECD40@oracle.com> Message-ID: <5710CCFB.2060303@oracle.com> Thanks Staffan! - Andreas On 2016-04-15 13:00, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 12 apr. 2016, at 18:05, Andreas Eriksson >> > wrote: >> >> Hi, >> >> Please review this fix for 8153641: assert(thread_state == >> _thread_in_native) failed: Assumed thread_in_native while heap dump >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153641 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8153641/webrev.00/ >> >> The crash is because changes I did in JDK-8129419 >> do not work with >> solaris logic used for UseVMInterruptibleIO in some cases. >> This change reverts the changes I did to the solaris version of >> os::write, and changes heapDumper.cpp to use ::write and ::close >> directly, as it did before. >> >> Thanks, >> Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Fri Apr 15 13:43:28 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Apr 2016 15:43:28 +0200 Subject: PerfData counter: sun.gc.policy.generations in JDK 8 In-Reply-To: References: <556E1D31.1040507@oracle.com> Message-ID: <5710F000.6070708@oracle.com> Hi Ramki and Jon, What's the status of this review thread? The bug is still open and targeted for JDK 9. Thanks, StefanK On 2015-06-03 08:15, Srinivas Ramakrishna wrote: > Thanks Jon for the review and the pointer to the test. I'll get back > to you later this week with a suitable test. > > -- Ramki > > ysr1729 > > On Jun 2, 2015, at 14:16, Jon Masamitsu > wrote: > >> Ramki, >> >> Changes look good. >> >> I'm guessing you tested by generating the >> perfdata by hand and verifying the contents >> of the perfdata. Do you think a test can >> be written to verify the change? If you look at >> >> test/gc/metaspace/TestMetaspacePerfCounters.java >> >> in your repository I think that is an example that >> can be followed. >> >> It's a jtreg test. >> >> http://openjdk.java.net/jtreg/ >> >> Jon >> >> On 06/01/2015 11:39 AM, Srinivas Ramakrishna wrote: >>> Thanks for the review of the patch for 8-dev (from the ticket), >>> Staffan. >>> >>> Sorry for the delay in getting the official webrev out -- it took me >>> a while to first get set up with an hs9 repo (thanks Jon!) and then >>> get my openjdk credentials updated (thanks Mark!). >>> >>> Here's the webrev against hs9 for official review:- >>> >>> http://cr.openjdk.java.net/~ysr/JDK-8080345/webrev.00/ >>> >>> >>> I built and tested the change (on both 8-dev whose patch was >>> attached with the original bug, as well as this with hs9) and >>> verified that the counter value for generations, in the perfdata >>> file, was now 2 instead of the previous 3. >>> >>> thanks! >>> -- ramki >>> >>> >>> On Mon, May 18, 2015 at 1:22 AM, Staffan Larsen >>> > wrote: >>> >>> Looks like a good patch to me. >>> >>> /Staffan >>> >>>> On 14 maj 2015, at 18:12, Srinivas Ramakrishna >>>> > wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8080345 >>>> >>>> >>>> >>>> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna >>>> > wrote: >>>> >>>> >>>> With perm gen going away (and being replaced by metaspace) >>>> in JDK 8, it makes sense that the counter >>>> sun.gc.policy.generations should be "2", rather than "3". >>>> However, in JDK 8 that counter still says 3. >>>> As I understand, the intention was that this counter would >>>> allow you to (for example) know the range of >>>> the sun.gc.generation.$num.* counters describing each of >>>> $num < sun.gc.policy.generations in the heap. >>>> Recall that the erstwhile perm gen in JDK 7 used to be >>>> synonymous with sun.gc.generation.2, but the >>>> JDK 8 avatars are now sun.gc.metaspace and >>>> sun.gc.compressedclassspace. >>>> >>>> The fix is simple, and I can submit a patch. Is there an >>>> existing bug for this? >>>> >>>> thanks! >>>> -- ramki >>>> >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.eriksson at oracle.com Fri Apr 15 14:40:21 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Fri, 15 Apr 2016 16:40:21 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof Message-ID: <5710FD55.9060209@oracle.com> Hi, Please review this test fix for 8149790: NegativeArraySizeException with hprof https://bugs.openjdk.java.net/browse/JDK-8149790 http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ Changes are to the hprof verifier, which now will pass heap dump content around as JavaThing arrays instead of byte arrays, since the latter cannot be guaranteed to be able to hold all the elements of large arrays. There is still a problem where the test will timeout on machines with lots of memory (seen on machines with 200+GB of memory) because the verification takes a long time. I'll file a new bug for that problem. Regards, Andreas From sgehwolf at redhat.com Fri Apr 15 16:53:53 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Apr 2016 18:53:53 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Message-ID: <1460739233.4653.25.camel@redhat.com> Hi, Here is a patch which is a redo of the fix for JDK-4858370 which got backed out due to it causing test regressions. Specifically problems were reported for?com/sun/jdi/InvokeTest.java and?com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 applied. Those test regressions were caused because: a.) The fix for JDK-4858370 deleted refs from the request object ? ? while *not* holding the invoker lock. b.) Invokes done via?invoker_doInvoke() save global references, but ? ? don't hold the invoker lock either. This new fix grabs relevant locks for both cases above. Testing done: ?- com/sun/jdi test set. No regressions + added regression test. ?- com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 ? ?invocations. Same for com/sun/jdi/InvokeTest.java. ?- I haven't seen any crashes in new OomDebugTest.java either. Bug:?https://bugs.openjdk.java.net/browse/JDK-8153711 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ Once reviewed, I'd need somebody to sponsor this patch. Thanks, Severin From serguei.spitsyn at oracle.com Fri Apr 15 17:17:28 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Apr 2016 10:17:28 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <5710C9DF.9090007@oracle.com> References: <570F53B1.90809@oracle.com> <570FA0E8.5080606@oracle.com> <570FFDF4.8080806@oracle.com> <5710C9DF.9090007@oracle.com> Message-ID: <57112228.5040201@oracle.com> On 4/15/16 04:00, Alan Bateman wrote: > > > On 14/04/2016 21:30, serguei.spitsyn at oracle.com wrote: >> Alan, >> >> This is for sanity check: >> >> The updated hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/ >> >> Please, note that the *src/share/vm/prims/jvmtiEnvBase.hpp* was >> corrected too. >> > In can_generate_early_class_hook_events then "can be posted" or "may > be posted" might be better than "could be posted". Also the end tag > '>' at L10002 should be probably be on the proceeding line. Fixed, thanks. > > Otherwise looks okay to me. Thanks, Alan! Serguei > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 15 18:14:14 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Apr 2016 11:14:14 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1460739233.4653.25.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> Message-ID: <57112F76.9020203@oracle.com> Hi Severin, The fix looks good to me. I can sponsor the fix once it is reviewed. Not sure, if I need to run the previously failed tests in the big loops or rely on your testing. Included Dan who did a back out into the cc-list. Thanks a lot for taking care to redo the fix! Thanks, Serguei On 4/15/16 09:53, Severin Gehwolf wrote: > Hi, > > Here is a patch which is a redo of the fix for JDK-4858370 which got > backed out due to it causing test regressions. Specifically problems > were reported for com/sun/jdi/InvokeTest.java > and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 > applied. > > Those test regressions were caused because: > a.) The fix for JDK-4858370 deleted refs from the request object > while *not* holding the invoker lock. > b.) Invokes done via invoker_doInvoke() save global references, but > don't hold the invoker lock either. > > This new fix grabs relevant locks for both cases above. > > Testing done: > - com/sun/jdi test set. No regressions + added regression test. > - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 > invocations. Same for com/sun/jdi/InvokeTest.java. > - I haven't seen any crashes in new OomDebugTest.java either. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ > > Once reviewed, I'd need somebody to sponsor this patch. > > Thanks, > Severin From erik.gahlin at oracle.com Fri Apr 15 18:21:29 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 15 Apr 2016 20:21:29 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof In-Reply-To: <5710FD55.9060209@oracle.com> References: <5710FD55.9060209@oracle.com> Message-ID: <57113129.5060802@oracle.com> Looks good, not a Reviewer. Do you really need curly braces in the switch clauses? Erik On 2016-04-15 16:40, Andreas Eriksson wrote: > Hi, > > Please review this test fix for 8149790: NegativeArraySizeException > with hprof > > https://bugs.openjdk.java.net/browse/JDK-8149790 > http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ > > Changes are to the hprof verifier, which now will pass heap dump > content around as JavaThing arrays instead of byte arrays, since the > latter cannot be guaranteed to be able to hold all the elements of > large arrays. > > There is still a problem where the test will timeout on machines with > lots of memory (seen on machines with 200+GB of memory) because the > verification takes a long time. I'll file a new bug for that problem. > > Regards, > Andreas From dmitry.samersoff at oracle.com Fri Apr 15 18:59:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 15 Apr 2016 21:59:34 +0300 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1460739233.4653.25.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> Message-ID: <57113A16.2010909@oracle.com> Severin, Looks good for me. But I'm a little afraid of the fact that now we are holding eventHandler_lock while doing invoke*. So please hold on with backports until the fix bakes in jdk9 for some time. -Dmitry On 2016-04-15 19:53, Severin Gehwolf wrote: > Hi, > > Here is a patch which is a redo of the fix for JDK-4858370 which got > backed out due to it causing test regressions. Specifically problems > were reported for com/sun/jdi/InvokeTest.java > and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 > applied. > > Those test regressions were caused because: > a.) The fix for JDK-4858370 deleted refs from the request object > while *not* holding the invoker lock. > b.) Invokes done via invoker_doInvoke() save global references, but > don't hold the invoker lock either. > > This new fix grabs relevant locks for both cases above. > > Testing done: > - com/sun/jdi test set. No regressions + added regression test. > - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 > invocations. Same for com/sun/jdi/InvokeTest.java. > - I haven't seen any crashes in new OomDebugTest.java either. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ > > Once reviewed, I'd need somebody to sponsor this patch. > > Thanks, > Severin > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Apr 15 20:52:21 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Apr 2016 13:52:21 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57113A16.2010909@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> Message-ID: <57115485.6090305@oracle.com> On 4/15/16 11:59, Dmitry Samersoff wrote: > Severin, > > Looks good for me. > > But I'm a little afraid of the fact that now we are holding > eventHandler_lock while doing invoke*. It seems, I have this concern too. Please, let me take a look closer at this part if it is done in a right way. > > So please hold on with backports until the fix bakes in jdk9 for some time. +1 Thanks, Serguei > > -Dmitry > > On 2016-04-15 19:53, Severin Gehwolf wrote: >> Hi, >> >> Here is a patch which is a redo of the fix for JDK-4858370 which got >> backed out due to it causing test regressions. Specifically problems >> were reported for com/sun/jdi/InvokeTest.java >> and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 >> applied. >> >> Those test regressions were caused because: >> a.) The fix for JDK-4858370 deleted refs from the request object >> while *not* holding the invoker lock. >> b.) Invokes done via invoker_doInvoke() save global references, but >> don't hold the invoker lock either. >> >> This new fix grabs relevant locks for both cases above. >> >> Testing done: >> - com/sun/jdi test set. No regressions + added regression test. >> - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 >> invocations. Same for com/sun/jdi/InvokeTest.java. >> - I haven't seen any crashes in new OomDebugTest.java either. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ >> >> Once reviewed, I'd need somebody to sponsor this patch. >> >> Thanks, >> Severin >> > From david.holmes at oracle.com Sun Apr 17 10:22:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Apr 2016 20:22:08 +1000 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <570DDE19.7000403@oracle.com> References: <570DDE19.7000403@oracle.com> Message-ID: <571363D0.9010407@oracle.com> Hi Robbin, Can you clarify here and/or in the bug report exactly what it was that changed to cause this crash. It seems the original code expects "object" to be a class, while it is actually an instance that has a class. Thanks, David On 13/04/2016 3:50 PM, Robbin Ehn wrote: > Hi all, > > Please review this bug fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 > > Test with tonga. (the 5 crashed tonga test no longer crashes) > > Thanks! > > /Robbin > > diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 +0000 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 +0200 > @@ -2260,7 +2260,7 @@ > if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { > EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject > alloc sent %s", > > JvmtiTrace::safe_get_thread_name(thread), > - object==NULL? "NULL" : > java_lang_Class::as_Klass(object)->external_name())); > + object==NULL? "NULL" : > object->klass()->external_name())); > > JvmtiVMObjectAllocEventMark jem(thread, h()); > JvmtiJavaThreadEventTransition jet(thread); From ioi.lam at oracle.com Sun Apr 17 14:32:32 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 17 Apr 2016 07:32:32 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <570EA62C.4080605@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> Message-ID: <57139E80.7090105@oracle.com> Hi Calvin, Thanks for the review. Please see my comments inside. On 4/13/16 1:03 PM, Calvin Cheung wrote: > Hi Ioi, > > Just a few minor comments. No need to see another webrev. > compactHashtable.cpp: > > 71 _num_entries ++; > > extra space before ++ > similarly in lines 80, 112, 123, 125 > I grepped the hotspot source code with '[a-z] [+][+]' and found that there are quite a few cases of putting a space between the variable name and "++". Other lines in compactHashtable.cpp that are not changed by this patch also use "++". The HotSpot coding guide (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't mention the "++" operator specifically, so I'll leave the space there for now. > 118 Entry tent = bucket->at(i); > > It is clearer if 'tent' is just 'ent' since the code in this block is > not dealing with tiny entry. > Changed tent -> ent > 249 while (entry > Needs a space before entry_max. > Fixed. > > SASymbolTableTest.java: > > The result of p.getPid() can be saved into a local variable so that it > won't need to be done twice in lines 86 and 93. > Fixed. Thanks - Ioi > thanks, > Calvin > > On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >> Ioi, >> >>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>> >>> Hi Jiangli, >>> >>> >>> Thanks for the review: >>> >>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> I like the more structural way of reading/writing the compact table >>>> with SimpleCompactHashtable. It looks quite clean overall. >>>> >>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>> than TINY_BUCKET_TYPE? >>>> >>> OK, I will make the change. >>> >>>> - The following assert in CompactSymbolTableWriter::add() limits >>>> the total shared space size to be less than MAX_SHARED_DELTA >>>> unnecessarily. Symbols are allocated from the RO space at dump >>>> time. We only need to make sure the max delta between the >>>> ?base_address? and the end of RO space is less than >>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>> change, you don?t have to address that as part of this change if >>>> you prefer. I?ll file a separate RFE. >>>> >>> I think it's better to do this in a separate RFE since >>> MAX_SHARED_DELTA is used elsewhere as well. >> I filed JDK-8154108. >> >>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>> *symbol) { >>>> 172 address base_address = >>>> address(MetaspaceShared::shared_rs()->base()); >>>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>> >>>> - Why is the default RO space size increased? >>>> >>> That's because the symbol table is moved from RW to RO, so I had to >>> change the RO minimum size, or else >>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >> Ok. >> >> Thanks, >> Jiangli >> >>>> - >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>> - >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>> Copyright year. >>> Will fix. >>> >>> Thanks >>> - Ioi >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>> Lam> wrote: >>>>> >>>>> Please review >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>> >>>>> >>>>> Bug: Clean up CompactHashtable >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>> >>>>> Summary of fix: >>>>> >>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>> tedious and >>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>> more >>>>> structural. >>>>> >>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>> so the >>>>> dumping and walking code is easier to understand >>>>> >>>>> (see comments above SimpleCompactHashtable declaration) >>>>> These 2 arrays are now allocated from the RO region (used to >>>>> be in RW) >>>>> >>>>> [3] Renamed a few things >>>>> >>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>> (having something called "compact" in CompactHashtable is >>>>> confusing) >>>>> >>>>> The old names "dump_table" (actually dumping the buckets) and >>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>> with >>>>> terminology used elsewhere. Now the terminology is unified: >>>>> "buckets" = the main index, "entries" = the second level. >>>>> >>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>> >>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>> checked with assert. >>>>> >>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>> >>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>> SimpleCompactHashtable::iterate) >>>>> >>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>> the lack of >>>>> a regression test, the walking of the compact hashtable in SA >>>>> had been >>>>> broken for a while before it was fixed in JDK-8151368, so >>>>> having a test >>>>> case would make the code more maintainable. >>>>> >>>>> Tests: >>>>> >>>>> Hotspot JTREG tests >>>>> >>>>> Thanks >>>>> - Ioi From robbin.ehn at oracle.com Sun Apr 17 19:16:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Sun, 17 Apr 2016 21:16:35 +0200 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <571363D0.9010407@oracle.com> References: <570DDE19.7000403@oracle.com> <571363D0.9010407@oracle.com> Message-ID: <5713E113.5040604@oracle.com> Hi David, Sorry for the lack of context. I was running jvmti tests (tonga nsk.jvmti) with full jvmti trace on, which is not something we normally do. I don't have the full history here and I do not know how often people use jvmti trace. But my understanding is that this can have been broken for a long time. I did not dig any deeper. (most of the file is from duke) /Robbin On 04/17/2016 12:22 PM, David Holmes wrote: > Hi Robbin, > > Can you clarify here and/or in the bug report exactly what it was that > changed to cause this crash. It seems the original code expects > "object" to be a class, while it is actually an instance that has a > class. > > Thanks, > David > > On 13/04/2016 3:50 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review this bug fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 >> >> Test with tonga. (the 5 crashed tonga test no longer crashes) >> >> Thanks! >> >> /Robbin >> >> diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 >> +0000 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 >> +0200 >> @@ -2260,7 +2260,7 @@ >> if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { >> EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject >> alloc sent %s", >> >> JvmtiTrace::safe_get_thread_name(thread), >> - object==NULL? "NULL" : >> java_lang_Class::as_Klass(object)->external_name())); >> + object==NULL? "NULL" : >> object->klass()->external_name())); >> >> JvmtiVMObjectAllocEventMark jem(thread, h()); >> JvmtiJavaThreadEventTransition jet(thread); From david.holmes at oracle.com Sun Apr 17 23:08:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Apr 2016 09:08:27 +1000 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <57139E80.7090105@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> <57139E80.7090105@oracle.com> Message-ID: <5714176B.1090406@oracle.com> On 18/04/2016 12:32 AM, Ioi Lam wrote: > Hi Calvin, > > Thanks for the review. Please see my comments inside. > > On 4/13/16 1:03 PM, Calvin Cheung wrote: >> Hi Ioi, >> >> Just a few minor comments. No need to see another webrev. >> compactHashtable.cpp: >> >> 71 _num_entries ++; >> >> extra space before ++ >> similarly in lines 80, 112, 123, 125 >> > I grepped the hotspot source code with '[a-z] [+][+]' and found that > there are quite a few cases of putting a space between the variable name > and "++". Other lines in compactHashtable.cpp that are not changed by > this patch also use "++". The HotSpot coding guide > (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't > mention the "++" operator specifically, so I'll leave the space there > for now. Then we need to update the style guide - unary operators (like the booleans the guide does mention) should not have a space between the operator and operand. Cheers, David ----- > >> 118 Entry tent = bucket->at(i); >> >> It is clearer if 'tent' is just 'ent' since the code in this block is >> not dealing with tiny entry. >> > Changed tent -> ent > >> 249 while (entry > >> Needs a space before entry_max. >> > Fixed. >> >> SASymbolTableTest.java: >> >> The result of p.getPid() can be saved into a local variable so that it >> won't need to be done twice in lines 86 and 93. >> > Fixed. > > Thanks > - Ioi >> thanks, >> Calvin >> >> On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >>> Ioi, >>> >>>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>>> >>>> Hi Jiangli, >>>> >>>> >>>> Thanks for the review: >>>> >>>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>>> Hi Ioi, >>>>> >>>>> I like the more structural way of reading/writing the compact table >>>>> with SimpleCompactHashtable. It looks quite clean overall. >>>>> >>>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>>> than TINY_BUCKET_TYPE? >>>>> >>>> OK, I will make the change. >>>> >>>>> - The following assert in CompactSymbolTableWriter::add() limits >>>>> the total shared space size to be less than MAX_SHARED_DELTA >>>>> unnecessarily. Symbols are allocated from the RO space at dump >>>>> time. We only need to make sure the max delta between the >>>>> ?base_address? and the end of RO space is less than >>>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>>> change, you don?t have to address that as part of this change if >>>>> you prefer. I?ll file a separate RFE. >>>>> >>>> I think it's better to do this in a separate RFE since >>>> MAX_SHARED_DELTA is used elsewhere as well. >>> I filed JDK-8154108. >>> >>>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>>> *symbol) { >>>>> 172 address base_address = >>>>> address(MetaspaceShared::shared_rs()->base()); >>>>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>>> >>>>> - Why is the default RO space size increased? >>>>> >>>> That's because the symbol table is moved from RW to RO, so I had to >>>> change the RO minimum size, or else >>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >>> Ok. >>> >>> Thanks, >>> Jiangli >>> >>>>> - >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>>> >>>>> - >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>>> >>>>> Copyright year. >>>> Will fix. >>>> >>>> Thanks >>>> - Ioi >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>>> Lam> wrote: >>>>>> >>>>>> Please review >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>>> >>>>>> >>>>>> Bug: Clean up CompactHashtable >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>>> >>>>>> >>>>>> Summary of fix: >>>>>> >>>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>>> tedious and >>>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>>> more >>>>>> structural. >>>>>> >>>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>>> so the >>>>>> dumping and walking code is easier to understand >>>>>> >>>>>> (see comments above SimpleCompactHashtable declaration) >>>>>> These 2 arrays are now allocated from the RO region (used to >>>>>> be in RW) >>>>>> >>>>>> [3] Renamed a few things >>>>>> >>>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>>> (having something called "compact" in CompactHashtable is >>>>>> confusing) >>>>>> >>>>>> The old names "dump_table" (actually dumping the buckets) and >>>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>>> with >>>>>> terminology used elsewhere. Now the terminology is unified: >>>>>> "buckets" = the main index, "entries" = the second level. >>>>>> >>>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>>> >>>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>>> checked with assert. >>>>>> >>>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>>> >>>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>>> SimpleCompactHashtable::iterate) >>>>>> >>>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>>> the lack of >>>>>> a regression test, the walking of the compact hashtable in SA >>>>>> had been >>>>>> broken for a while before it was fixed in JDK-8151368, so >>>>>> having a test >>>>>> case would make the code more maintainable. >>>>>> >>>>>> Tests: >>>>>> >>>>>> Hotspot JTREG tests >>>>>> >>>>>> Thanks >>>>>> - Ioi > From david.holmes at oracle.com Sun Apr 17 23:12:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Apr 2016 09:12:28 +1000 Subject: RFR: 8154064: JVMTI trace event crashes In-Reply-To: <5713E113.5040604@oracle.com> References: <570DDE19.7000403@oracle.com> <571363D0.9010407@oracle.com> <5713E113.5040604@oracle.com> Message-ID: <5714185C.9080204@oracle.com> On 18/04/2016 5:16 AM, Robbin Ehn wrote: > Hi David, > > Sorry for the lack of context. > > I was running jvmti tests (tonga nsk.jvmti) with full jvmti trace on, > which is not something we normally do. > I don't have the full history here and I do not know how often people > use jvmti trace. > But my understanding is that this can have been broken for a long time. Ah I see. Okay - please add that to the bug report if you haven't already. Thanks. David > I did not dig any deeper. (most of the file is from duke) > > /Robbin > > On 04/17/2016 12:22 PM, David Holmes wrote: >> Hi Robbin, >> >> Can you clarify here and/or in the bug report exactly what it was that >> changed to cause this crash. It seems the original code expects >> "object" to be a class, while it is actually an instance that has a >> class. >> >> Thanks, >> David >> >> On 13/04/2016 3:50 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review this bug fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154064 >>> >>> Test with tonga. (the 5 crashed tonga test no longer crashes) >>> >>> Thanks! >>> >>> /Robbin >>> >>> diff -r 4823056a5bbd src/share/vm/prims/jvmtiExport.cpp >>> --- a/src/share/vm/prims/jvmtiExport.cpp Tue Apr 12 09:08:48 2016 >>> +0000 >>> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 13 07:39:50 2016 >>> +0200 >>> @@ -2260,7 +2260,7 @@ >>> if (env->is_enabled(JVMTI_EVENT_VM_OBJECT_ALLOC)) { >>> EVT_TRACE(JVMTI_EVENT_VM_OBJECT_ALLOC, ("JVMTI [%s] Evt vmobject >>> alloc sent %s", >>> >>> JvmtiTrace::safe_get_thread_name(thread), >>> - object==NULL? "NULL" : >>> java_lang_Class::as_Klass(object)->external_name())); >>> + object==NULL? "NULL" : >>> object->klass()->external_name())); >>> >>> JvmtiVMObjectAllocEventMark jem(thread, h()); >>> JvmtiJavaThreadEventTransition jet(thread); > From ioi.lam at oracle.com Mon Apr 18 02:25:15 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 17 Apr 2016 19:25:15 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <5714176B.1090406@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> <57139E80.7090105@oracle.com> <5714176B.1090406@oracle.com> Message-ID: <5714458B.1050206@oracle.com> On 4/17/16 4:08 PM, David Holmes wrote: > On 18/04/2016 12:32 AM, Ioi Lam wrote: >> Hi Calvin, >> >> Thanks for the review. Please see my comments inside. >> >> On 4/13/16 1:03 PM, Calvin Cheung wrote: >>> Hi Ioi, >>> >>> Just a few minor comments. No need to see another webrev. >>> compactHashtable.cpp: >>> >>> 71 _num_entries ++; >>> >>> extra space before ++ >>> similarly in lines 80, 112, 123, 125 >>> >> I grepped the hotspot source code with '[a-z] [+][+]' and found that >> there are quite a few cases of putting a space between the variable name >> and "++". Other lines in compactHashtable.cpp that are not changed by >> this patch also use "++". The HotSpot coding guide >> (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't >> mention the "++" operator specifically, so I'll leave the space there >> for now. > > Then we need to update the style guide - unary operators (like the > booleans the guide does mention) should not have a space between the > operator and operand. > OK, I have updated the webrev to fix the "++" issues on compactHashtable.cpp/hpp. I'll leave the other files as-is. This webrev also contains the feedbacks from Calvin and Jiangli in the previous mails. These are stylistic changes, variable renaming, etc with no change in functionality. http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v03/ Thanks - Ioi > Cheers, > David > ----- > > >> >>> 118 Entry tent = bucket->at(i); >>> >>> It is clearer if 'tent' is just 'ent' since the code in this block is >>> not dealing with tiny entry. >>> >> Changed tent -> ent >> >>> 249 while (entry >> >>> Needs a space before entry_max. >>> >> Fixed. >>> >>> SASymbolTableTest.java: >>> >>> The result of p.getPid() can be saved into a local variable so that it >>> won't need to be done twice in lines 86 and 93. >>> >> Fixed. >> >> Thanks >> - Ioi >>> thanks, >>> Calvin >>> >>> On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >>>> Ioi, >>>> >>>>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> >>>>> Thanks for the review: >>>>> >>>>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>>>> Hi Ioi, >>>>>> >>>>>> I like the more structural way of reading/writing the compact table >>>>>> with SimpleCompactHashtable. It looks quite clean overall. >>>>>> >>>>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>>>> than TINY_BUCKET_TYPE? >>>>>> >>>>> OK, I will make the change. >>>>> >>>>>> - The following assert in CompactSymbolTableWriter::add() limits >>>>>> the total shared space size to be less than MAX_SHARED_DELTA >>>>>> unnecessarily. Symbols are allocated from the RO space at dump >>>>>> time. We only need to make sure the max delta between the >>>>>> ?base_address? and the end of RO space is less than >>>>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>>>> change, you don?t have to address that as part of this change if >>>>>> you prefer. I?ll file a separate RFE. >>>>>> >>>>> I think it's better to do this in a separate RFE since >>>>> MAX_SHARED_DELTA is used elsewhere as well. >>>> I filed JDK-8154108. >>>> >>>>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>>>> *symbol) { >>>>>> 172 address base_address = >>>>>> address(MetaspaceShared::shared_rs()->base()); >>>>>> 173 uintx max_delta = >>>>>> uintx(MetaspaceShared::shared_rs()->size()); >>>>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>>>> >>>>>> - Why is the default RO space size increased? >>>>>> >>>>> That's because the symbol table is moved from RW to RO, so I had to >>>>> change the RO minimum size, or else >>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >>>> Ok. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>>> - >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>>>> >>>>>> >>>>>> - >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>>>> >>>>>> >>>>>> Copyright year. >>>>> Will fix. >>>>> >>>>> Thanks >>>>> - Ioi >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>>>> Lam> wrote: >>>>>>> >>>>>>> Please review >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug: Clean up CompactHashtable >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary of fix: >>>>>>> >>>>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>>>> tedious and >>>>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>>>> more >>>>>>> structural. >>>>>>> >>>>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>>>> so the >>>>>>> dumping and walking code is easier to understand >>>>>>> >>>>>>> (see comments above SimpleCompactHashtable declaration) >>>>>>> These 2 arrays are now allocated from the RO region (used to >>>>>>> be in RW) >>>>>>> >>>>>>> [3] Renamed a few things >>>>>>> >>>>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>>>> (having something called "compact" in CompactHashtable is >>>>>>> confusing) >>>>>>> >>>>>>> The old names "dump_table" (actually dumping the buckets) and >>>>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>>>> with >>>>>>> terminology used elsewhere. Now the terminology is unified: >>>>>>> "buckets" = the main index, "entries" = the second level. >>>>>>> >>>>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>>>> >>>>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>>>> checked with assert. >>>>>>> >>>>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>>>> >>>>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>>>> SimpleCompactHashtable::iterate) >>>>>>> >>>>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>>>> the lack of >>>>>>> a regression test, the walking of the compact hashtable in SA >>>>>>> had been >>>>>>> broken for a while before it was fixed in JDK-8151368, so >>>>>>> having a test >>>>>>> case would make the code more maintainable. >>>>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Hotspot JTREG tests >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >> From sgehwolf at redhat.com Mon Apr 18 09:16:49 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Apr 2016 11:16:49 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57113A16.2010909@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> Message-ID: <1460971009.3790.18.camel@redhat.com> Hi Dmitry, On Fri, 2016-04-15 at 21:59 +0300, Dmitry Samersoff wrote: > Severin, > > Looks good for me. Thanks for the review! > But I'm a little afraid of the fact that now we are holding > eventHandler_lock while doing invoke*. OK. FWIW, we need to hold this lock for proper lock ordering. Otherwise?com/sun/jdi/InvokeHangTest.java fails: diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c @@ -670,7 +670,6 @@ ?????????return JNI_FALSE; ?????} ? -????eventHandler_lock(); /* for proper lock order */ ?????debugMonitorEnter(invokerLock); ?????env = getEnv(); ? @@ -706,7 +705,6 @@ ? ?????} END_WITH_LOCAL_REFS(env); ?????debugMonitorExit(invokerLock); -????eventHandler_unlock(); > So please hold on with backports until the fix bakes in jdk9 for some > time. Sounds good. Sorry for the trouble last time around. Cheers, Severin > -Dmitry > > On 2016-04-15 19:53, Severin Gehwolf wrote: > > > > Hi, > > > > Here is a patch which is a redo of the fix for JDK-4858370 which > > got > > backed out due to it causing test regressions. Specifically > > problems > > were reported for com/sun/jdi/InvokeTest.java > > and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK- > > 4858370 > > applied. > > > > Those test regressions were caused because: > > a.) The fix for JDK-4858370 deleted refs from the request object > > ????while *not* holding the invoker lock. > > b.) Invokes done via invoker_doInvoke() save global references, but > > ????don't hold the invoker lock either. > > > > This new fix grabs relevant locks for both cases above. > > > > Testing done: > > ?- com/sun/jdi test set. No regressions + added regression test. > > ?- com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 > > ???invocations. Same for com/sun/jdi/InvokeTest.java. > > ?- I haven't seen any crashes in new OomDebugTest.java either. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/we > > brev.01/ > > > > Once reviewed, I'd need somebody to sponsor this patch. > > > > Thanks, > > Severin > > > From chris.hegarty at oracle.com Mon Apr 18 10:37:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Apr 2016 11:37:38 +0100 Subject: RFR [9] 8147553: Remove sun.misc.ManagedLocalsThread from java.management Message-ID: <5714B8F2.1000304@oracle.com> 8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in java.management to use the new Thread constructor. http://cr.openjdk.java.net/~chegar/8147553/ https://bugs.openjdk.java.net/browse/JDK-8147553 -Chris. From daniel.fuchs at oracle.com Mon Apr 18 13:24:31 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 18 Apr 2016 15:24:31 +0200 Subject: RFR [9] 8147553: Remove sun.misc.ManagedLocalsThread from java.management In-Reply-To: <5714B8F2.1000304@oracle.com> References: <5714B8F2.1000304@oracle.com> Message-ID: Hi Chris, The changes look good to me. best regards, -- daniel On 18/04/16 12:37, Chris Hegarty wrote: > 8056152 added a new constructor to java.lang.Thread to constructing > Threads that do not inherit inheritable-thread-local initial values. > Given there is now a supported API for creating such threads, other > areas of the JDK should be updated to use it. > > This change updates the code in java.management to use the new Thread > constructor. > > http://cr.openjdk.java.net/~chegar/8147553/ > https://bugs.openjdk.java.net/browse/JDK-8147553 > > -Chris. > From yasuenag at gmail.com Mon Apr 18 14:06:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 18 Apr 2016 23:06:33 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <570B6E57.2060707@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> Message-ID: <5714E9E9.40804@gmail.com> PING: I've sent review request for JDK-8153073. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ If this patch is merged, user can set logfile size with k/m/g. Please review it. Thanks, Yasumasa On 2016/04/11 18:28, Yasumasa Suenaga wrote: > PING: Could you review it? > We need more reviewer. > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/03/31 22:33, Yasumasa Suenaga wrote: >> CC'ed to serviceability-dev. >> >> Could you review it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>> >>> arguments.hpp is included in precompiled.hpp . So build was succeeded. >>> However, it should be included in logFileOutput.cpp . >>> >>> I uploaded a new webrev. Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This request review is related to [1]. >>>>> >>>>> I want to set filesize option with k/m/g as below: >>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>> >>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>> I think we can use option parser in arguments.cpp . >>>>> >>>>> I uploaded webrev. Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>> >>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>> >>>> Apart from that, this looks good to me. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>> >>>> From yasuenag at gmail.com Mon Apr 18 14:09:07 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 18 Apr 2016 23:09:07 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <570B6E86.6020507@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> Message-ID: <5714EA83.8050007@gmail.com> PING: I've sent review request for JDK-8153074. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ If this patch is merged, user can confirm output option via VM.log jcmd. Please review and sponsor it. Thanks, Yasumasa On 2016/04/11 18:29, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2016/03/31 22:35, Yasumasa Suenaga wrote: >> CC'ed to serviceability-dev. >> >> Could you review it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This request review is related to [1]. >>> >>> I want to see output option (filecount, filesize) in VM.log jcmd. >>> >>> Output sample: >>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>> >>> I uploaded webrev. Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>> >>> From kirk at kodewerk.com Mon Apr 18 18:09:33 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Mon, 18 Apr 2016 14:09:33 -0400 Subject: bug in JVMTI Message-ID: <807CF7AE-9B21-435F-B7A6-08F07044607E@kodewerk.com> Hi all, For almost a year (j)VisualVM (jFluid) has been running into this JVMTI bug. # Problematic frame: # V [libjvm.dylib+0x44691c] Method::checked_resolve_jmethod_id(_jmethodID*)+0x22 ?. Current thread (0x00007ffdcc08b000): JavaThread "*** Profiler Agent Communication Thread" daemon [_thread_in_vm, id=67339, stack(0x0000700002492000,0x0000700002592000)] siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000001b It is a know bug and has been known for quite some time. Since this worked in the past, someone has bunged something up here. It happens, no worries. The problem is this is critical bug as it completely stuffs up VisualVM. Is there to know if this bug has been assigned to someone and to know when it might be fixed? Kind regards, Kirk Pepperdine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.larsen at oracle.com Mon Apr 18 18:17:06 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Apr 2016 20:17:06 +0200 Subject: bug in JVMTI In-Reply-To: <807CF7AE-9B21-435F-B7A6-08F07044607E@kodewerk.com> References: <807CF7AE-9B21-435F-B7A6-08F07044607E@kodewerk.com> Message-ID: What bug is this on bugs.openjdk.java.net ? > On 18 apr. 2016, at 20:09, kirk at kodewerk.com wrote: > > Hi all, > > For almost a year (j)VisualVM (jFluid) has been running into this JVMTI bug. > > # Problematic frame: > # V [libjvm.dylib+0x44691c] Method::checked_resolve_jmethod_id(_jmethodID*)+0x22 > > ?. > Current thread (0x00007ffdcc08b000): JavaThread "*** Profiler Agent Communication Thread" daemon [_thread_in_vm, id=67339, stack(0x0000700002492000,0x0000700002592000)] > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000001b > > > It is a know bug and has been known for quite some time. Since this worked in the past, someone has bunged something up here. It happens, no worries. > > The problem is this is critical bug as it completely stuffs up VisualVM. Is there to know if this bug has been assigned to someone and to know when it might be fixed? > > Kind regards, > Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at basilcrow.com Mon Apr 18 18:33:19 2016 From: me at basilcrow.com (Basil Crow) Date: Mon, 18 Apr 2016 11:33:19 -0700 Subject: Unable to extract usable hprof heap dump from core file with Java 8 Message-ID: Hi all, I posted a message a few months ago entitled "Unable to create hprof heap dump from core file with jmap on Oracle Solaris" [1] to describe my difficulties creating a usable hprof heap dump from a core file with jmap with Java 8. Despite the fact that JDK-8044416 has been resolved, the problem still exists and has been reported by more users. While JDK-8044416 putatively fixed the issue by getting rid of the exception when invoking jmap, an hprof heap dump generated from a core file with Java 8 is still unusable in any of the major analysis tools. See Eclipse bugs 471757 [2] and 476262 [3] for details regarding Eclipse MAT in particular. I have also been unable to analyze an hprof heap dump generated this way in VisualVM. A user on Stack Overflow reports the same issue with YourKit [4]. The users mentioned above have reported this issue with core files generated on Linux, Windows, and Oracle Solaris -- and using Java 8 Update 60 or above, where this is supposed to be fixed. Clearly something is still not working as expected. Could we please get an update on when this issue will be resolved and how to track progress? Thanks, Basil [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-August/017765.html [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=471757 [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=476262 [4] https://stackoverflow.com/questions/34719148/mat-cant-open-the-dump-file From vladimir.x.ivanov at oracle.com Mon Apr 18 18:38:50 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 18 Apr 2016 21:38:50 +0300 Subject: bug in JVMTI In-Reply-To: References: <807CF7AE-9B21-435F-B7A6-08F07044607E@kodewerk.com> Message-ID: <571529BA.3060506@oracle.com> There's the following bug filed: https://bugs.openjdk.java.net/browse/JDK-8147451 Best regards, Vladimir Ivanov On 4/18/16 9:17 PM, Staffan Larsen wrote: > What bug is this on bugs.openjdk.java.net ? > >> On 18 apr. 2016, at 20:09, kirk at kodewerk.com >> wrote: >> >> Hi all, >> >> For almost a year (j)VisualVM (jFluid) has been running into this >> JVMTI bug. >> >> # Problematic frame: >> # V [libjvm.dylib+0x44691c] >> Method::checked_resolve_jmethod_id(_jmethodID*)+0x22 >> >> ?. >> Current thread (0x00007ffdcc08b000): JavaThread "*** Profiler Agent >> Communication Thread" daemon [_thread_in_vm, id=67339, >> stack(0x0000700002492000,0x0000700002592000)] >> >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: >> 0x000000000000001b >> >> >> It is a know bug and has been known for quite some time. Since this >> worked in the past, someone has bunged something up here. It happens, >> no worries. >> >> The problem is this is critical bug as it completely stuffs up >> VisualVM. Is there to know if this bug has been assigned to someone >> and to know when it might be fixed? >> >> Kind regards, >> Kirk Pepperdine > From kirk at kodewerk.com Mon Apr 18 19:11:46 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Mon, 18 Apr 2016 15:11:46 -0400 Subject: bug in JVMTI In-Reply-To: <571529BA.3060506@oracle.com> References: <807CF7AE-9B21-435F-B7A6-08F07044607E@kodewerk.com> <571529BA.3060506@oracle.com> Message-ID: Hi all, This works in 7 and 9 (not tried a recent build of 9) but breaks in every version of 8 I?ve tried. Is there a way to get the fix in 8? Kind regards, Kirk Pepperdine > On Apr 18, 2016, at 2:38 PM, Vladimir Ivanov wrote: > > There's the following bug filed: > https://bugs.openjdk.java.net/browse/JDK-8147451 > > Best regards, > Vladimir Ivanov > > On 4/18/16 9:17 PM, Staffan Larsen wrote: >> What bug is this on bugs.openjdk.java.net ? >> >>> On 18 apr. 2016, at 20:09, kirk at kodewerk.com >>> wrote: >>> >>> Hi all, >>> >>> For almost a year (j)VisualVM (jFluid) has been running into this >>> JVMTI bug. >>> >>> # Problematic frame: >>> # V [libjvm.dylib+0x44691c] >>> Method::checked_resolve_jmethod_id(_jmethodID*)+0x22 >>> >>> ?. >>> Current thread (0x00007ffdcc08b000): JavaThread "*** Profiler Agent >>> Communication Thread" daemon [_thread_in_vm, id=67339, >>> stack(0x0000700002492000,0x0000700002592000)] >>> >>> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: >>> 0x000000000000001b >>> >>> >>> It is a know bug and has been known for quite some time. Since this >>> worked in the past, someone has bunged something up here. It happens, >>> no worries. >>> >>> The problem is this is critical bug as it completely stuffs up >>> VisualVM. Is there to know if this bug has been assigned to someone >>> and to know when it might be fixed? >>> >>> Kind regards, >>> Kirk Pepperdine >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexhenrie24 at gmail.com Mon Apr 18 20:17:49 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Mon, 18 Apr 2016 14:17:49 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <570F5638.1030708@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> Message-ID: 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com : > Your fix has been pushed. Thanks! Could you send me a link to the repository that it was pushed to? I'm not seeing it in jdk9/dev/jdk. -Alex From serguei.spitsyn at oracle.com Mon Apr 18 20:23:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Apr 2016 13:23:18 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> Message-ID: <57154236.7060703@oracle.com> The fix was pushed to the jdk9/hs-rt. It will take some time (a week or two) to be promoted to the jdk9/dev. Thanks, Serguei On 4/18/16 13:17, Alex Henrie wrote: > 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com > : >> Your fix has been pushed. > Thanks! Could you send me a link to the repository that it was pushed > to? I'm not seeing it in jdk9/dev/jdk. > > -Alex From daniel.daugherty at oracle.com Mon Apr 18 20:40:06 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Apr 2016 14:40:06 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <57154236.7060703@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> Message-ID: <57154626.8020403@oracle.com> Serguei, Even though the JPRT "succeeded", the push itself failed: hg --config ui.merge=false push --repository /net/scaaa637.us.oracle.com/export/ archives/data/jprt/archive/2016/04/2016-04-13-173931.sspitsyn.8145278/sourcetree /jdk --noninteractive --time pushing to ssh://sspitsyn at hg.openjdk.java.net/jdk9/hs-rt/jdk searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] remote: remote: > Changeset: 14045:93826bcfbaf1 remote: > Author: Alex Henrie remote: > Date: 2015-11-17 23:10 remote: > remote: > 8145278: Fix memory leak in splitPathList remote: > Reviewed-by: sspitsyn, dsamersoff, dcubed remote: remote: Invalid changeset author: Alex Henrie remote: remote: transaction abort! remote: rollback completed remote: abort: pretxnchangegroup.0.jcheck hook failed time: real 5.530 secs (user 0.350+0.000 sys 0.050+0.000) -> 1 You must have jcheck disabled on the machine that you used to commit the changeset. The server side rejected the changeset because of the malformed "Author:" field. Dan On 4/18/16 2:23 PM, serguei.spitsyn at oracle.com wrote: > The fix was pushed to the jdk9/hs-rt. > It will take some time (a week or two) to be promoted to the jdk9/dev. > > Thanks, > Serguei > > > On 4/18/16 13:17, Alex Henrie wrote: >> 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com >> : >>> Your fix has been pushed. >> Thanks! Could you send me a link to the repository that it was pushed >> to? I'm not seeing it in jdk9/dev/jdk. >> >> -Alex > > From serguei.spitsyn at oracle.com Mon Apr 18 20:55:27 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Apr 2016 13:55:27 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <57154626.8020403@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> <57154626.8020403@oracle.com> Message-ID: <571549BF.4080704@oracle.com> Dan, Thank you for the notice! Will check and re-submit the job. Thanks, Serguei On 4/18/16 13:40, Daniel D. Daugherty wrote: > Serguei, > > Even though the JPRT "succeeded", the push itself failed: > > hg --config ui.merge=false push --repository > /net/scaaa637.us.oracle.com/export/ > archives/data/jprt/archive/2016/04/2016-04-13-173931.sspitsyn.8145278/sourcetree > > /jdk --noninteractive --time > pushing to ssh://sspitsyn at hg.openjdk.java.net/jdk9/hs-rt/jdk > searching for changes > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] > remote: > remote: > Changeset: 14045:93826bcfbaf1 > remote: > Author: Alex Henrie > remote: > Date: 2015-11-17 23:10 > remote: > > remote: > 8145278: Fix memory leak in splitPathList > remote: > Reviewed-by: sspitsyn, dsamersoff, dcubed > remote: > remote: Invalid changeset author: Alex Henrie > remote: > remote: transaction abort! > remote: rollback completed > remote: abort: pretxnchangegroup.0.jcheck hook failed > time: real 5.530 secs (user 0.350+0.000 sys 0.050+0.000) > -> 1 > > > You must have jcheck disabled on the machine that you used to > commit the changeset. The server side rejected the changeset > because of the malformed "Author:" field. > > Dan > > > On 4/18/16 2:23 PM, serguei.spitsyn at oracle.com wrote: >> The fix was pushed to the jdk9/hs-rt. >> It will take some time (a week or two) to be promoted to the jdk9/dev. >> >> Thanks, >> Serguei >> >> >> On 4/18/16 13:17, Alex Henrie wrote: >>> 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com >>> : >>>> Your fix has been pushed. >>> Thanks! Could you send me a link to the repository that it was pushed >>> to? I'm not seeing it in jdk9/dev/jdk. >>> >>> -Alex >> >> > From daniel.daugherty at oracle.com Mon Apr 18 20:57:41 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Apr 2016 14:57:41 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <571549BF.4080704@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> <57154626.8020403@oracle.com> <571549BF.4080704@oracle.com> Message-ID: <57154A45.4000208@oracle.com> On 4/18/16 2:55 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > Thank you for the notice! No problem. I just happened to notice that my changeset notification tracker didn't report that one going by... and we were watching stuff closed on 2016.04.13 and 2016.04.14 due to the upcoming JDK9-hs-rt merge with JDK9-hs. > Will check and re-submit the job. Please remember to rebase to JDK9-hs. JDK9-hs-rt is now closed and read-only... Dan > > Thanks, > Serguei > > > On 4/18/16 13:40, Daniel D. Daugherty wrote: >> Serguei, >> >> Even though the JPRT "succeeded", the push itself failed: >> >> hg --config ui.merge=false push --repository >> /net/scaaa637.us.oracle.com/export/ >> archives/data/jprt/archive/2016/04/2016-04-13-173931.sspitsyn.8145278/sourcetree >> >> /jdk --noninteractive --time >> pushing to ssh://sspitsyn at hg.openjdk.java.net/jdk9/hs-rt/jdk >> searching for changes >> remote: adding changesets >> remote: adding manifests >> remote: adding file changes >> remote: added 1 changesets with 1 changes to 1 files >> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >> remote: >> remote: > Changeset: 14045:93826bcfbaf1 >> remote: > Author: Alex Henrie >> remote: > Date: 2015-11-17 23:10 >> remote: > >> remote: > 8145278: Fix memory leak in splitPathList >> remote: > Reviewed-by: sspitsyn, dsamersoff, dcubed >> remote: >> remote: Invalid changeset author: Alex Henrie >> remote: >> remote: transaction abort! >> remote: rollback completed >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> time: real 5.530 secs (user 0.350+0.000 sys 0.050+0.000) >> -> 1 >> >> >> You must have jcheck disabled on the machine that you used to >> commit the changeset. The server side rejected the changeset >> because of the malformed "Author:" field. >> >> Dan >> >> >> On 4/18/16 2:23 PM, serguei.spitsyn at oracle.com wrote: >>> The fix was pushed to the jdk9/hs-rt. >>> It will take some time (a week or two) to be promoted to the jdk9/dev. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/18/16 13:17, Alex Henrie wrote: >>>> 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com >>>> : >>>>> Your fix has been pushed. >>>> Thanks! Could you send me a link to the repository that it was pushed >>>> to? I'm not seeing it in jdk9/dev/jdk. >>>> >>>> -Alex >>> >>> >> > From daniel.daugherty at oracle.com Mon Apr 18 20:59:51 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Apr 2016 14:59:51 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <57154A45.4000208@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> <57154626.8020403@oracle.com> <571549BF.4080704@oracle.com> <57154A45.4000208@oracle.com> Message-ID: <57154AC7.1010703@oracle.com> On 4/18/16 2:57 PM, Daniel D. Daugherty wrote: > On 4/18/16 2:55 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you for the notice! > > No problem. I just happened to notice that my changeset notification > tracker didn't report that one going by... and we were watching stuff > closed on 2016.04.13 and 2016.04.14 due to the upcoming JDK9-hs-rt Typo: 'closed' -> 'closely'. Typing too fast... Dan > merge with JDK9-hs. > > >> Will check and re-submit the job. > > Please remember to rebase to JDK9-hs. JDK9-hs-rt is now closed > and read-only... > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 4/18/16 13:40, Daniel D. Daugherty wrote: >>> Serguei, >>> >>> Even though the JPRT "succeeded", the push itself failed: >>> >>> hg --config ui.merge=false push --repository >>> /net/scaaa637.us.oracle.com/export/ >>> archives/data/jprt/archive/2016/04/2016-04-13-173931.sspitsyn.8145278/sourcetree >>> >>> /jdk --noninteractive --time >>> pushing to ssh://sspitsyn at hg.openjdk.java.net/jdk9/hs-rt/jdk >>> searching for changes >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 1 changesets with 1 changes to 1 files >>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>> remote: >>> remote: > Changeset: 14045:93826bcfbaf1 >>> remote: > Author: Alex Henrie >>> remote: > Date: 2015-11-17 23:10 >>> remote: > >>> remote: > 8145278: Fix memory leak in splitPathList >>> remote: > Reviewed-by: sspitsyn, dsamersoff, dcubed >>> remote: >>> remote: Invalid changeset author: Alex Henrie >>> remote: >>> remote: transaction abort! >>> remote: rollback completed >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> time: real 5.530 secs (user 0.350+0.000 sys 0.050+0.000) >>> -> 1 >>> >>> >>> You must have jcheck disabled on the machine that you used to >>> commit the changeset. The server side rejected the changeset >>> because of the malformed "Author:" field. >>> >>> Dan >>> >>> >>> On 4/18/16 2:23 PM, serguei.spitsyn at oracle.com wrote: >>>> The fix was pushed to the jdk9/hs-rt. >>>> It will take some time (a week or two) to be promoted to the jdk9/dev. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/18/16 13:17, Alex Henrie wrote: >>>>> 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com >>>>> : >>>>>> Your fix has been pushed. >>>>> Thanks! Could you send me a link to the repository that it was pushed >>>>> to? I'm not seeing it in jdk9/dev/jdk. >>>>> >>>>> -Alex >>>> >>>> >>> >> > > From serguei.spitsyn at oracle.com Mon Apr 18 21:02:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Apr 2016 14:02:08 -0700 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <57154A45.4000208@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> <57154626.8020403@oracle.com> <571549BF.4080704@oracle.com> <57154A45.4000208@oracle.com> Message-ID: <57154B50.4050900@oracle.com> On 4/18/16 13:57, Daniel D. Daugherty wrote: > On 4/18/16 2:55 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you for the notice! > > No problem. I just happened to notice that my changeset notification > tracker didn't report that one going by... and we were watching stuff > closed on 2016.04.13 and 2016.04.14 due to the upcoming JDK9-hs-rt > merge with JDK9-hs. It is nice it got caught. I could catch the absence of the integration comment in the bug report. > > >> Will check and re-submit the job. > > Please remember to rebase to JDK9-hs. JDK9-hs-rt is now closed > and read-only... Yes of course, I remember it. :) Thanks, Sertguei > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 4/18/16 13:40, Daniel D. Daugherty wrote: >>> Serguei, >>> >>> Even though the JPRT "succeeded", the push itself failed: >>> >>> hg --config ui.merge=false push --repository >>> /net/scaaa637.us.oracle.com/export/ >>> archives/data/jprt/archive/2016/04/2016-04-13-173931.sspitsyn.8145278/sourcetree >>> >>> /jdk --noninteractive --time >>> pushing to ssh://sspitsyn at hg.openjdk.java.net/jdk9/hs-rt/jdk >>> searching for changes >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 1 changesets with 1 changes to 1 files >>> remote: [jcheck d46eaf84b346 2015-12-01 13:15:54 -0800] >>> remote: >>> remote: > Changeset: 14045:93826bcfbaf1 >>> remote: > Author: Alex Henrie >>> remote: > Date: 2015-11-17 23:10 >>> remote: > >>> remote: > 8145278: Fix memory leak in splitPathList >>> remote: > Reviewed-by: sspitsyn, dsamersoff, dcubed >>> remote: >>> remote: Invalid changeset author: Alex Henrie >>> remote: >>> remote: transaction abort! >>> remote: rollback completed >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> time: real 5.530 secs (user 0.350+0.000 sys 0.050+0.000) >>> -> 1 >>> >>> >>> You must have jcheck disabled on the machine that you used to >>> commit the changeset. The server side rejected the changeset >>> because of the malformed "Author:" field. >>> >>> Dan >>> >>> >>> On 4/18/16 2:23 PM, serguei.spitsyn at oracle.com wrote: >>>> The fix was pushed to the jdk9/hs-rt. >>>> It will take some time (a week or two) to be promoted to the jdk9/dev. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/18/16 13:17, Alex Henrie wrote: >>>>> 2016-04-14 2:35 GMT-06:00 serguei.spitsyn at oracle.com >>>>> : >>>>>> Your fix has been pushed. >>>>> Thanks! Could you send me a link to the repository that it was pushed >>>>> to? I'm not seeing it in jdk9/dev/jdk. >>>>> >>>>> -Alex >>>> >>>> >>> >> > From david.holmes at oracle.com Tue Apr 19 01:14:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 11:14:49 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <5714E9E9.40804@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> Message-ID: <57158689.7020101@oracle.com> Hi Yasumasa, On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: > PING: > > I've sent review request for JDK-8153073. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > > If this patch is merged, user can set logfile size with k/m/g. Your webrev seems out of date with respect to the current code - the logfile size processing is done in LogFileOutput::parse_options not configure_rotation. And of course you now need to work with jdk9/hs not hs-rt. That aside: src/share/vm/runtime/arguments.cpp I don't think you need to add the Arguments:: to the atomull calls when you are executing in Arguments code - lines 2643, 2660 This comment could be updated to delete "memory" 788 // Parses a memory size specification string. Which makes me wonder if atomull needs renaming - does the "m" mean memory? atojulong would seem more appropriate regardless. --- src/share/vm/logging/logFileOutput.cpp You removed the size checking logic. Not directly related to your change but I was surprised that the various log file options don't seem to be documented anywhere in the -Xlog:help output. Thanks, David ----- > > Please review it. > > > Thanks, > > Yasumasa > > > On 2016/04/11 18:28, Yasumasa Suenaga wrote: >> PING: Could you review it? >> We need more reviewer. >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>> CC'ed to serviceability-dev. >>> >>> Could you review it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>> Hi Marcus, >>>> >>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>> >>>> arguments.hpp is included in precompiled.hpp . So build was succeeded. >>>> However, it should be included in logFileOutput.cpp . >>>> >>>> I uploaded a new webrev. Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This request review is related to [1]. >>>>>> >>>>>> I want to set filesize option with k/m/g as below: >>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>> >>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>> I think we can use option parser in arguments.cpp . >>>>>> >>>>>> I uploaded webrev. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>> >>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>>> >>>>> Apart from that, this looks good to me. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>> >>>>> From serguei.spitsyn at oracle.com Tue Apr 19 08:33:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 01:33:18 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57115485.6090305@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> Message-ID: <5715ED4E.3080501@oracle.com> Hi Severin, Please, find my comments below. On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: > On 4/15/16 11:59, Dmitry Samersoff wrote: >> Severin, >> >> Looks good for me. >> >> But I'm a little afraid of the fact that now we are holding >> eventHandler_lock while doing invoke*. > > It seems, I have this concern too. > Please, let me take a look closer at this part if it is done in a > right way. Ok, my question was not about the eventHandler_lock, but about the invokerLock. Please, see below. > > >> >> So please hold on with backports until the fix bakes in jdk9 for some >> time. > +1 > > Thanks, > Serguei > >> >> -Dmitry >> >> On 2016-04-15 19:53, Severin Gehwolf wrote: >>> Hi, >>> >>> Here is a patch which is a redo of the fix for JDK-4858370 which got >>> backed out due to it causing test regressions. Specifically problems >>> were reported for com/sun/jdi/InvokeTest.java >>> and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 >>> applied. >>> >>> Those test regressions were caused because: >>> a.) The fix for JDK-4858370 deleted refs from the request object >>> while *not* holding the invoker lock. >>> b.) Invokes done via invoker_doInvoke() save global references, but >>> don't hold the invoker lock either. It seems, the invokerLock is to protect any uses of the 'request' pointer that points to the field ThreadNode.currentInvoke, not to protect the saveGlobalRef() call itself. So that, we have a hole in synchronization that you nicely discovered. Here is a couple of more places where the 'request' pointer is not protected with the invokerLock: invoker_enableInvokeRequests(), invoker_isPending(), invoker_isEnabled(). I've filed a new bug: https://bugs.openjdk.java.net/browse/JDK-8154529 BTW, these are pretty simple or rare cases that do not harm much. The function invoker_isPending() is not used at all. Please, consider your fix reviewed. Thanks! Serguei >>> >>> This new fix grabs relevant locks for both cases above. >>> >>> Testing done: >>> - com/sun/jdi test set. No regressions + added regression test. >>> - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 >>> invocations. Same for com/sun/jdi/InvokeTest.java. >>> - I haven't seen any crashes in new OomDebugTest.java either. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 >>> webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ >>> >>> Once reviewed, I'd need somebody to sponsor this patch. >>> >>> Thanks, >>> Severin >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Tue Apr 19 09:07:03 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Apr 2016 11:07:03 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <570F80B1.5020602@oracle.com> References: <570F80B1.5020602@oracle.com> Message-ID: <5715F537.2040904@oracle.com> Hi, On 04/14/2016 01:36 PM, Robbin Ehn wrote: > Hi all, > > Please review: > > This moves jvmti trace output to the tag jvmti on trace level. > > The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have > a lot of functionality, e.g. can filter on func, in/out, etc, so it if > left as is. > > TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti > tag is set. > > Webrev: http://cr.openjdk.java.net/~rehn/8154041/ In jvmtiExport.cpp: Maybe we should remove the commented trace calls while at it? I'm thinking of lines 639-641 and 677-681. Maybe they could be un-commented as well, I'm not sure. Also, there is (pre-existing) trailing whitespace in a bunch of the messages which I think we can remove (line 2203 for example). Other than that, I think this looks good! Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 > > Thanks! > > /Robbin From marcus.larsson at oracle.com Tue Apr 19 09:16:01 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Apr 2016 11:16:01 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <570F8499.7070604@oracle.com> References: <570F8499.7070604@oracle.com> Message-ID: <5715F751.1060406@oracle.com> Hi, On 04/14/2016 01:52 PM, Robbin Ehn wrote: > Hi all, > > Please review: > > This moves jvmti object-tagging output to the tag-set > jvmti,objecttagging on debug level. > > The TraceJVMTIObjectTagging argument is deprecated and aliased with: > "-Xlog:jvmti+objecttagging=debug" > > Did this on top of: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html > > but only part common is the jvmti tag (logTag.hpp). > > Webrev: http://cr.openjdk.java.net/~rehn/8154059/ I think 'objecttagging' is a bit too long. Maybe we could just call it 'tagging'? I'm fine with leaving it as is as well, just wanted to suggest the alternative. Looks good in any case! Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 > > Thanks! > > /Robbin > From sgehwolf at redhat.com Tue Apr 19 09:16:48 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 19 Apr 2016 11:16:48 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5715ED4E.3080501@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> Message-ID: <1461057408.4555.6.camel@redhat.com> Hi, On Tue, 2016-04-19 at 01:33 -0700, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > Please, find my comments below. > > On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: > > On 4/15/16 11:59, Dmitry Samersoff wrote:? > > > Severin,? > > > > > > Looks good for me.? > > > > > > But I'm a little afraid of the fact that now we are holding? > > > eventHandler_lock while doing invoke*.? > > ? > > It seems, I have this concern too.? > > Please, let me take a look closer at this part if it is done in a right way.? > ? > Ok, my question was not about the eventHandler_lock, but about the invokerLock. Please, see below. > > > > > > > > > > > So please hold on with backports until the fix bakes in jdk9 for some time.? > > ?+1? > > Thanks,? > > Serguei? > > > > > > > > -Dmitry? > > > > > > On 2016-04-15 19:53, Severin Gehwolf wrote:? > > > > Hi,? > > > > > > > > Here is a patch which is a redo of the fix for JDK-4858370 which got? > > > > backed out due to it causing test regressions. Specifically problems? > > > > were reported for com/sun/jdi/InvokeTest.java? > > > > and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370? > > > > applied.? > > > > > > > > Those test regressions were caused because:? > > > > a.) The fix for JDK-4858370 deleted refs from the request object? > > > > ???? while *not* holding the invoker lock.? > ? > > > > b.) Invokes done via invoker_doInvoke() save global references, but? > > > > ???? don't hold the invoker lock either.? > ? > It seems, the invokerLock is to protect any uses of the 'request' pointer that points > to the field ThreadNode.currentInvoke, not to protect the saveGlobalRef() call itself. > So that, we have a hole in synchronization that you nicely discovered. Yes, that's right. saveGlobalRef() saves references by using the request pointer. > Here is a couple of more places where the 'request' pointer is not protected with > the invokerLock: > ??? invoker_enableInvokeRequests(), invoker_isPending(), invoker_isEnabled(). > > I've filed a new bug: > ? https://bugs.openjdk.java.net/browse/JDK-8154529 > > BTW, these are pretty simple or rare cases that do not harm much. > The function invoker_isPending() is not used at all. OK. > Please, consider your fix reviewed. Thanks! The hg exported changeset is here: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/JDK-8153711-jdk9-jdk.export.patch I'd need somebody to sponsor this for me. Cheers, Severin > Thanks! > Serguei > > > > > > > > > > This new fix grabs relevant locks for both cases above.? > > > > > > > > Testing done:? > > > > ? - com/sun/jdi test set. No regressions + added regression test.? > > > > ? - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300? > > > > ??? invocations. Same for com/sun/jdi/InvokeTest.java.? > > > > ? - I haven't seen any crashes in new OomDebugTest.java either.? > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153711? > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/? > > > > > > > > Once reviewed, I'd need somebody to sponsor this patch.? > > > > > > > > Thanks,? > > > > Severin? > > > > > > > ? > > ? > ? From serguei.spitsyn at oracle.com Tue Apr 19 09:22:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 02:22:24 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1461057408.4555.6.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> Message-ID: <5715F8D0.6030200@oracle.com> On 4/19/16 02:16, Severin Gehwolf wrote: > Hi, > > On Tue, 2016-04-19 at 01:33 -0700, serguei.spitsyn at oracle.com wrote: >> Hi Severin, >> >> Please, find my comments below. >> >> On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: >>> On 4/15/16 11:59, Dmitry Samersoff wrote: >>>> Severin, >>>> >>>> Looks good for me. >>>> >>>> But I'm a little afraid of the fact that now we are holding >>>> eventHandler_lock while doing invoke*. >>> >>> It seems, I have this concern too. >>> Please, let me take a look closer at this part if it is done in a right way. >> >> Ok, my question was not about the eventHandler_lock, but about the invokerLock. Please, see below. >> >>> >>>> So please hold on with backports until the fix bakes in jdk9 for some time. >>> +1 >>> Thanks, >>> Serguei >>> >>>> -Dmitry >>>> >>>> On 2016-04-15 19:53, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Here is a patch which is a redo of the fix for JDK-4858370 which got >>>>> backed out due to it causing test regressions. Specifically problems >>>>> were reported for com/sun/jdi/InvokeTest.java >>>>> and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 >>>>> applied. >>>>> >>>>> Those test regressions were caused because: >>>>> a.) The fix for JDK-4858370 deleted refs from the request object >>>>> while *not* holding the invoker lock. >> >>>>> b.) Invokes done via invoker_doInvoke() save global references, but >>>>> don't hold the invoker lock either. >> >> It seems, the invokerLock is to protect any uses of the 'request' pointer that points >> to the field ThreadNode.currentInvoke, not to protect the saveGlobalRef() call itself. >> So that, we have a hole in synchronization that you nicely discovered. > Yes, that's right. saveGlobalRef() saves references by using the request pointer. > >> Here is a couple of more places where the 'request' pointer is not protected with >> the invokerLock: >> invoker_enableInvokeRequests(), invoker_isPending(), invoker_isEnabled(). >> >> I've filed a new bug: >> https://bugs.openjdk.java.net/browse/JDK-8154529 >> >> BTW, these are pretty simple or rare cases that do not harm much. >> The function invoker_isPending() is not used at all. > OK. > >> Please, consider your fix reviewed. > Thanks! > > The hg exported changeset is here: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/JDK-8153711-jdk9-jdk.export.patch > > I'd need somebody to sponsor this for me. I will sponsor the fix for you. Thanks, Serguei > > Cheers, > Severin > >> Thanks! >> Serguei >> >> >>>>> This new fix grabs relevant locks for both cases above. >>>>> >>>>> Testing done: >>>>> - com/sun/jdi test set. No regressions + added regression test. >>>>> - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 >>>>> invocations. Same for com/sun/jdi/InvokeTest.java. >>>>> - I haven't seen any crashes in new OomDebugTest.java either. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 >>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ >>>>> >>>>> Once reviewed, I'd need somebody to sponsor this patch. >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>> >>> >> > From robbin.ehn at oracle.com Tue Apr 19 09:43:34 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 11:43:34 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715F537.2040904@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> Message-ID: <5715FDC6.6040209@oracle.com> Hi Marcus, On 04/19/2016 11:07 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 01:36 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review: >> >> This moves jvmti trace output to the tag jvmti on trace level. >> >> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >> left as is. >> >> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >> tag is set. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ > > In jvmtiExport.cpp: > Maybe we should remove the commented trace calls while at it? I'm > thinking of lines 639-641 and 677-681. Maybe they could be un-commented > as well, I'm not sure. I removed them. > > Also, there is (pre-existing) trailing whitespace in a bunch of the > messages which I think we can remove (line 2203 for example). I removed these also. I updated webrev: Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ > > Other than that, I think this looks good! Thanks ! /Robbin > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Tue Apr 19 09:46:26 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 11:46:26 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5715F751.1060406@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> Message-ID: <5715FE72.7080104@oracle.com> Hi Marcus, On 04/19/2016 11:16 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 01:52 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review: >> >> This moves jvmti object-tagging output to the tag-set >> jvmti,objecttagging on debug level. >> >> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >> "-Xlog:jvmti+objecttagging=debug" >> >> Did this on top of: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >> >> but only part common is the jvmti tag (logTag.hpp). >> >> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ > > I think 'objecttagging' is a bit too long. Maybe we could just call it > 'tagging'? I'm fine with leaving it as is as well, just wanted to > suggest the alternative. If the "second" reviewer concur, I'll change it. > > Looks good in any case! Thanks! /Robbin > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >> >> Thanks! >> >> /Robbin >> > From serguei.spitsyn at oracle.com Tue Apr 19 09:47:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 02:47:25 -0700 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715FDC6.6040209@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <5715FDC6.6040209@oracle.com> Message-ID: <5715FEAD.80802@oracle.com> Hi Robbin, The fix looks good. Also, I'm Ok with the removal of comments. Thanks, Serguei On 4/19/16 02:43, Robbin Ehn wrote: > Hi Marcus, > > On 04/19/2016 11:07 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review: >>> >>> This moves jvmti trace output to the tag jvmti on trace level. >>> >>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >>> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >>> left as is. >>> >>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >>> tag is set. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >> >> In jvmtiExport.cpp: >> Maybe we should remove the commented trace calls while at it? I'm >> thinking of lines 639-641 and 677-681. Maybe they could be un-commented >> as well, I'm not sure. > > I removed them. > >> >> Also, there is (pre-existing) trailing whitespace in a bunch of the >> messages which I think we can remove (line 2203 for example). > > I removed these also. > > I updated webrev: > Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ > Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ > >> >> Other than that, I think this looks good! > > Thanks ! > > /Robbin > >> >> Thanks, >> Marcus >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>> >>> Thanks! >>> >>> /Robbin >> From robbin.ehn at oracle.com Tue Apr 19 10:00:03 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 12:00:03 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715FEAD.80802@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <5715FDC6.6040209@oracle.com> <5715FEAD.80802@oracle.com> Message-ID: <571601A3.7040502@oracle.com> Hi Serguei, Thanks! /Robbin On 04/19/2016 11:47 AM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > The fix looks good. > Also, I'm Ok with the removal of comments. > > Thanks, > Serguei > > > On 4/19/16 02:43, Robbin Ehn wrote: >> Hi Marcus, >> >> On 04/19/2016 11:07 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review: >>>> >>>> This moves jvmti trace output to the tag jvmti on trace level. >>>> >>>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >>>> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >>>> left as is. >>>> >>>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >>>> tag is set. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >>> >>> In jvmtiExport.cpp: >>> Maybe we should remove the commented trace calls while at it? I'm >>> thinking of lines 639-641 and 677-681. Maybe they could be un-commented >>> as well, I'm not sure. >> >> I removed them. >> >>> >>> Also, there is (pre-existing) trailing whitespace in a bunch of the >>> messages which I think we can remove (line 2203 for example). >> >> I removed these also. >> >> I updated webrev: >> Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ >> Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ >> >>> >>> Other than that, I think this looks good! >> >> Thanks ! >> >> /Robbin >> >>> >>> Thanks, >>> Marcus >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>>> >>>> Thanks! >>>> >>>> /Robbin >>> > From serguei.spitsyn at oracle.com Tue Apr 19 10:05:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 03:05:58 -0700 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5715FE72.7080104@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> Message-ID: <57160306.3050107@oracle.com> Hi Robbin, The fix loos good. I'd like to have the tag-set name shorter but prefer "objecttagging" over "tagging". Also, I'm thinking if the tag-set name should include the "jvmti" prefix. But, please, use your judgement as it has to be consistent with the overall design. Thanks, Serguei On 4/19/16 02:46, Robbin Ehn wrote: > Hi Marcus, > > On 04/19/2016 11:16 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review: >>> >>> This moves jvmti object-tagging output to the tag-set >>> jvmti,objecttagging on debug level. >>> >>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>> "-Xlog:jvmti+objecttagging=debug" >>> >>> Did this on top of: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>> >>> >>> but only part common is the jvmti tag (logTag.hpp). >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >> >> I think 'objecttagging' is a bit too long. Maybe we could just call it >> 'tagging'? I'm fine with leaving it as is as well, just wanted to >> suggest the alternative. > > If the "second" reviewer concur, I'll change it. > >> >> Looks good in any case! > > Thanks! > > /Robbin > >> >> Thanks, >> Marcus >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>> >>> Thanks! >>> >>> /Robbin >>> >> From robbin.ehn at oracle.com Tue Apr 19 11:16:45 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 13:16:45 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <57160306.3050107@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> Message-ID: <5716139D.2040408@oracle.com> Hi Serguei, Thanks! /Robbin On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > The fix loos good. > I'd like to have the tag-set name shorter but prefer "objecttagging" > over "tagging". > Also, I'm thinking if the tag-set name should include the "jvmti" prefix. > But, please, use your judgement as it has to be consistent with the > overall design. > > Thanks, > Serguei > > > On 4/19/16 02:46, Robbin Ehn wrote: >> Hi Marcus, >> >> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review: >>>> >>>> This moves jvmti object-tagging output to the tag-set >>>> jvmti,objecttagging on debug level. >>>> >>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>> "-Xlog:jvmti+objecttagging=debug" >>>> >>>> Did this on top of: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>> >>>> >>>> but only part common is the jvmti tag (logTag.hpp). >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>> >>> I think 'objecttagging' is a bit too long. Maybe we could just call it >>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>> suggest the alternative. >> >> If the "second" reviewer concur, I'll change it. >> >>> >>> Looks good in any case! >> >> Thanks! >> >> /Robbin >> >>> >>> Thanks, >>> Marcus >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>> > From dmitry.samersoff at oracle.com Tue Apr 19 13:06:48 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 19 Apr 2016 16:06:48 +0300 Subject: RFR(S): JDK-8153278 sun/tools/jps/TestJpsJar.java fails in hs nightly Message-ID: <57162D68.4060606@oracle.com> Everybody, Please review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8153278/webrev.01/ The test (a) get it's own name then (b) launch JPS and check that it's name is present in the output. If for some reason the directory from where the test is run changes it name between (a) and (b) test fails. So test changed to get it's name right before the check of jps output. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Tue Apr 19 13:50:03 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Apr 2016 22:50:03 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <57158689.7020101@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> Message-ID: <5716378B.7030302@gmail.com> Hi David, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ > Which makes me wonder if atomull needs renaming - does the "m" mean > memory? atojulong would seem more appropriate regardless. I renamed to atojulong() in new webrev. > Not directly related to your change but I was surprised that the > various log file options don't seem to be documented anywhere in the > -Xlog:help output. I updated help message in new webrev. Thanks, Yasumasa On 2016/04/19 10:14, David Holmes wrote: > Hi Yasumasa, > > On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >> PING: >> >> I've sent review request for JDK-8153073. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >> If this patch is merged, user can set logfile size with k/m/g. > > Your webrev seems out of date with respect to the current code - the > logfile size processing is done in LogFileOutput::parse_options not > configure_rotation. And of course you now need to work with jdk9/hs not > hs-rt. > > That aside: > > src/share/vm/runtime/arguments.cpp > > I don't think you need to add the Arguments:: to the atomull calls when > you are executing in Arguments code - lines 2643, 2660 > > This comment could be updated to delete "memory" > > 788 // Parses a memory size specification string. > > Which makes me wonder if atomull needs renaming - does the "m" mean > memory? atojulong would seem more appropriate regardless. > > --- > > src/share/vm/logging/logFileOutput.cpp > > You removed the size checking logic. > > Not directly related to your change but I was surprised that the > various log file options don't seem to be documented anywhere in the > -Xlog:help output. > > Thanks, > David > ----- > >> >> Please review it. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> We need more reviewer. >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>> CC'ed to serviceability-dev. >>>> >>>> Could you review it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>> Hi Marcus, >>>>> >>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>>> >>>>> arguments.hpp is included in precompiled.hpp . So build was succeeded. >>>>> However, it should be included in logFileOutput.cpp . >>>>> >>>>> I uploaded a new webrev. Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This request review is related to [1]. >>>>>>> >>>>>>> I want to set filesize option with k/m/g as below: >>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>> >>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>>> I think we can use option parser in arguments.cpp . >>>>>>> >>>>>>> I uploaded webrev. Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>> >>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>>>> >>>>>> Apart from that, this looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>> >>>>>> From yasuenag at gmail.com Tue Apr 19 13:55:29 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Apr 2016 22:55:29 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <5714EA83.8050007@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> Message-ID: <571638D1.3040702@gmail.com> I adapted changes to jdk9/hs/hotspot repos. http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ Please review. Yasumasa On 2016/04/18 23:09, Yasumasa Suenaga wrote: > PING: > > I've sent review request for JDK-8153074. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ > > If this patch is merged, user can confirm output option via VM.log jcmd. > > > Please review and sponsor it. > > > Thanks, > > Yasumasa > > > On 2016/04/11 18:29, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>> CC'ed to serviceability-dev. >>> >>> Could you review it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This request review is related to [1]. >>>> >>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>> >>>> Output sample: >>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>> >>>> I uploaded webrev. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>> >>>> From dmitry.samersoff at oracle.com Tue Apr 19 13:56:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 19 Apr 2016 16:56:19 +0300 Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS In-Reply-To: <570E72B2.404@oracle.com> References: <570E72B2.404@oracle.com> Message-ID: <57163903.5070201@oracle.com> Any reviewers? On 2016-04-13 19:24, Dmitry Samersoff wrote: > Everybody. > > Please review a small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ > > I don't have a reproducer, so the fix is based on coredump analyzes. > > Tested with rbt > > -Dmitry > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Tue Apr 19 16:06:48 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Apr 2016 09:06:48 -0700 (PDT) Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5716139D.2040408@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> Message-ID: <57165798.2020103@oracle.com> Please, no shorter than 'objtag'. Object needs to be in there somewhere... 'tagging' is just too general. Dan On 4/19/16 5:16 AM, Robbin Ehn wrote: > Hi Serguei, > > Thanks! > > /Robbin > > On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >> Hi Robbin, >> >> The fix loos good. >> I'd like to have the tag-set name shorter but prefer "objecttagging" >> over "tagging". >> Also, I'm thinking if the tag-set name should include the "jvmti" >> prefix. >> But, please, use your judgement as it has to be consistent with the >> overall design. >> >> Thanks, >> Serguei >> >> >> On 4/19/16 02:46, Robbin Ehn wrote: >>> Hi Marcus, >>> >>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>> Hi all, >>>>> >>>>> Please review: >>>>> >>>>> This moves jvmti object-tagging output to the tag-set >>>>> jvmti,objecttagging on debug level. >>>>> >>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>>> "-Xlog:jvmti+objecttagging=debug" >>>>> >>>>> Did this on top of: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>> >>>>> >>>>> >>>>> but only part common is the jvmti tag (logTag.hpp). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>> >>>> I think 'objecttagging' is a bit too long. Maybe we could just call it >>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>> suggest the alternative. >>> >>> If the "second" reviewer concur, I'll change it. >>> >>>> >>>> Looks good in any case! >>> >>> Thanks! >>> >>> /Robbin >>> >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >>>>> >>>> >> From serguei.spitsyn at oracle.com Tue Apr 19 16:49:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 09:49:58 -0700 Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS In-Reply-To: <57165FF8.6070207@oracle.com> References: <570E72B2.404@oracle.com> <57163903.5070201@oracle.com> <57165FF8.6070207@oracle.com> Message-ID: <571661B6.30108@oracle.com> On 4/19/16 09:42, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > 144 // Clazz become invalid since the time we get the class list > 145 // Skip this entry > 146 if (error == JVMTI_ERROR_INVALID_CLASS) { > 147 continue; > 148 } > 149 > I'd like to better understand the root cause of this issue. > Could you, please, give an idea why a class in this test becomes invalid? > Do you think there is a potential in this test for a class to get > unloaded? > Or is it something about anonymous classes? One more question: Any ideas on why these two tests started failing in November 2015 and did not fail before? Thanks, Serguei > > Thanks, > Serguei > > > On 4/19/16 06:56, Dmitry Samersoff wrote: >> Any reviewers? >> >> On 2016-04-13 19:24, Dmitry Samersoff wrote: >>> Everybody. >>> >>> Please review a small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ >>> >>> I don't have a reproducer, so the fix is based on coredump analyzes. >>> >>> Tested with rbt >>> >>> -Dmitry >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 19 16:42:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 09:42:32 -0700 (PDT) Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS In-Reply-To: <57163903.5070201@oracle.com> References: <570E72B2.404@oracle.com> <57163903.5070201@oracle.com> Message-ID: <57165FF8.6070207@oracle.com> Hi Dmitry, 144 // Clazz become invalid since the time we get the class list 145 // Skip this entry 146 if (error == JVMTI_ERROR_INVALID_CLASS) { 147 continue; 148 } 149 I'd like to better understand the root cause of this issue. Could you, please, give an idea why a class in this test becomes invalid? Do you think there is a potential in this test for a class to get unloaded? Or is it something about anonymous classes? Thanks, Serguei On 4/19/16 06:56, Dmitry Samersoff wrote: > Any reviewers? > > On 2016-04-13 19:24, Dmitry Samersoff wrote: >> Everybody. >> >> Please review a small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ >> >> I don't have a reproducer, so the fix is based on coredump analyzes. >> >> Tested with rbt >> >> -Dmitry >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Tue Apr 19 19:23:08 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 21:23:08 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <57165798.2020103@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> <57165798.2020103@oracle.com> Message-ID: <5716859C.3010204@oracle.com> Hi Dan, This was pushed with: -Xlog:jvmti+objecttagging=debug /Robbin On 04/19/2016 06:06 PM, Daniel D. Daugherty wrote: > Please, no shorter than 'objtag'. Object needs to be in there > somewhere... 'tagging' is just too general. > > Dan > > > On 4/19/16 5:16 AM, Robbin Ehn wrote: >> Hi Serguei, >> >> Thanks! >> >> /Robbin >> >> On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Robbin, >>> >>> The fix loos good. >>> I'd like to have the tag-set name shorter but prefer "objecttagging" >>> over "tagging". >>> Also, I'm thinking if the tag-set name should include the "jvmti" >>> prefix. >>> But, please, use your judgement as it has to be consistent with the >>> overall design. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/19/16 02:46, Robbin Ehn wrote: >>>> Hi Marcus, >>>> >>>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review: >>>>>> >>>>>> This moves jvmti object-tagging output to the tag-set >>>>>> jvmti,objecttagging on debug level. >>>>>> >>>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>>>> "-Xlog:jvmti+objecttagging=debug" >>>>>> >>>>>> Did this on top of: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>>> >>>>>> >>>>>> >>>>>> but only part common is the jvmti tag (logTag.hpp). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>>> >>>>> I think 'objecttagging' is a bit too long. Maybe we could just >>>>> call it >>>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>>> suggest the alternative. >>>> >>>> If the "second" reviewer concur, I'll change it. >>>> >>>>> >>>>> Looks good in any case! >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Robbin >>>>>> >>>>> >>> > From daniel.daugherty at oracle.com Tue Apr 19 19:25:26 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Apr 2016 13:25:26 -0600 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5716859C.3010204@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> <57165798.2020103@oracle.com> <5716859C.3010204@oracle.com> Message-ID: <57168626.1040303@oracle.com> Yup. I saw that after I was caught up with my hg/Mercurial notifications mailbox... My general (unfiltered) Inbox gets priority since that's where code review happen... :-) Dan On 4/19/16 1:23 PM, Robbin Ehn wrote: > Hi Dan, > > This was pushed with: > > -Xlog:jvmti+objecttagging=debug > > /Robbin > > On 04/19/2016 06:06 PM, Daniel D. Daugherty wrote: >> Please, no shorter than 'objtag'. Object needs to be in there >> somewhere... 'tagging' is just too general. >> >> Dan >> >> >> On 4/19/16 5:16 AM, Robbin Ehn wrote: >>> Hi Serguei, >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Robbin, >>>> >>>> The fix loos good. >>>> I'd like to have the tag-set name shorter but prefer "objecttagging" >>>> over "tagging". >>>> Also, I'm thinking if the tag-set name should include the "jvmti" >>>> prefix. >>>> But, please, use your judgement as it has to be consistent with the >>>> overall design. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/19/16 02:46, Robbin Ehn wrote: >>>>> Hi Marcus, >>>>> >>>>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> This moves jvmti object-tagging output to the tag-set >>>>>>> jvmti,objecttagging on debug level. >>>>>>> >>>>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased >>>>>>> with: >>>>>>> "-Xlog:jvmti+objecttagging=debug" >>>>>>> >>>>>>> Did this on top of: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> but only part common is the jvmti tag (logTag.hpp). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>>>> >>>>>> I think 'objecttagging' is a bit too long. Maybe we could just >>>>>> call it >>>>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>>>> suggest the alternative. >>>>> >>>>> If the "second" reviewer concur, I'll change it. >>>>> >>>>>> >>>>>> Looks good in any case! >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >>>>> >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>> >>>> >> > From serguei.spitsyn at oracle.com Wed Apr 20 02:06:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 19:06:47 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5715F8D0.6030200@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> Message-ID: <5716E437.9030405@oracle.com> On 4/19/16 02:22, serguei.spitsyn at oracle.com wrote: > On 4/19/16 02:16, Severin Gehwolf wrote: >> Hi, >> >> On Tue, 2016-04-19 at 01:33 -0700, serguei.spitsyn at oracle.com wrote: >>> Hi Severin, >>> >>> Please, find my comments below. >>> >>> On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: >>>> On 4/15/16 11:59, Dmitry Samersoff wrote: >>>>> Severin, >>>>> >>>>> Looks good for me. >>>>> >>>>> But I'm a little afraid of the fact that now we are holding >>>>> eventHandler_lock while doing invoke*. >>>> It seems, I have this concern too. >>>> Please, let me take a look closer at this part if it is done in a >>>> right way. >>> Ok, my question was not about the eventHandler_lock, but about the >>> invokerLock. Please, see below. >>> >>>> >>>>> So please hold on with backports until the fix bakes in jdk9 for >>>>> some time. >>>> +1 >>>> Thanks, >>>> Serguei >>>> >>>>> -Dmitry >>>>> >>>>> On 2016-04-15 19:53, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Here is a patch which is a redo of the fix for JDK-4858370 which got >>>>>> backed out due to it causing test regressions. Specifically problems >>>>>> were reported for com/sun/jdi/InvokeTest.java >>>>>> and com/sun/jdi/InterfaceMethodsTest.java with the fix for >>>>>> JDK-4858370 >>>>>> applied. >>>>>> >>>>>> Those test regressions were caused because: >>>>>> a.) The fix for JDK-4858370 deleted refs from the request object >>>>>> while *not* holding the invoker lock. >>>>>> b.) Invokes done via invoker_doInvoke() save global references, but >>>>>> don't hold the invoker lock either. >>> It seems, the invokerLock is to protect any uses of the 'request' >>> pointer that points >>> to the field ThreadNode.currentInvoke, not to protect the >>> saveGlobalRef() call itself. >>> So that, we have a hole in synchronization that you nicely discovered. >> Yes, that's right. saveGlobalRef() saves references by using the >> request pointer. >> >>> Here is a couple of more places where the 'request' pointer is not >>> protected with >>> the invokerLock: >>> invoker_enableInvokeRequests(), invoker_isPending(), >>> invoker_isEnabled(). >>> >>> I've filed a new bug: >>> https://bugs.openjdk.java.net/browse/JDK-8154529 >>> >>> BTW, these are pretty simple or rare cases that do not harm much. >>> The function invoker_isPending() is not used at all. >> OK. >> >>> Please, consider your fix reviewed. >> Thanks! >> >> The hg exported changeset is here: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/JDK-8153711-jdk9-jdk.export.patch >> >> >> I'd need somebody to sponsor this for me. > > I will sponsor the fix for you. Hi Severin, I postpone a push for this fix. There are two nsk.jdi test failures (they look like deadlocks): nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) and one jtreg sun/com/jdi failure (it looks like a deadlock too): com/sun/jdi/InvokeHangTes.java I'll double check if these failures are regressions caused by your fix or not. Thanks, Serguei > > Thanks, > Serguei > >> >> Cheers, >> Severin >> >>> Thanks! >>> Serguei >>> >>> >>>>>> This new fix grabs relevant locks for both cases above. >>>>>> >>>>>> Testing done: >>>>>> - com/sun/jdi test set. No regressions + added regression test. >>>>>> - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 >>>>>> invocations. Same for com/sun/jdi/InvokeTest.java. >>>>>> - I haven't seen any crashes in new OomDebugTest.java either. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ >>>>>> >>>>>> Once reviewed, I'd need somebody to sponsor this patch. >>>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >> > From david.holmes at oracle.com Wed Apr 20 02:21:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 19:21:08 -0700 (PDT) Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <5716378B.7030302@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> Message-ID: <5716E794.9060905@oracle.com> Hi Yasumasa, On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > > I uploaded new webrev. Could you review again? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ You still removed the size bounds checks: 190 size_t value = parse_value(value_str); 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { 192 errstream->print_cr("Invalid option: %s must be in range [0, " 193 SIZE_FORMAT "]", FileSizeOptionKey, SIZE_MAX / K); 194 success = false; >> Which makes me wonder if atomull needs renaming - does the "m" mean >> memory? atojulong would seem more appropriate regardless. > > I renamed to atojulong() in new webrev. > >> Not directly related to your change but I was surprised that the >> various log file options don't seem to be documented anywhere in the >> -Xlog:help output. > > I updated help message in new webrev. Thanks, I had missed that example usage buried in there, but am still surprised none of these "options" for the handling the file are explicitly documented. Thanks, David > > Thanks, > > Yasumasa > > > On 2016/04/19 10:14, David Holmes wrote: >> Hi Yasumasa, >> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>> PING: >>> >>> I've sent review request for JDK-8153073. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>> If this patch is merged, user can set logfile size with k/m/g. >> >> Your webrev seems out of date with respect to the current code - the >> logfile size processing is done in LogFileOutput::parse_options not >> configure_rotation. And of course you now need to work with jdk9/hs not >> hs-rt. >> >> That aside: >> >> src/share/vm/runtime/arguments.cpp >> >> I don't think you need to add the Arguments:: to the atomull calls when >> you are executing in Arguments code - lines 2643, 2660 >> >> This comment could be updated to delete "memory" >> >> 788 // Parses a memory size specification string. >> >> Which makes me wonder if atomull needs renaming - does the "m" mean >> memory? atojulong would seem more appropriate regardless. >> >> --- >> >> src/share/vm/logging/logFileOutput.cpp >> >> You removed the size checking logic. >> >> Not directly related to your change but I was surprised that the >> various log file options don't seem to be documented anywhere in the >> -Xlog:help output. >> >> Thanks, >> David >> ----- >> >>> >>> Please review it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> We need more reviewer. >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>> CC'ed to serviceability-dev. >>>>> >>>>> Could you review it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>> Hi Marcus, >>>>>> >>>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So build was succeeded. >>>>>> However, it should be included in logFileOutput.cpp . >>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>> >>>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. >>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>> >>>>>>> From serguei.spitsyn at oracle.com Wed Apr 20 02:32:45 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 19:32:45 -0700 (PDT) Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5716E437.9030405@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> Message-ID: <5716EA4D.2030401@oracle.com> On 4/19/16 19:06, serguei.spitsyn at oracle.com wrote: > On 4/19/16 02:22, serguei.spitsyn at oracle.com wrote: >> On 4/19/16 02:16, Severin Gehwolf wrote: >>> Hi, >>> >>> On Tue, 2016-04-19 at 01:33 -0700, serguei.spitsyn at oracle.com wrote: >>>> Hi Severin, >>>> >>>> Please, find my comments below. >>>> >>>> On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: >>>>> On 4/15/16 11:59, Dmitry Samersoff wrote: >>>>>> Severin, >>>>>> >>>>>> Looks good for me. >>>>>> >>>>>> But I'm a little afraid of the fact that now we are holding >>>>>> eventHandler_lock while doing invoke*. >>>>> It seems, I have this concern too. >>>>> Please, let me take a look closer at this part if it is done in a >>>>> right way. >>>> Ok, my question was not about the eventHandler_lock, but about >>>> the invokerLock. Please, see below. >>>> >>>>> >>>>>> So please hold on with backports until the fix bakes in jdk9 for >>>>>> some time. >>>>> +1 >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2016-04-15 19:53, Severin Gehwolf wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Here is a patch which is a redo of the fix for JDK-4858370 which >>>>>>> got >>>>>>> backed out due to it causing test regressions. Specifically >>>>>>> problems >>>>>>> were reported for com/sun/jdi/InvokeTest.java >>>>>>> and com/sun/jdi/InterfaceMethodsTest.java with the fix for >>>>>>> JDK-4858370 >>>>>>> applied. >>>>>>> >>>>>>> Those test regressions were caused because: >>>>>>> a.) The fix for JDK-4858370 deleted refs from the request object >>>>>>> while *not* holding the invoker lock. >>>>>>> b.) Invokes done via invoker_doInvoke() save global references, but >>>>>>> don't hold the invoker lock either. >>>> It seems, the invokerLock is to protect any uses of the 'request' >>>> pointer that points >>>> to the field ThreadNode.currentInvoke, not to protect the >>>> saveGlobalRef() call itself. >>>> So that, we have a hole in synchronization that you nicely discovered. >>> Yes, that's right. saveGlobalRef() saves references by using the >>> request pointer. >>> >>>> Here is a couple of more places where the 'request' pointer is not >>>> protected with >>>> the invokerLock: >>>> invoker_enableInvokeRequests(), invoker_isPending(), >>>> invoker_isEnabled(). >>>> >>>> I've filed a new bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8154529 >>>> >>>> BTW, these are pretty simple or rare cases that do not harm much. >>>> The function invoker_isPending() is not used at all. >>> OK. >>> >>>> Please, consider your fix reviewed. >>> Thanks! >>> >>> The hg exported changeset is here: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/JDK-8153711-jdk9-jdk.export.patch >>> >>> >>> I'd need somebody to sponsor this for me. >> >> I will sponsor the fix for you. > > Hi Severin, > > I postpone a push for this fix. > > There are two nsk.jdi test failures (they look like deadlocks): > nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) > nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) > > and one jtreg sun/com/jdi failure (it looks like a deadlock too): > com/sun/jdi/InvokeHangTes.java > > > I'll double check if these failures are regressions caused by your fix > or not. I confirm, the failures above are new regressions introduced by the fix. The tests fail consistently with the fix and do not fail without the fix. Thanks, Serguei > > > Thanks, > Serguei > > > >> >> Thanks, >> Serguei >> >>> >>> Cheers, >>> Severin >>> >>>> Thanks! >>>> Serguei >>>> >>>> >>>>>>> This new fix grabs relevant locks for both cases above. >>>>>>> >>>>>>> Testing done: >>>>>>> - com/sun/jdi test set. No regressions + added regression test. >>>>>>> - com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 >>>>>>> invocations. Same for com/sun/jdi/InvokeTest.java. >>>>>>> - I haven't seen any crashes in new OomDebugTest.java either. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ >>>>>>> >>>>>>> Once reviewed, I'd need somebody to sponsor this patch. >>>>>>> >>>>>>> Thanks, >>>>>>> Severin >>>>>>> >>> >> > From david.holmes at oracle.com Wed Apr 20 02:37:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 19:37:23 -0700 (PDT) Subject: RFR(S): JDK-8153278 sun/tools/jps/TestJpsJar.java fails in hs nightly In-Reply-To: <57162D68.4060606@oracle.com> References: <57162D68.4060606@oracle.com> Message-ID: <5716EB63.1070201@oracle.com> Hi Dmitry, On 19/04/2016 11:06 PM, Dmitry Samersoff wrote: > Everybody, > > Please review the changes. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8153278/webrev.01/ > > The test (a) get it's own name then (b) launch JPS and check that it's > name is present in the output. > > If for some reason the directory from where the test is run changes it > name between (a) and (b) test fails. > > So test changed to get it's name right before the check of jps output. Changes seem fine, but I am curious how the directory can be changed between (a) and (b) ?? Thanks, David > -Dmitry > From yasuenag at gmail.com Wed Apr 20 05:25:39 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 20 Apr 2016 14:25:39 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <5716E794.9060905@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> Message-ID: Hi David, > You still removed the size bounds checks: > > 190 size_t value = parse_value(value_str); > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { > 192 errstream->print_cr("Invalid option: %s must be in range [0, " > 193 SIZE_FORMAT "]", FileSizeOptionKey, SIZE_MAX / K); > 194 success = false; SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. Arguments::atojulong(atomull) checks value range [2]. Thus I do not think we do not need to check value range in LogFileOutput::parse_options(). > Thanks, I had missed that example usage buried in there, but am still > surprised none of these "options" for the handling the file are > explicitly documented. I do not know how we can documented about it. (Is it internal process in Oracle?) I can help for it if I can Thanks, Yasumasa [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 [2] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 2016/04/20 11:24 "David Holmes" : > Hi Yasumasa, > > On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: > > Hi David, > > > > Thank you for your comment. > > > > I uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ > > You still removed the size bounds checks: > > 190 size_t value = parse_value(value_str); > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { > 192 errstream->print_cr("Invalid option: %s must be in range [0, " > 193 SIZE_FORMAT "]", FileSizeOptionKey, > SIZE_MAX / K); > 194 success = false; > > >> Which makes me wonder if atomull needs renaming - does the "m" mean > >> memory? atojulong would seem more appropriate regardless. > > > > I renamed to atojulong() in new webrev. > > > >> Not directly related to your change but I was surprised that the > >> various log file options don't seem to be documented anywhere in the > >> -Xlog:help output. > > > > I updated help message in new webrev. > > Thanks, I had missed that example usage buried in there, but am still > surprised none of these "options" for the handling the file are > explicitly documented. > > Thanks, > David > > > > > Thanks, > > > > Yasumasa > > > > > > On 2016/04/19 10:14, David Holmes wrote: > >> Hi Yasumasa, > >> > >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: > >>> PING: > >>> > >>> I've sent review request for JDK-8153073. > >>> Could you review it? > >>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>> > >>> If this patch is merged, user can set logfile size with k/m/g. > >> > >> Your webrev seems out of date with respect to the current code - the > >> logfile size processing is done in LogFileOutput::parse_options not > >> configure_rotation. And of course you now need to work with jdk9/hs not > >> hs-rt. > >> > >> That aside: > >> > >> src/share/vm/runtime/arguments.cpp > >> > >> I don't think you need to add the Arguments:: to the atomull calls when > >> you are executing in Arguments code - lines 2643, 2660 > >> > >> This comment could be updated to delete "memory" > >> > >> 788 // Parses a memory size specification string. > >> > >> Which makes me wonder if atomull needs renaming - does the "m" mean > >> memory? atojulong would seem more appropriate regardless. > >> > >> --- > >> > >> src/share/vm/logging/logFileOutput.cpp > >> > >> You removed the size checking logic. > >> > >> Not directly related to your change but I was surprised that the > >> various log file options don't seem to be documented anywhere in the > >> -Xlog:help output. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> Please review it. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: > >>>> PING: Could you review it? > >>>> We need more reviewer. > >>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: > >>>>> CC'ed to serviceability-dev. > >>>>> > >>>>> Could you review it? > >>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: > >>>>>> Hi Marcus, > >>>>>> > >>>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. > >>>>>> > >>>>>> arguments.hpp is included in precompiled.hpp . So build was > succeeded. > >>>>>> However, it should be included in logFileOutput.cpp . > >>>>>> > >>>>>> I uploaded a new webrev. Could you review again? > >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> This request review is related to [1]. > >>>>>>>> > >>>>>>>> I want to set filesize option with k/m/g as below: > >>>>>>>> > -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m > >>>>>>>> > >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . > >>>>>>>> I think we can use option parser in arguments.cpp . > >>>>>>>> > >>>>>>>> I uploaded webrev. Could you review it? > >>>>>>>> > >>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ > >>>>>>> > >>>>>>> You're missing an include of arguments.hpp in logFileOutput.cpp. > >>>>>>> > >>>>>>> Apart from that, this looks good to me. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Marcus > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I cannot access JPRT. So I need a sponsor. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> [1] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html > >>>>>>>> > >>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Apr 20 06:04:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2016 16:04:10 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> Message-ID: <57171BDA.9010703@oracle.com> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: > Hi David, > > > You still removed the size bounds checks: > > > > 190 size_t value = parse_value(value_str); > > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { > > 192 errstream->print_cr("Invalid option: %s must be in range > [0, " > > 193 SIZE_FORMAT "]", FileSizeOptionKey, > SIZE_MAX / K); > > 194 success = false; > > SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. Ah I hadn't realized this was an external value, I thought it was some internally enforced maximum file size limit. So this is just an overflow check really, and ... > Arguments::atojulong(atomull) checks value range [2]. ... we already do an overflow check in here, but ... > Thus I do not think we do not need to check value range in > LogFileOutput::parse_options(). ... on 32-bit size_t and julong are not the same size so we would still need to ensure we don't specify a filesize that is greater than SIZE_MAX on 32-bit. > > > Thanks, I had missed that example usage buried in there, but am still > > surprised none of these "options" for the handling the file are > > explicitly documented. > > I do not know how we can documented about it. > (Is it internal process in Oracle?) No I just meant that amongst all that help text you already modified, there is nothing, that I could see, that actually describes the possible options for filesize. Thanks, David > I can help for it if I can > > Thanks, > > Yasumasa > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 > [2] > http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 > > 2016/04/20 11:24 "David Holmes" >: > > Hi Yasumasa, > > On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: > > Hi David, > > > > Thank you for your comment. > > > > I uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ > > You still removed the size bounds checks: > > 190 size_t value = parse_value(value_str); > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { > 192 errstream->print_cr("Invalid option: %s must be in > range [0, " > 193 SIZE_FORMAT "]", FileSizeOptionKey, > SIZE_MAX / K); > 194 success = false; > > >> Which makes me wonder if atomull needs renaming - does the "m" mean > >> memory? atojulong would seem more appropriate regardless. > > > > I renamed to atojulong() in new webrev. > > > >> Not directly related to your change but I was surprised that the > >> various log file options don't seem to be documented anywhere in the > >> -Xlog:help output. > > > > I updated help message in new webrev. > > Thanks, I had missed that example usage buried in there, but am still > surprised none of these "options" for the handling the file are > explicitly documented. > > Thanks, > David > > > > > Thanks, > > > > Yasumasa > > > > > > On 2016/04/19 10:14, David Holmes wrote: > >> Hi Yasumasa, > >> > >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: > >>> PING: > >>> > >>> I've sent review request for JDK-8153073. > >>> Could you review it? > >>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>> > >>> If this patch is merged, user can set logfile size with k/m/g. > >> > >> Your webrev seems out of date with respect to the current code - the > >> logfile size processing is done in LogFileOutput::parse_options not > >> configure_rotation. And of course you now need to work with > jdk9/hs not > >> hs-rt. > >> > >> That aside: > >> > >> src/share/vm/runtime/arguments.cpp > >> > >> I don't think you need to add the Arguments:: to the atomull > calls when > >> you are executing in Arguments code - lines 2643, 2660 > >> > >> This comment could be updated to delete "memory" > >> > >> 788 // Parses a memory size specification string. > >> > >> Which makes me wonder if atomull needs renaming - does the "m" mean > >> memory? atojulong would seem more appropriate regardless. > >> > >> --- > >> > >> src/share/vm/logging/logFileOutput.cpp > >> > >> You removed the size checking logic. > >> > >> Not directly related to your change but I was surprised that the > >> various log file options don't seem to be documented anywhere in the > >> -Xlog:help output. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> Please review it. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: > >>>> PING: Could you review it? > >>>> We need more reviewer. > >>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: > >>>>> CC'ed to serviceability-dev. > >>>>> > >>>>> Could you review it? > >>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: > >>>>>> Hi Marcus, > >>>>>> > >>>>>>> You're missing an include of arguments.hpp in > logFileOutput.cpp. > >>>>>> > >>>>>> arguments.hpp is included in precompiled.hpp . So build was > succeeded. > >>>>>> However, it should be included in logFileOutput.cpp . > >>>>>> > >>>>>> I uploaded a new webrev. Could you review again? > >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> This request review is related to [1]. > >>>>>>>> > >>>>>>>> I want to set filesize option with k/m/g as below: > >>>>>>>> > -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m > >>>>>>>> > >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . > >>>>>>>> I think we can use option parser in arguments.cpp . > >>>>>>>> > >>>>>>>> I uploaded webrev. Could you review it? > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ > >>>>>>> > >>>>>>> You're missing an include of arguments.hpp in > logFileOutput.cpp. > >>>>>>> > >>>>>>> Apart from that, this looks good to me. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Marcus > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I cannot access JPRT. So I need a sponsor. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> [1] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html > >>>>>>>> > >>>>>>> > From robbin.ehn at oracle.com Wed Apr 20 07:40:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 09:40:00 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee Message-ID: <57173250.6030304@oracle.com> Hi all, Please review. We are missing a cr on a log stream, which leads to this guarantee. Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 Thanks ! /Robbin diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 @@ -428,6 +428,7 @@ LogTarget(Trace, jvmti) log; LogStreamCHeap log_stream(log); java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); + log_stream.cr(); CLEAR_PENDING_EXCEPTION; return; } From mikael.gerdin at oracle.com Wed Apr 20 07:51:16 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Apr 2016 09:51:16 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <571734F4.5070006@oracle.com> Hi Robbin, On 2016-04-20 09:40, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } Looks good. /Mikael From robbin.ehn at oracle.com Wed Apr 20 07:53:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 09:53:57 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <571734F4.5070006@oracle.com> References: <57173250.6030304@oracle.com> <571734F4.5070006@oracle.com> Message-ID: <57173595.4030506@oracle.com> Thanks Mikael! /Robbin On 04/20/2016 09:51 AM, Mikael Gerdin wrote: > Hi Robbin, > > On 2016-04-20 09:40, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } > > > Looks good. > > /Mikael From david.holmes at oracle.com Wed Apr 20 07:57:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2016 17:57:44 +1000 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <57173678.9010000@oracle.com> Looks fine to me. Thanks, David On 20/04/2016 5:40 PM, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } From stefan.karlsson at oracle.com Wed Apr 20 08:00:07 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 20 Apr 2016 10:00:07 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <57173707.7070006@oracle.com> Hi Robbin, This looks good to me. This breaks gc nightly and is a fairly trivial change, so I'll push this right away. Thanks, StefanK On 2016-04-20 09:40, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 > -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 > +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } From dmitry.samersoff at oracle.com Wed Apr 20 08:00:53 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2016 11:00:53 +0300 Subject: RFR(S): JDK-8153278 sun/tools/jps/TestJpsJar.java fails in hs nightly In-Reply-To: <5716EB63.1070201@oracle.com> References: <57162D68.4060606@oracle.com> <5716EB63.1070201@oracle.com> Message-ID: <57173735.3070003@oracle.com> David, The problem is observed under Aurora/Windows where the test starts as C:\ but when JPS is run the path is E:\ So the test is failed. I have no ideas how it happens. -Dmitry On 2016-04-20 05:37, David Holmes wrote: > Hi Dmitry, > > On 19/04/2016 11:06 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the changes. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8153278/webrev.01/ >> >> The test (a) get it's own name then (b) launch JPS and check that it's >> name is present in the output. >> >> If for some reason the directory from where the test is run changes it >> name between (a) and (b) test fails. >> >> So test changed to get it's name right before the check of jps output. > > Changes seem fine, but I am curious how the directory can be changed > between (a) and (b) ?? > > Thanks, > David > >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Wed Apr 20 08:00:52 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 10:00:52 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173678.9010000@oracle.com> References: <57173250.6030304@oracle.com> <57173678.9010000@oracle.com> Message-ID: <57173734.9030508@oracle.com> Thanks David! /Robbin On 04/20/2016 09:57 AM, David Holmes wrote: > Looks fine to me. > > Thanks, > David > > On 20/04/2016 5:40 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } From robbin.ehn at oracle.com Wed Apr 20 08:02:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 10:02:00 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173707.7070006@oracle.com> References: <57173250.6030304@oracle.com> <57173707.7070006@oracle.com> Message-ID: <57173778.1020105@oracle.com> Thanks Stefan! And for sponsoring! /Robbin On 04/20/2016 10:00 AM, Stefan Karlsson wrote: > Hi Robbin, > > This looks good to me. This breaks gc nightly and is a fairly trivial > change, so I'll push this right away. > > Thanks, > StefanK > > On 2016-04-20 09:40, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } > From sgehwolf at redhat.com Wed Apr 20 08:55:14 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 20 Apr 2016 10:55:14 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5716EA4D.2030401@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> Message-ID: <1461142514.3502.6.camel@redhat.com> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: > On 4/19/16 19:06, serguei.spitsyn at oracle.com wrote: > > > > On 4/19/16 02:22, serguei.spitsyn at oracle.com wrote: > > > > > > On 4/19/16 02:16, Severin Gehwolf wrote: > > > > > > > > Hi, > > > > > > > > On Tue, 2016-04-19 at 01:33 -0700, serguei.spitsyn at oracle.com wrote: > > > > > > > > > > Hi Severin, > > > > > > > > > > Please, find my comments below. > > > > > > > > > > On 4/15/16 13:52, serguei.spitsyn at oracle.com wrote: > > > > > > > > > > > > On 4/15/16 11:59, Dmitry Samersoff wrote: > > > > > > > > > > > > > > Severin, > > > > > > > > > > > > > > Looks good for me. > > > > > > > > > > > > > > But I'm a little afraid of the fact that now we are holding > > > > > > > eventHandler_lock while doing invoke*. > > > > > > ? It seems, I have this concern too. > > > > > > Please, let me take a look closer at this part if it is done in a? > > > > > > right way. > > > > > ? Ok, my question was not about the eventHandler_lock, but about? > > > > > the invokerLock. Please, see below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So please hold on with backports until the fix bakes in jdk9 for? > > > > > > > some time. > > > > > > ? +1 > > > > > > Thanks, > > > > > > Serguei > > > > > > > > > > > > > > > > > > > > -Dmitry > > > > > > > > > > > > > > On 2016-04-15 19:53, Severin Gehwolf wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Here is a patch which is a redo of the fix for JDK-4858370 which? > > > > > > > > got > > > > > > > > backed out due to it causing test regressions. Specifically? > > > > > > > > problems > > > > > > > > were reported for com/sun/jdi/InvokeTest.java > > > > > > > > and com/sun/jdi/InterfaceMethodsTest.java with the fix for? > > > > > > > > JDK-4858370 > > > > > > > > applied. > > > > > > > > > > > > > > > > Those test regressions were caused because: > > > > > > > > a.) The fix for JDK-4858370 deleted refs from the request object > > > > > > > > ??????while *not* holding the invoker lock. > > > > > > > > b.) Invokes done via invoker_doInvoke() save global references, but > > > > > > > > ??????don't hold the invoker lock either. > > > > > ? It seems, the invokerLock is to protect any uses of the 'request'? > > > > > pointer that points > > > > > to the field ThreadNode.currentInvoke, not to protect the? > > > > > saveGlobalRef() call itself. > > > > > So that, we have a hole in synchronization that you nicely discovered. > > > > Yes, that's right. saveGlobalRef() saves references by using the? > > > > request pointer. > > > > > > > > > > > > > > Here is a couple of more places where the 'request' pointer is not? > > > > > protected with > > > > > the invokerLock: > > > > > ?????invoker_enableInvokeRequests(), invoker_isPending(),? > > > > > invoker_isEnabled(). > > > > > > > > > > I've filed a new bug: > > > > > ???https://bugs.openjdk.java.net/browse/JDK-8154529 > > > > > > > > > > BTW, these are pretty simple or rare cases that do not harm much. > > > > > The function invoker_isPending() is not used at all. > > > > OK. > > > > > > > > > > > > > > Please, consider your fix reviewed. > > > > Thanks! > > > > > > > > The hg exported changeset is here: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/JDK-8153711-jdk9-jdk.export.patch? > > > > > > > > > > > > I'd need somebody to sponsor this for me. > > > I will sponsor the fix for you. > > Hi Severin, > > > > I postpone a push for this fix. > > > > There are two nsk.jdi test failures (they look like deadlocks): > > ? nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) > > ? nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) Those seem closed tests, no? At least I don't see those. Any pointers? > > and one jtreg sun/com/jdi failure (it looks like a deadlock too): > > ? com/sun/jdi/InvokeHangTes.java This seems one I can work with. On which platform does it fail? I've run this test > 100 times when I last tested the patch and didn't observe hangs. > > I'll double check if these failures are regressions caused by your fix? > > or not. > I confirm, the failures above are new regressions introduced by the fix. > The tests fail consistently with the fix and do not fail without the fix. > This new fix grabs relevant locks for both cases above. Thanks for checking! I'll have another look. Hopefully I can reproduce. Cheers, Severin > > > > > > > > > > > > > > > > Testing done: > > > > > > > > ???- com/sun/jdi test set. No regressions + added regression test. > > > > > > > > ???- com/sun/jdi/InterfaceMethodsTest.java did not fail in 1300 > > > > > > > > ?????invocations. Same for com/sun/jdi/InvokeTest.java. > > > > > > > > ???- I haven't seen any crashes in new OomDebugTest.java either. > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153711 > > > > > > > > webrev:? > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.01/ > > > > > > > > > > > > > > > > Once reviewed, I'd need somebody to sponsor this patch. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Severin > > > > > > > > From yasuenag at gmail.com Wed Apr 20 09:15:15 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 20 Apr 2016 18:15:15 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <57171BDA.9010703@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> Message-ID: <571748A3.8090508@gmail.com> Hi David, > ... on 32-bit size_t and julong are not the same size so we would still need to ensure we don't specify a filesize that is greater than SIZE_MAX on 32-bit. Oh... I understood. I've fixed and uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ Thanks, Yasumasa On 2016/04/20 15:04, David Holmes wrote: > On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> > You still removed the size bounds checks: >> > >> > 190 size_t value = parse_value(value_str); >> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >> > 192 errstream->print_cr("Invalid option: %s must be in range >> [0, " >> > 193 SIZE_FORMAT "]", FileSizeOptionKey, >> SIZE_MAX / K); >> > 194 success = false; >> >> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. > > Ah I hadn't realized this was an external value, I thought it was some internally enforced maximum file size limit. So this is just an overflow check really, and ... > >> Arguments::atojulong(atomull) checks value range [2]. > > ... we already do an overflow check in here, but ... > >> Thus I do not think we do not need to check value range in >> LogFileOutput::parse_options(). > > ... on 32-bit size_t and julong are not the same size so we would still need to ensure we don't specify a filesize that is greater than SIZE_MAX on 32-bit. > >> >> > Thanks, I had missed that example usage buried in there, but am still >> > surprised none of these "options" for the handling the file are >> > explicitly documented. >> >> I do not know how we can documented about it. >> (Is it internal process in Oracle?) > > No I just meant that amongst all that help text you already modified, there is nothing, that I could see, that actually describes the possible options for filesize. > > Thanks, > David > >> I can help for it if I can >> >> Thanks, >> >> Yasumasa >> >> [1] >> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >> [2] >> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >> >> 2016/04/20 11:24 "David Holmes" > >: >> >> Hi Yasumasa, >> >> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >> > Hi David, >> > >> > Thank you for your comment. >> > >> > I uploaded new webrev. Could you review again? >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >> >> You still removed the size bounds checks: >> >> 190 size_t value = parse_value(value_str); >> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >> 192 errstream->print_cr("Invalid option: %s must be in >> range [0, " >> 193 SIZE_FORMAT "]", FileSizeOptionKey, >> SIZE_MAX / K); >> 194 success = false; >> >> >> Which makes me wonder if atomull needs renaming - does the "m" mean >> >> memory? atojulong would seem more appropriate regardless. >> > >> > I renamed to atojulong() in new webrev. >> > >> >> Not directly related to your change but I was surprised that the >> >> various log file options don't seem to be documented anywhere in the >> >> -Xlog:help output. >> > >> > I updated help message in new webrev. >> >> Thanks, I had missed that example usage buried in there, but am still >> surprised none of these "options" for the handling the file are >> explicitly documented. >> >> Thanks, >> David >> >> > >> > Thanks, >> > >> > Yasumasa >> > >> > >> > On 2016/04/19 10:14, David Holmes wrote: >> >> Hi Yasumasa, >> >> >> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >> >>> PING: >> >>> >> >>> I've sent review request for JDK-8153073. >> >>> Could you review it? >> >>> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >>> >> >>> If this patch is merged, user can set logfile size with k/m/g. >> >> >> >> Your webrev seems out of date with respect to the current code - the >> >> logfile size processing is done in LogFileOutput::parse_options not >> >> configure_rotation. And of course you now need to work with >> jdk9/hs not >> >> hs-rt. >> >> >> >> That aside: >> >> >> >> src/share/vm/runtime/arguments.cpp >> >> >> >> I don't think you need to add the Arguments:: to the atomull >> calls when >> >> you are executing in Arguments code - lines 2643, 2660 >> >> >> >> This comment could be updated to delete "memory" >> >> >> >> 788 // Parses a memory size specification string. >> >> >> >> Which makes me wonder if atomull needs renaming - does the "m" mean >> >> memory? atojulong would seem more appropriate regardless. >> >> >> >> --- >> >> >> >> src/share/vm/logging/logFileOutput.cpp >> >> >> >> You removed the size checking logic. >> >> >> >> Not directly related to your change but I was surprised that the >> >> various log file options don't seem to be documented anywhere in the >> >> -Xlog:help output. >> >> >> >> Thanks, >> >> David >> >> ----- >> >> >> >>> >> >>> Please review it. >> >>> >> >>> >> >>> Thanks, >> >>> >> >>> Yasumasa >> >>> >> >>> >> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >> >>>> PING: Could you review it? >> >>>> We need more reviewer. >> >>>> >> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >>>> >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Yasumasa >> >>>> >> >>>> >> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >> >>>>> CC'ed to serviceability-dev. >> >>>>> >> >>>>> Could you review it? >> >>>>> >> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> Yasumasa >> >>>>> >> >>>>> >> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >> >>>>>> Hi Marcus, >> >>>>>> >> >>>>>>> You're missing an include of arguments.hpp in >> logFileOutput.cpp. >> >>>>>> >> >>>>>> arguments.hpp is included in precompiled.hpp . So build was >> succeeded. >> >>>>>> However, it should be included in logFileOutput.cpp . >> >>>>>> >> >>>>>> I uploaded a new webrev. Could you review again? >> >>>>>> >> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >> >>>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>>>> Yasumasa >> >>>>>> >> >>>>>> >> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >> >>>>>>> Hi, >> >>>>>>> >> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >> >>>>>>>> Hi all, >> >>>>>>>> >> >>>>>>>> This request review is related to [1]. >> >>>>>>>> >> >>>>>>>> I want to set filesize option with k/m/g as below: >> >>>>>>>> >> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >> >>>>>>>> >> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >> >>>>>>>> I think we can use option parser in arguments.cpp . >> >>>>>>>> >> >>>>>>>> I uploaded webrev. Could you review it? >> >>>>>>>> >> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >> >>>>>>> >> >>>>>>> You're missing an include of arguments.hpp in >> logFileOutput.cpp. >> >>>>>>> >> >>>>>>> Apart from that, this looks good to me. >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> Marcus >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I cannot access JPRT. So I need a sponsor. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Thanks, >> >>>>>>>> >> >>>>>>>> Yasumasa >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >> >>>>>>>> >> >>>>>>> >> From robbin.ehn at oracle.com Wed Apr 20 11:47:04 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 13:47:04 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() Message-ID: <57176C38.3000109@oracle.com> Hi all, please review! print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ Tested with: #define TraceJVMTICalls false in hotspot/src/share/vm/prims/jvmtiEnv.cpp set to true with test-set nsk.jvmti.SetBreakpoint Thanks! /Robbin From marcus.larsson at oracle.com Wed Apr 20 11:54:59 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 20 Apr 2016 13:54:59 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> Hi, On 04/20/2016 01:47 PM, Robbin Ehn wrote: > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, > this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists > as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ Looks good to me. Thanks, Marcus > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Wed Apr 20 11:55:19 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 13:55:19 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> References: <57176C38.3000109@oracle.com> <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> Message-ID: <57176E27.3040607@oracle.com> Thanks Marcus! /Robbin On 04/20/2016 01:54 PM, Marcus Larsson wrote: > Hi, > > On 04/20/2016 01:47 PM, Robbin Ehn wrote: >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, >> this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists >> as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Looks good to me. > > Thanks, > Marcus > >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From yasuenag at gmail.com Wed Apr 20 12:14:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 20 Apr 2016 21:14:54 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <570E4832.9040701@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> Message-ID: <571772BE.3030403@gmail.com> PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ This changes is based on jdk9/hs-rt. But I confirmed this patch works fine on jdk9/hs . Thanks, Yasumasa On 2016/04/13 22:22, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thank you for your comment. > I uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ > > > Thanks, > > Yasumasa > > > On 2016/04/13 21:41, Dmitry Samersoff wrote: >> Yasumasa, >> >> Yes. It's better. >> >> Please place all _saved_* declarations together and add a comment >> explaining what is the purpose of this variables. >> >> -Dmitry >> >> >> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Could you review and sponsor it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>> >>> If it is not accepted, I think that we can add new field to PerfMemory >>> for using in JSnap: >>> ----------------------- >>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 2016 +0000 >>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 2016 +0900 >>> @@ -45,11 +45,16 @@ >>> UINT_CHARS + 1; >>> >>> char* PerfMemory::_start = NULL; >>> +char* PerfMemory::_saved_start = NULL; >>> char* PerfMemory::_end = NULL; >>> +char* PerfMemory::_saved_end = NULL; >>> char* PerfMemory::_top = NULL; >>> +char* PerfMemory::_saved_top = NULL; >>> size_t PerfMemory::_capacity = 0; >>> +size_t PerfMemory::_saved_capacity = 0; >>> jint PerfMemory::_initialized = false; >>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>> >>> void perfMemory_init() { >>> >>> @@ -103,6 +108,8 @@ >>> >>> // allocate PerfData memory region >>> create_memory_region(capacity); >>> + _saved_start = _start; >>> + _saved_capacity = _capacity; >>> >>> if (_start == NULL) { >>> >>> @@ -132,8 +139,11 @@ >>> } >>> >>> _prologue = (PerfDataPrologue *)_start; >>> + _saved_prologue = _prologue; >>> _end = _start + _capacity; >>> + _saved_end = _end; >>> _top = _start + sizeof(PerfDataPrologue); >>> + _saved_top = _top; >>> } >>> >>> assert(_prologue != NULL, "prologue pointer must be initialized"); >>> ----------------------- >>> >>> If it is better, I will upload a webrev. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>> Hi Dmitry, >>>> >>>> Thanks for your comment. >>>> >>>> I uploaded a new webrev. Could you review again? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>> >>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>> Yasumasa, >>>>> >>>>> 1. It's better to change JSnap code to produce meaningful error message >>>>> instead of NPE. >>>> >>>> I added null check and set message to PerfMemory.java . >>>> >>>> >>>>> 2. We should check that no other consumer of perf counters rely on the >>>>> fact it's NULL after call to destroy(). I'm not sure that this part of >>>>> the fix is not dangerous. >>>> >>>> I added new flag (_destroyed) in PerfMemory class. >>>> This flag set true at PerfMemory::destroy(). >>>> >>>> _start, _end, and more field which I removed from destroy() are >>>> private member of >>>> PerfMemory. I implemented that the getter functions of them check >>>> _destroyed flag, >>>> and returns same value before this change. >>>> >>>> So I think this change does not affect other place. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> -Dmitry >>>>> >>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>> PING: Could you review it? >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review it? >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>> >: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core images, I >>>>>>> encountered NPE: >>>>>>> ------------- >>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>> at >>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>> at >>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>> at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>> ------------- >>>>>>> >>>>>>> PerfMemory::destroy() clears all members which are used in JSnap. >>>>>>> Thus NPE is occurred. >>>>>>> >>>>>>> I uploaded webrev for this issue. >>>>>>> Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>> >>>>>>> I cannot access JPRT. >>>>>>> So I need a Sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>> >>>>> >> >> From dmitry.samersoff at oracle.com Wed Apr 20 12:21:55 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2016 15:21:55 +0300 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <571772BE.3030403@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> Message-ID: <57177463.8060003@oracle.com> Yasumasa, I need some more time to check what is happening with performance counters and what side effect this fix can have. Sorry about it. -Dmitry On 2016-04-20 15:14, Yasumasa Suenaga wrote: > PING: Could you review it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ > > This changes is based on jdk9/hs-rt. > But I confirmed this patch works fine on jdk9/hs . > > > Thanks, > > Yasumasa > > > On 2016/04/13 22:22, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> Thank you for your comment. >> I uploaded new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> Yes. It's better. >>> >>> Please place all _saved_* declarations together and add a comment >>> explaining what is the purpose of this variables. >>> >>> -Dmitry >>> >>> >>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Could you review and sponsor it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>> >>>> If it is not accepted, I think that we can add new field to PerfMemory >>>> for using in JSnap: >>>> ----------------------- >>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>> 2016 +0000 >>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>> 2016 +0900 >>>> @@ -45,11 +45,16 @@ >>>> UINT_CHARS + 1; >>>> >>>> char* PerfMemory::_start = NULL; >>>> +char* PerfMemory::_saved_start = NULL; >>>> char* PerfMemory::_end = NULL; >>>> +char* PerfMemory::_saved_end = NULL; >>>> char* PerfMemory::_top = NULL; >>>> +char* PerfMemory::_saved_top = NULL; >>>> size_t PerfMemory::_capacity = 0; >>>> +size_t PerfMemory::_saved_capacity = 0; >>>> jint PerfMemory::_initialized = false; >>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>> >>>> void perfMemory_init() { >>>> >>>> @@ -103,6 +108,8 @@ >>>> >>>> // allocate PerfData memory region >>>> create_memory_region(capacity); >>>> + _saved_start = _start; >>>> + _saved_capacity = _capacity; >>>> >>>> if (_start == NULL) { >>>> >>>> @@ -132,8 +139,11 @@ >>>> } >>>> >>>> _prologue = (PerfDataPrologue *)_start; >>>> + _saved_prologue = _prologue; >>>> _end = _start + _capacity; >>>> + _saved_end = _end; >>>> _top = _start + sizeof(PerfDataPrologue); >>>> + _saved_top = _top; >>>> } >>>> >>>> assert(_prologue != NULL, "prologue pointer must be initialized"); >>>> ----------------------- >>>> >>>> If it is better, I will upload a webrev. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>> Hi Dmitry, >>>>> >>>>> Thanks for your comment. >>>>> >>>>> I uploaded a new webrev. Could you review again? >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>> >>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>> Yasumasa, >>>>>> >>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>> message >>>>>> instead of NPE. >>>>> >>>>> I added null check and set message to PerfMemory.java . >>>>> >>>>> >>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>> the >>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>> part of >>>>>> the fix is not dangerous. >>>>> >>>>> I added new flag (_destroyed) in PerfMemory class. >>>>> This flag set true at PerfMemory::destroy(). >>>>> >>>>> _start, _end, and more field which I removed from destroy() are >>>>> private member of >>>>> PerfMemory. I implemented that the getter functions of them check >>>>> _destroyed flag, >>>>> and returns same value before this change. >>>>> >>>>> So I think this change does not affect other place. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review it? >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review it? >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>> >: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>> images, I >>>>>>>> encountered NPE: >>>>>>>> ------------- >>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>> at >>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>> at >>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>> at >>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>> ------------- >>>>>>>> >>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>> JSnap. >>>>>>>> Thus NPE is occurred. >>>>>>>> >>>>>>>> I uploaded webrev for this issue. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>> >>>>>>>> I cannot access JPRT. >>>>>>>> So I need a Sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>> >>>>>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Wed Apr 20 16:06:53 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 20 Apr 2016 09:06:53 -0700 (PDT) Subject: RFR:8153989:Some SVC tests fail on compact2 due to an unnecessary test library dependency Message-ID: Hi, Could you, please, review this small tests-only fix: CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" Webrev: http://cr.openjdk.java.net/~akulyakh/8153992/test/testlibrary/jdk/test/lib/ProcessTools.java.udiff.html Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. The API is not available on compact2 and below. Therefore the tests failed. We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. I am not sure how acceptable it is to cast from long to int this change. If it is not acceptable we can change the return type to long. This however, will cause massive changes throughout the hotspot tests which presently expect getProcessId() to return int. Best regards, Alexander From dmitry.samersoff at oracle.com Wed Apr 20 17:12:15 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2016 20:12:15 +0300 Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS In-Reply-To: <571661B6.30108@oracle.com> References: <570E72B2.404@oracle.com> <57163903.5070201@oracle.com> <57165FF8.6070207@oracle.com> <571661B6.30108@oracle.com> Message-ID: <5717B86F.7060603@oracle.com> Serguei, The test fails rarely and I'm not able to reproduce the issue. JDWP call JvmtiGetLoadedClasses::getLoadedClasses then store received classes locally. So nothing prevent these classes from being unloaded and I think it's worth to fix. -Dmitry On 2016-04-19 19:49, serguei.spitsyn at oracle.com wrote: > On 4/19/16 09:42, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> 144 // Clazz become invalid since the time we get the class list >> 145 // Skip this entry >> 146 if (error == JVMTI_ERROR_INVALID_CLASS) { >> 147 continue; >> 148 } >> 149 >> I'd like to better understand the root cause of this issue. >> Could you, please, give an idea why a class in this test becomes invalid? >> Do you think there is a potential in this test for a class to get >> unloaded? >> Or is it something about anonymous classes? > > One more question: > Any ideas on why these two tests started failing in November 2015 and > did not fail before? > > > Thanks, > Serguei > > >> >> Thanks, >> Serguei >> >> >> On 4/19/16 06:56, Dmitry Samersoff wrote: >>> Any reviewers? >>> >>> On 2016-04-13 19:24, Dmitry Samersoff wrote: >>>> Everybody. >>>> >>>> Please review a small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ >>>> >>>> I don't have a reproducer, so the fix is based on coredump analyzes. >>>> >>>> Tested with rbt >>>> >>>> -Dmitry >>>> >>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Apr 20 17:44:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Apr 2016 10:44:33 -0700 Subject: RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS In-Reply-To: <5717B86F.7060603@oracle.com> References: <570E72B2.404@oracle.com> <57163903.5070201@oracle.com> <57165FF8.6070207@oracle.com> <571661B6.30108@oracle.com> <5717B86F.7060603@oracle.com> Message-ID: <5717C001.7030209@oracle.com> Dmitry, Thank you for the reply. I hope, you run all the JDI tests including nsk.jdi and jtreg com/sun/jdi. Reviewed. Thanks, Serguei On 4/20/16 10:12, Dmitry Samersoff wrote: > Serguei, > > The test fails rarely and I'm not able to reproduce the issue. > > JDWP call JvmtiGetLoadedClasses::getLoadedClasses then store received > classes locally. > > So nothing prevent these classes from being unloaded and I think it's > worth to fix. > > -Dmitry > > On 2016-04-19 19:49, serguei.spitsyn at oracle.com wrote: >> On 4/19/16 09:42, serguei.spitsyn at oracle.com wrote: >>> Hi Dmitry, >>> >>> 144 // Clazz become invalid since the time we get the class list >>> 145 // Skip this entry >>> 146 if (error == JVMTI_ERROR_INVALID_CLASS) { >>> 147 continue; >>> 148 } >>> 149 >>> I'd like to better understand the root cause of this issue. >>> Could you, please, give an idea why a class in this test becomes invalid? >>> Do you think there is a potential in this test for a class to get >>> unloaded? >>> Or is it something about anonymous classes? >> One more question: >> Any ideas on why these two tests started failing in November 2015 and >> did not fail before? >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> Serguei >>> >>> >>> On 4/19/16 06:56, Dmitry Samersoff wrote: >>>> Any reviewers? >>>> >>>> On 2016-04-13 19:24, Dmitry Samersoff wrote: >>>>> Everybody. >>>>> >>>>> Please review a small fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ >>>>> >>>>> I don't have a reproducer, so the fix is based on coredump analyzes. >>>>> >>>>> Tested with rbt >>>>> >>>>> -Dmitry >>>>> >>>>> > From erik.gahlin at oracle.com Wed Apr 20 20:26:12 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 20 Apr 2016 22:26:12 +0200 Subject: RFR (XS): 8154794,,Add support for experimental fields/events to event-based tracing Message-ID: <5717E5E4.4030506@oracle.com> Hi, Could I have a review of this small fix that adds support for experimental events and experimental fields for event based tracing. Bug: https://bugs.openjdk.java.net/browse/JDK-8154794 Webrev: http://cr.openjdk.java.net/~egahlin/8154794/ Thanks Erik From mandy.chung at oracle.com Wed Apr 20 21:03:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 Apr 2016 14:03:13 -0700 Subject: RFR:8153989:Some SVC tests fail on compact2 due to an unnecessary test library dependency In-Reply-To: References: Message-ID: <524345D9-CA6F-425D-AB77-3C46ACDEF19F@oracle.com> > On Apr 20, 2016, at 9:06 AM, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review this small tests-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153992/test/testlibrary/jdk/test/lib/ProcessTools.java.udiff.html > > Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. > The API is not available on compact2 and below. Therefore the tests failed. > > We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. > This looks okay. But I see that getVmInputArguments calls ManagementFactory.getRuntimeMXBean. So ProcessTools still has a dependency on java.management. The jdk test library ProcessTools::getProcessId has been long ago to call Process::getPid and the method is changed to return long. I thought that similar change would have been made in the hotspot test library at that time. > I am not sure how acceptable it is to cast from long to int this change. If it is not acceptable we can change the return type to long. > This however, will cause massive changes throughout the hotspot tests which presently expect getProcessId() to return int. IMO it would be good to return long or have the callsite to call ProcessHandle.current().getPid(). Mandy From david.holmes at oracle.com Thu Apr 21 05:43:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Apr 2016 15:43:28 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <571748A3.8090508@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> Message-ID: <57186880.7040901@oracle.com> Hi Yasumasa, On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: > Hi David, > >> ... on 32-bit size_t and julong are not the same size so we would >> still need to ensure we don't specify a filesize that is greater than >> SIZE_MAX on 32-bit. > > Oh... I understood. > I've fixed and uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ So it just registered with me that currently filesize is interpreted as a value in KB. With this change it will be in bytes - that means tests will need fixing eg: hotspot/test/serviceability/logging/TestLogRotation.java That change in semantics may not be desirable, but I'll leave that to the owners of this code to decide (and I hope they jump in soon!) I note that in the existing range check: if (value == SIZE_MAX || value > SIZE_MAX / K) { the first clause is redundant. So your change seems okay. Thanks, David ----- > > Thanks, > > Yasumasa > > > On 2016/04/20 15:04, David Holmes wrote: >> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> > You still removed the size bounds checks: >>> > >>> > 190 size_t value = parse_value(value_str); >>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>> > 192 errstream->print_cr("Invalid option: %s must be in range >>> [0, " >>> > 193 SIZE_FORMAT "]", FileSizeOptionKey, >>> SIZE_MAX / K); >>> > 194 success = false; >>> >>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >> >> Ah I hadn't realized this was an external value, I thought it was some >> internally enforced maximum file size limit. So this is just an >> overflow check really, and ... >> >>> Arguments::atojulong(atomull) checks value range [2]. >> >> ... we already do an overflow check in here, but ... >> >>> Thus I do not think we do not need to check value range in >>> LogFileOutput::parse_options(). >> >> ... on 32-bit size_t and julong are not the same size so we would >> still need to ensure we don't specify a filesize that is greater than >> SIZE_MAX on 32-bit. >> >>> >>> > Thanks, I had missed that example usage buried in there, but am still >>> > surprised none of these "options" for the handling the file are >>> > explicitly documented. >>> >>> I do not know how we can documented about it. >>> (Is it internal process in Oracle?) >> >> No I just meant that amongst all that help text you already modified, >> there is nothing, that I could see, that actually describes the >> possible options for filesize. >> >> Thanks, >> David >> >>> I can help for it if I can >>> >>> Thanks, >>> >>> Yasumasa >>> >>> [1] >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>> >>> [2] >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>> >>> >>> 2016/04/20 11:24 "David Holmes" >> >: >>> >>> Hi Yasumasa, >>> >>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>> > Hi David, >>> > >>> > Thank you for your comment. >>> > >>> > I uploaded new webrev. Could you review again? >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>> >>> You still removed the size bounds checks: >>> >>> 190 size_t value = parse_value(value_str); >>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>> 192 errstream->print_cr("Invalid option: %s must be in >>> range [0, " >>> 193 SIZE_FORMAT "]", >>> FileSizeOptionKey, >>> SIZE_MAX / K); >>> 194 success = false; >>> >>> >> Which makes me wonder if atomull needs renaming - does the >>> "m" mean >>> >> memory? atojulong would seem more appropriate regardless. >>> > >>> > I renamed to atojulong() in new webrev. >>> > >>> >> Not directly related to your change but I was surprised that the >>> >> various log file options don't seem to be documented anywhere >>> in the >>> >> -Xlog:help output. >>> > >>> > I updated help message in new webrev. >>> >>> Thanks, I had missed that example usage buried in there, but am >>> still >>> surprised none of these "options" for the handling the file are >>> explicitly documented. >>> >>> Thanks, >>> David >>> >>> > >>> > Thanks, >>> > >>> > Yasumasa >>> > >>> > >>> > On 2016/04/19 10:14, David Holmes wrote: >>> >> Hi Yasumasa, >>> >> >>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>> >>> PING: >>> >>> >>> >>> I've sent review request for JDK-8153073. >>> >>> Could you review it? >>> >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>> >>> >>> If this patch is merged, user can set logfile size with k/m/g. >>> >> >>> >> Your webrev seems out of date with respect to the current >>> code - the >>> >> logfile size processing is done in >>> LogFileOutput::parse_options not >>> >> configure_rotation. And of course you now need to work with >>> jdk9/hs not >>> >> hs-rt. >>> >> >>> >> That aside: >>> >> >>> >> src/share/vm/runtime/arguments.cpp >>> >> >>> >> I don't think you need to add the Arguments:: to the atomull >>> calls when >>> >> you are executing in Arguments code - lines 2643, 2660 >>> >> >>> >> This comment could be updated to delete "memory" >>> >> >>> >> 788 // Parses a memory size specification string. >>> >> >>> >> Which makes me wonder if atomull needs renaming - does the >>> "m" mean >>> >> memory? atojulong would seem more appropriate regardless. >>> >> >>> >> --- >>> >> >>> >> src/share/vm/logging/logFileOutput.cpp >>> >> >>> >> You removed the size checking logic. >>> >> >>> >> Not directly related to your change but I was surprised that the >>> >> various log file options don't seem to be documented anywhere >>> in the >>> >> -Xlog:help output. >>> >> >>> >> Thanks, >>> >> David >>> >> ----- >>> >> >>> >>> >>> >>> Please review it. >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Yasumasa >>> >>> >>> >>> >>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>> >>>> PING: Could you review it? >>> >>>> We need more reviewer. >>> >>>> >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>>> >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> Yasumasa >>> >>>> >>> >>>> >>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>> >>>>> CC'ed to serviceability-dev. >>> >>>>> >>> >>>>> Could you review it? >>> >>>>> >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> >>> >>>>> Yasumasa >>> >>>>> >>> >>>>> >>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>> >>>>>> Hi Marcus, >>> >>>>>> >>> >>>>>>> You're missing an include of arguments.hpp in >>> logFileOutput.cpp. >>> >>>>>> >>> >>>>>> arguments.hpp is included in precompiled.hpp . So build was >>> succeeded. >>> >>>>>> However, it should be included in logFileOutput.cpp . >>> >>>>>> >>> >>>>>> I uploaded a new webrev. Could you review again? >>> >>>>>> >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>> >>>>>> >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> >>> >>>>>> Yasumasa >>> >>>>>> >>> >>>>>> >>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>> >>>>>>> Hi, >>> >>>>>>> >>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>> >>>>>>>> Hi all, >>> >>>>>>>> >>> >>>>>>>> This request review is related to [1]. >>> >>>>>>>> >>> >>>>>>>> I want to set filesize option with k/m/g as below: >>> >>>>>>>> >>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>> >>>>>>>> >>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>> >>>>>>>> I think we can use option parser in arguments.cpp . >>> >>>>>>>> >>> >>>>>>>> I uploaded webrev. Could you review it? >>> >>>>>>>> >>> >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>> >>>>>>> >>> >>>>>>> You're missing an include of arguments.hpp in >>> logFileOutput.cpp. >>> >>>>>>> >>> >>>>>>> Apart from that, this looks good to me. >>> >>>>>>> >>> >>>>>>> Thanks, >>> >>>>>>> Marcus >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> Thanks, >>> >>>>>>>> >>> >>>>>>>> Yasumasa >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> [1] >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>> >>> >>>>>>>> >>> >>>>>>> >>> From yasuenag at gmail.com Thu Apr 21 09:37:00 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Apr 2016 18:37:00 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <57186880.7040901@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> Message-ID: <57189F3C.8070300@gmail.com> Hi David, > So it just registered with me that currently filesize is interpreted as a value in KB. With this change it will be in bytes - that means tests will need fixing eg: > > hotspot/test/serviceability/logging/TestLogRotation.java Thanks! I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ Following jtreg tests are passed: - hotspot/test/gc/logging - hotspot/test/runtime/logging - hotspot/test/serviceability/logging Yasumasa On 2016/04/21 14:43, David Holmes wrote: > Hi Yasumasa, > > On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> ... on 32-bit size_t and julong are not the same size so we would >>> still need to ensure we don't specify a filesize that is greater than >>> SIZE_MAX on 32-bit. >> >> Oh... I understood. >> I've fixed and uploaded new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ > > So it just registered with me that currently filesize is interpreted as a value in KB. With this change it will be in bytes - that means tests will need fixing eg: > > hotspot/test/serviceability/logging/TestLogRotation.java > > That change in semantics may not be desirable, but I'll leave that to the owners of this code to decide (and I hope they jump in soon!) > > I note that in the existing range check: > > if (value == SIZE_MAX || value > SIZE_MAX / K) { > > the first clause is redundant. So your change seems okay. > > Thanks, > David > ----- > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/20 15:04, David Holmes wrote: >>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> > You still removed the size bounds checks: >>>> > >>>> > 190 size_t value = parse_value(value_str); >>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>> > 192 errstream->print_cr("Invalid option: %s must be in range >>>> [0, " >>>> > 193 SIZE_FORMAT "]", FileSizeOptionKey, >>>> SIZE_MAX / K); >>>> > 194 success = false; >>>> >>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>> >>> Ah I hadn't realized this was an external value, I thought it was some >>> internally enforced maximum file size limit. So this is just an >>> overflow check really, and ... >>> >>>> Arguments::atojulong(atomull) checks value range [2]. >>> >>> ... we already do an overflow check in here, but ... >>> >>>> Thus I do not think we do not need to check value range in >>>> LogFileOutput::parse_options(). >>> >>> ... on 32-bit size_t and julong are not the same size so we would >>> still need to ensure we don't specify a filesize that is greater than >>> SIZE_MAX on 32-bit. >>> >>>> >>>> > Thanks, I had missed that example usage buried in there, but am still >>>> > surprised none of these "options" for the handling the file are >>>> > explicitly documented. >>>> >>>> I do not know how we can documented about it. >>>> (Is it internal process in Oracle?) >>> >>> No I just meant that amongst all that help text you already modified, >>> there is nothing, that I could see, that actually describes the >>> possible options for filesize. >>> >>> Thanks, >>> David >>> >>>> I can help for it if I can >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> [1] >>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>> >>>> [2] >>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>> >>>> >>>> 2016/04/20 11:24 "David Holmes" >>> >: >>>> >>>> Hi Yasumasa, >>>> >>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>> > Hi David, >>>> > >>>> > Thank you for your comment. >>>> > >>>> > I uploaded new webrev. Could you review again? >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>> >>>> You still removed the size bounds checks: >>>> >>>> 190 size_t value = parse_value(value_str); >>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>> 192 errstream->print_cr("Invalid option: %s must be in >>>> range [0, " >>>> 193 SIZE_FORMAT "]", >>>> FileSizeOptionKey, >>>> SIZE_MAX / K); >>>> 194 success = false; >>>> >>>> >> Which makes me wonder if atomull needs renaming - does the >>>> "m" mean >>>> >> memory? atojulong would seem more appropriate regardless. >>>> > >>>> > I renamed to atojulong() in new webrev. >>>> > >>>> >> Not directly related to your change but I was surprised that the >>>> >> various log file options don't seem to be documented anywhere >>>> in the >>>> >> -Xlog:help output. >>>> > >>>> > I updated help message in new webrev. >>>> >>>> Thanks, I had missed that example usage buried in there, but am >>>> still >>>> surprised none of these "options" for the handling the file are >>>> explicitly documented. >>>> >>>> Thanks, >>>> David >>>> >>>> > >>>> > Thanks, >>>> > >>>> > Yasumasa >>>> > >>>> > >>>> > On 2016/04/19 10:14, David Holmes wrote: >>>> >> Hi Yasumasa, >>>> >> >>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>> >>> PING: >>>> >>> >>>> >>> I've sent review request for JDK-8153073. >>>> >>> Could you review it? >>>> >>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>> >>>> >>> If this patch is merged, user can set logfile size with k/m/g. >>>> >> >>>> >> Your webrev seems out of date with respect to the current >>>> code - the >>>> >> logfile size processing is done in >>>> LogFileOutput::parse_options not >>>> >> configure_rotation. And of course you now need to work with >>>> jdk9/hs not >>>> >> hs-rt. >>>> >> >>>> >> That aside: >>>> >> >>>> >> src/share/vm/runtime/arguments.cpp >>>> >> >>>> >> I don't think you need to add the Arguments:: to the atomull >>>> calls when >>>> >> you are executing in Arguments code - lines 2643, 2660 >>>> >> >>>> >> This comment could be updated to delete "memory" >>>> >> >>>> >> 788 // Parses a memory size specification string. >>>> >> >>>> >> Which makes me wonder if atomull needs renaming - does the >>>> "m" mean >>>> >> memory? atojulong would seem more appropriate regardless. >>>> >> >>>> >> --- >>>> >> >>>> >> src/share/vm/logging/logFileOutput.cpp >>>> >> >>>> >> You removed the size checking logic. >>>> >> >>>> >> Not directly related to your change but I was surprised that the >>>> >> various log file options don't seem to be documented anywhere >>>> in the >>>> >> -Xlog:help output. >>>> >> >>>> >> Thanks, >>>> >> David >>>> >> ----- >>>> >> >>>> >>> >>>> >>> Please review it. >>>> >>> >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Yasumasa >>>> >>> >>>> >>> >>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>> >>>> PING: Could you review it? >>>> >>>> We need more reviewer. >>>> >>>> >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> >>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>> >>>>> CC'ed to serviceability-dev. >>>> >>>>> >>>> >>>>> Could you review it? >>>> >>>>> >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>>> >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> >>>> >>>>> Yasumasa >>>> >>>>> >>>> >>>>> >>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>> >>>>>> Hi Marcus, >>>> >>>>>> >>>> >>>>>>> You're missing an include of arguments.hpp in >>>> logFileOutput.cpp. >>>> >>>>>> >>>> >>>>>> arguments.hpp is included in precompiled.hpp . So build was >>>> succeeded. >>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>> >>>>>> >>>> >>>>>> I uploaded a new webrev. Could you review again? >>>> >>>>>> >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> >>>> >>>>>> Yasumasa >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>> >>>>>>> Hi, >>>> >>>>>>> >>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>> >>>>>>>> Hi all, >>>> >>>>>>>> >>>> >>>>>>>> This request review is related to [1]. >>>> >>>>>>>> >>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>> >>>>>>>> >>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>> >>>>>>>> >>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>> >>>>>>>> >>>> >>>>>>>> I uploaded webrev. Could you review it? >>>> >>>>>>>> >>>> >>>>>>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>> >>>>>>> >>>> >>>>>>> You're missing an include of arguments.hpp in >>>> logFileOutput.cpp. >>>> >>>>>>> >>>> >>>>>>> Apart from that, this looks good to me. >>>> >>>>>>> >>>> >>>>>>> Thanks, >>>> >>>>>>> Marcus >>>> >>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> Thanks, >>>> >>>>>>>> >>>> >>>>>>>> Yasumasa >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> [1] >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>> >>>> >>>>>>>> >>>> >>>>>>> >>>> From andreas.eriksson at oracle.com Thu Apr 21 13:47:35 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 21 Apr 2016 15:47:35 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof In-Reply-To: <57113129.5060802@oracle.com> References: <5710FD55.9060209@oracle.com> <57113129.5060802@oracle.com> Message-ID: <95a0309a-abe9-18f3-ce3f-b1043b8fd067@oracle.com> Hi, On 2016-04-15 20:21, Erik Gahlin wrote: > Looks good, not a Reviewer. Thanks. > > Do you really need curly braces in the switch clauses? In JavaValueArray.java they were needed before my change but not after. Do you want me to remove them? In JavaObject.java they are needed because the 'value' variable is a different type in each clause, I could refactor so that I could remove the curly braces, but I don't think it is worth the effort. - Andreas > > Erik > > On 2016-04-15 16:40, Andreas Eriksson wrote: >> Hi, >> >> Please review this test fix for 8149790: NegativeArraySizeException >> with hprof >> >> https://bugs.openjdk.java.net/browse/JDK-8149790 >> http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ >> >> Changes are to the hprof verifier, which now will pass heap dump >> content around as JavaThing arrays instead of byte arrays, since the >> latter cannot be guaranteed to be able to hold all the elements of >> large arrays. >> >> There is still a problem where the test will timeout on machines with >> lots of memory (seen on machines with 200+GB of memory) because the >> verification takes a long time. I'll file a new bug for that problem. >> >> Regards, >> Andreas > From marcus.larsson at oracle.com Thu Apr 21 14:37:01 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 21 Apr 2016 16:37:01 +0200 Subject: RFR (XS): 8154794, , Add support for experimental fields/events to event-based tracing In-Reply-To: <5717E5E4.4030506@oracle.com> References: <5717E5E4.4030506@oracle.com> Message-ID: Hi, On 04/20/2016 10:26 PM, Erik Gahlin wrote: > Hi, > > Could I have a review of this small fix that adds support for > experimental events and experimental fields for event based tracing. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8154794 > > Webrev: > http://cr.openjdk.java.net/~egahlin/8154794/ Looks good to me. Thanks, Marcus > > Thanks > Erik From erik.gahlin at oracle.com Thu Apr 21 16:46:13 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 21 Apr 2016 18:46:13 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof In-Reply-To: <95a0309a-abe9-18f3-ce3f-b1043b8fd067@oracle.com> References: <5710FD55.9060209@oracle.com> <57113129.5060802@oracle.com> <95a0309a-abe9-18f3-ce3f-b1043b8fd067@oracle.com> Message-ID: <571903D5.3050703@oracle.com> On 2016-04-21 15:47, Andreas Eriksson wrote: > Hi, > > > On 2016-04-15 20:21, Erik Gahlin wrote: >> Looks good, not a Reviewer. > > Thanks. > >> >> Do you really need curly braces in the switch clauses? > > In JavaValueArray.java they were needed before my change but not > after. Do you want me to remove them? > In JavaObject.java they are needed because the 'value' variable is a > different type in each clause, I could refactor so that I could remove > the curly braces, but I don't think it is worth the effort. > I was thinking about JavaValueArray.java. It would look better without them, but no need to create an updated webrev just for that. Erik > - Andreas > >> >> Erik >> >> On 2016-04-15 16:40, Andreas Eriksson wrote: >>> Hi, >>> >>> Please review this test fix for 8149790: NegativeArraySizeException >>> with hprof >>> >>> https://bugs.openjdk.java.net/browse/JDK-8149790 >>> http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ >>> >>> Changes are to the hprof verifier, which now will pass heap dump >>> content around as JavaThing arrays instead of byte arrays, since the >>> latter cannot be guaranteed to be able to hold all the elements of >>> large arrays. >>> >>> There is still a problem where the test will timeout on machines >>> with lots of memory (seen on machines with 200+GB of memory) because >>> the verification takes a long time. I'll file a new bug for that >>> problem. >>> >>> Regards, >>> Andreas >> > From andreas.eriksson at oracle.com Thu Apr 21 17:35:45 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 21 Apr 2016 19:35:45 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof In-Reply-To: <571903D5.3050703@oracle.com> References: <5710FD55.9060209@oracle.com> <57113129.5060802@oracle.com> <95a0309a-abe9-18f3-ce3f-b1043b8fd067@oracle.com> <571903D5.3050703@oracle.com> Message-ID: On 2016-04-21 18:46, Erik Gahlin wrote: > On 2016-04-21 15:47, Andreas Eriksson wrote: >> Hi, >> >> >> On 2016-04-15 20:21, Erik Gahlin wrote: >>> Looks good, not a Reviewer. >> >> Thanks. >> >>> >>> Do you really need curly braces in the switch clauses? >> >> In JavaValueArray.java they were needed before my change but not >> after. Do you want me to remove them? >> In JavaObject.java they are needed because the 'value' variable is a >> different type in each clause, I could refactor so that I could >> remove the curly braces, but I don't think it is worth the effort. >> > I was thinking about JavaValueArray.java. > > It would look better without them, but no need to create an updated > webrev just for that. Alright, I'll change that before I push. Could a Reviewer take a look as well? - Andreas > > Erik > >> - Andreas >> >>> >>> Erik >>> >>> On 2016-04-15 16:40, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Please review this test fix for 8149790: NegativeArraySizeException >>>> with hprof >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8149790 >>>> http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ >>>> >>>> Changes are to the hprof verifier, which now will pass heap dump >>>> content around as JavaThing arrays instead of byte arrays, since >>>> the latter cannot be guaranteed to be able to hold all the elements >>>> of large arrays. >>>> >>>> There is still a problem where the test will timeout on machines >>>> with lots of memory (seen on machines with 200+GB of memory) >>>> because the verification takes a long time. I'll file a new bug for >>>> that problem. >>>> >>>> Regards, >>>> Andreas >>> >> > From stuart.marks at oracle.com Fri Apr 22 02:21:16 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 21 Apr 2016 19:21:16 -0700 Subject: Fwd: RFR(s): 8154801 deprecate java.util.Observable/Observer In-Reply-To: <571989A8.3010901@oracle.com> References: <571989A8.3010901@oracle.com> Message-ID: <57198A9C.3000104@oracle.com> Hi all, I just posted the following to core-libs-dev. The only user of Observable/Observer in the JDK is the Serviceability Agent. Unless I missed something, the only impact the deprecation will have on SA is the generation of deprecation warnings, were SA to be compiled with deprecation warnings enabled. Currently, SA is compiled without warnings enabled. I can assist with migrating SA away from Observable/Observer, if there's any interest in doing that. s'marks -------- Forwarded Message -------- Subject: RFR(s): 8154801 deprecate java.util.Observable/Observer Date: Thu, 21 Apr 2016 19:17:12 -0700 From: Stuart Marks To: core-libs-dev Hi all, Here's a small proposal to deprecate the java.util.Observable and Observer. This deprecation will not be for removal. See https://bugs.openjdk.java.net/browse/JDK-8154801 for some background. Essentially, these classes are a very thin implementation of the Observer pattern. These classes provide little beyond maintaining a list of callbacks plus the ability calling them upon request. A 1999 comment from Josh Bloch in a related bug report said that they are no longer under active development and have been superseded by the 1.1 Beans/AWT event model. Their only use in the JDK is in the Hotspot Serviceability Agent, which doesn't even use Observable, and which uses Observer as a callback interface. SA's use of Observer could easily be replaced with lambdas and Consumer. There is some use of these classes "in the wild" but only for conventional callback purposes. Deprecation will generate warnings if that code is recompiled with deprecation warnings enabled. Diffs follow. Thanks, s'marks diff -r 92280897299f -r e16d8d56da15 src/java.base/share/classes/java/util/Observable.java --- a/src/java.base/share/classes/java/util/Observable.java Mon Apr 18 14:10:14 2016 -0700 +++ b/src/java.base/share/classes/java/util/Observable.java Thu Apr 21 15:48:23 2016 -0700 @@ -58,7 +58,19 @@ * @see java.util.Observer * @see java.util.Observer#update(java.util.Observable, java.lang.Object) * @since 1.0 + * + * @deprecated + * This class and the {@link Observer} interface have been deprecated. + * The event model supported by {@code Observer} and {@code Observable} + * is quite limited, the order of notifications delivered by + * {@code Observable} is unspecified, and state changes are not in + * one-for-one correspondence with notifications. + * For a richer event model, consider using the + * {@link java.beans} package. For reliable and ordered + * messaging among threads, consider using one of the concurrent data + * structures in the {@link java.util.concurrent} package. */ + at Deprecated(since="9") public class Observable { private boolean changed = false; private Vector obs; diff -r 92280897299f -r e16d8d56da15 src/java.base/share/classes/java/util/Observer.java --- a/src/java.base/share/classes/java/util/Observer.java Mon Apr 18 14:10:14 2016 -0700 +++ b/src/java.base/share/classes/java/util/Observer.java Thu Apr 21 15:48:23 2016 -0700 @@ -31,7 +31,12 @@ * @author Chris Warth * @see java.util.Observable * @since 1.0 + * + * @deprecated + * This interface has been deprecated. See the {@link Observable} + * class for further information. */ + at Deprecated(since="9") public interface Observer { /** * This method is called whenever the observed object is changed. An From harsha.wardhana.b at oracle.com Fri Apr 22 07:10:39 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 22 Apr 2016 12:40:39 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Message-ID: <5719CE6F.3030704@oracle.com> Hi, Please review the below simple fix for issue, issue : https://bugs.openjdk.java.net/browse/JDK-8154166 webrev : http://cr.openjdk.java.net/~hb/8154166/webrev.00/ -Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Fri Apr 22 08:06:52 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 22 Apr 2016 16:06:52 +0800 Subject: JDK 9 RFR of JDK-8154277: JavaDoc warnings in VirtualMachineManager.java and Pool.java Message-ID: <5719DB9C.5040504@oracle.com> Please review this tiny fix for typos in the the documentation of: jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java bug: https://bugs.openjdk.java.net/browse/JDK-8154277 webrev: http://cr.openjdk.java.net/~amlu/8154277/webrev.00/ Thanks, Amy --- old/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java 2016-04-22 15:53:09.000000000 +0800 +++ new/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java 2016-04-22 15:53:09.000000000 +0800 @@ -257,11 +257,11 @@ * delegate to the {@link com.sun.jdi.connect.spi.TransportService#description() * description()} method of the underlying transport service. Both * the AttachingConnector and the ListeningConnector will have two - * Connector {@link com.sun.jdi.connect.Connector$Argument Arguments}. - * A {@link com.sun.jdi.connect.Connector$StringArgument StringArgument} + * Connector {@link com.sun.jdi.connect.Connector.Argument Arguments}. + * A {@link com.sun.jdi.connect.Connector.StringArgument StringArgument} * named {@code address} is the connector argument to specify the * address to attach too, or to listen on. A - * {@link com.sun.jdi.connect.Connector$IntegerArgument IntegerArgument} + * {@link com.sun.jdi.connect.Connector.IntegerArgument IntegerArgument} * named {@code timeout} is the connector argument to specify the * timeout when attaching, or accepting. The timeout connector may be * ignored depending on if the transport service supports an attach --- old/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java 2016-04-22 15:53:10.000000000 +0800 +++ new/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java 2016-04-22 15:53:10.000000000 +0800 @@ -226,7 +226,7 @@ *
  • For jimage content: /{module name}/{package1}/.../{packageN}/{file * name}
    • *
  • For other files (shared lib, launchers, config, ...):/{module name}/ - * {@literal bin|conf|native}/{dir1}>/.../{dirN}/{file name}
    • + * {@literal bin|conf|native}/{dir1}/.../{dirN}/{file name} * */ public static class ModuleData { -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Apr 22 08:09:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Apr 2016 09:09:42 +0100 Subject: JDK 9 RFR of JDK-8154277: JavaDoc warnings in VirtualMachineManager.java and Pool.java In-Reply-To: <5719DB9C.5040504@oracle.com> References: <5719DB9C.5040504@oracle.com> Message-ID: <5719DC46.9000505@oracle.com> On 22/04/2016 09:06, Amy Lu wrote: > Please review this tiny fix for typos in the the documentation of: > > jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java > jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java > > > bug: https://bugs.openjdk.java.net/browse/JDK-8154277 > webrev: http://cr.openjdk.java.net/~amlu/8154277/webrev.00/ > > Thanks, > Amy Looks good. In the case of the jlink API then the javadoc was clean at one point but it seems to have regressed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bachorik at gmail.com Fri Apr 22 14:28:46 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Fri, 22 Apr 2016 16:28:46 +0200 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: <5719CE6F.3030704@oracle.com> References: <5719CE6F.3030704@oracle.com> Message-ID: Hi, On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < harsha.wardhana.b at oracle.com> wrote: > Hi, > > Please review the below simple fix for issue, > > issue : https://bugs.openjdk.java.net/browse/JDK-8154166 > webrev : > http://cr.openjdk.java.net/~hb/8154166/webrev.00/ > Shouldn't this test rather declare the conditions when it is supposed to work? According to the issue this was caused by introducing the "-XX:+ExplicitGCInvokesConcurrent" which makes it very tricky to make any assumptions about the GC process. See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java for enabling the test only for allowed configurations. Cheers, -JB- > > > -Harsha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Apr 22 22:18:15 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 22 Apr 2016 15:18:15 -0700 Subject: JDK 9 RFR of JDK-8154277: JavaDoc warnings in VirtualMachineManager.java and Pool.java In-Reply-To: <5719DC46.9000505@oracle.com> References: <5719DB9C.5040504@oracle.com> <5719DC46.9000505@oracle.com> Message-ID: <571AA327.7000208@oracle.com> On 4/22/2016 1:09 AM, Alan Bateman wrote: > > On 22/04/2016 09:06, Amy Lu wrote: >> Please review this tiny fix for typos in the the documentation of: >> >> jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java >> jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154277 >> webrev: http://cr.openjdk.java.net/~amlu/8154277/webrev.00/ >> >> Thanks, >> Amy > Looks good. In the case of the jlink API then the javadoc was clean at > one point but it seems to have regressed. > I took a quick look at the makefile and didn't see a specialized entry for jdk.jlink. In any case, I recommend the build options for jdk.jlink, wherever they are, to be modified to make lint and doclint warnings fatal. Cheers, -Joe From harsha.wardhana.b at oracle.com Sat Apr 23 10:15:05 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Sat, 23 Apr 2016 15:45:05 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: References: <5719CE6F.3030704@oracle.com> Message-ID: <571B4B29.8040808@oracle.com> Hello, The issue was not reproducible with or without, "-XX:+ExplicitGCInvokesConcurrent" Flag. The patch ensures that GC happens before we start measuring memory. Without the patch, GC might or might not happen. -Harsha On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: > Hi, > > On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B > > > wrote: > > Hi, > > Please review the below simple fix for issue, > > issue : https://bugs.openjdk.java.net/browse/JDK-8154166 > webrev : http://cr.openjdk.java.net/~hb/8154166/webrev.00/ > > > > Shouldn't this test rather declare the conditions when it is supposed > to work? According to the issue this was caused by introducing the > "-XX:+ExplicitGCInvokesConcurrent" which makes it very tricky to make > any assumptions about the GC process. > > See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java > for enabling the test only for allowed configurations. > > Cheers, > > -JB- > > > > -Harsha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bachorik at gmail.com Sun Apr 24 09:47:19 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Sun, 24 Apr 2016 11:47:19 +0200 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: <571B4B29.8040808@oracle.com> References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> Message-ID: The reproducer would be very time sensitive as with the provided 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the invoker. Otherwise, in the current implementation, calling Runtime.gc() would guarantee the GC cycle has finished before that method returns. The WeakReference javadoc ( https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) is only stating that the referenced object will be made finalizable at the same time as the reference is cleared. As a consequence a cleared reference might not always mean that the heap usage has been changed (unless a particular GC implementation makes some additional guarantees). I know we were stabilizing a bunch of related tests relying on GC doing its work before checking for some post-conditions and the only way to make the tests reliable was to forbid running those tests with '-XX:+ExplicitGCInvokesConcurrent'. -JB- On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B < harsha.wardhana.b at oracle.com> wrote: > Hello, > > The issue was not reproducible with or without, > > "-XX:+ExplicitGCInvokesConcurrent" > > Flag. The patch ensures that GC happens before we start measuring memory. > Without the patch, GC might or might not happen. > > -Harsha > > > On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: > > Hi, > > On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < > harsha.wardhana.b at oracle.com> wrote: > >> Hi, >> >> Please review the below simple fix for issue, >> >> issue : https://bugs.openjdk.java.net/browse/JDK-8154166 >> webrev : http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >> > > Shouldn't this test rather declare the conditions when it is supposed to > work? According to the issue this was caused by introducing the "-XX:+ExplicitGCInvokesConcurrent" > which makes it very tricky to make any assumptions about the GC process. > > See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java for > enabling the test only for allowed configurations. > > Cheers, > > -JB- > > >> >> >> -Harsha >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Mon Apr 25 07:27:47 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 25 Apr 2016 12:57:47 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> Message-ID: <571DC6F3.2090502@oracle.com> Hi, Please review below patch to disable concurrent GC option. http://cr.openjdk.java.net/~hb/8154166/webrev.01/ Jaroslav, According to Javadoc of Runtime.gc(), https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- The call will only make it's best effort to do a GC and provides no guarantee that a given object can be collected even if GC runs. It does not say that Runtime.gc() call will block till entire GC cycle is finished and hence we cannot be making that assumption. Hence it is required that we encapsulate the target object in WeakReference and repeatedly call GC till weakRef returns null. Granted that we will have a small window when weakRef returns null and the target object is not removed from memory. But I see no way how to fix that problem. -Harsha On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: > The reproducer would be very time sensitive as with the provided > 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the > invoker. Otherwise, in the current implementation, calling > Runtime.gc() would guarantee the GC cycle has finished before that > method returns. > > The WeakReference javadoc > (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) > is only stating that the referenced object will be made finalizable at > the same time as the reference is cleared. As a consequence a cleared > reference might not always mean that the heap usage has been changed > (unless a particular GC implementation makes some additional guarantees). > > I know we were stabilizing a bunch of related tests relying on GC > doing its work before checking for some post-conditions and the only > way to make the tests reliable was to forbid running those tests with > '-XX:+ExplicitGCInvokesConcurrent'. > > -JB- > > On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B > > > wrote: > > Hello, > > The issue was not reproducible with or without, > > "-XX:+ExplicitGCInvokesConcurrent" > > Flag. The patch ensures that GC happens before we start measuring > memory. Without the patch, GC might or might not happen. > > -Harsha > > > On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >> Hi, >> >> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B >> > > wrote: >> >> Hi, >> >> Please review the below simple fix for issue, >> >> issue : https://bugs.openjdk.java.net/browse/JDK-8154166 >> webrev : http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >> >> >> >> Shouldn't this test rather declare the conditions when it is >> supposed to work? According to the issue this was caused by >> introducing the "-XX:+ExplicitGCInvokesConcurrent" which makes it >> very tricky to make any assumptions about the GC process. >> >> See eg. >> jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >> for enabling the test only for allowed configurations. >> >> Cheers, >> >> -JB- >> >> >> >> -Harsha >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Apr 25 07:53:09 2016 From: jini.george at oracle.com (Jini George) Date: Mon, 25 Apr 2016 00:53:09 -0700 (PDT) Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Message-ID: Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571" JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT : hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Apr 25 08:59:16 2016 From: jini.george at oracle.com (Jini George) Date: Mon, 25 Apr 2016 01:59:16 -0700 (PDT) Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: Message-ID: Adding hotspot-runtime as well since this includes runtime changes. Regards, Jini. From: Jini George Sent: Monday, April 25, 2016 1:23 PM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: 1. Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) 2. Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT testsets: hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Apr 25 11:45:14 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Apr 2016 14:45:14 +0300 Subject: RFR(S): JDK-8155009 jstack subtest of BasicLauncherTest should not be executed under OS X Message-ID: <571E034A.6070002@oracle.com> Everybody, Please review the test changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8155009/webrev.01/ Coredump stackwalking is not implemented on OS X so skip corresponding test. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Apr 25 11:50:26 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Apr 2016 14:50:26 +0300 Subject: RFR(L): JDK-8154258 [TESTBUG] Various serviceability tests fail compilation In-Reply-To: <5714CCCA.7030809@oracle.com> References: <5714CCCA.7030809@oracle.com> Message-ID: <571E0482.6050000@oracle.com> Everybody, Please review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8154258/webrev.04/ 1. Change hotspot/test/testlibrary/jdk/test/lib/Utils.java to match /test/lib/share/classes/jdk/test/lib/Utils.java i.e. replace sun.misc.Unsafe to jdk.internal.misc.Unsafe 2. Add the tag @modules java.base/jdk.internal.misc to all tests that uses testlibrary 3. Replace all occurrence of sun.misc.Unsafe to jdk.internal.misc.Unsafe Testing: local, RBT:hotspot_all -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Mon Apr 25 12:17:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 25 Apr 2016 14:17:35 +0200 Subject: RFR(S): JDK-8155009 jstack subtest of BasicLauncherTest should not be executed under OS X In-Reply-To: <571E034A.6070002@oracle.com> References: <571E034A.6070002@oracle.com> Message-ID: <0eef1119-22b2-7439-1b2c-9b1561c9870c@oracle.com> Hi Dmitry, For separate RFE, wouldn't it be nicer if these 4 tests where split into 4 jtreg so we could use in this case: @requires ((os.family == "linux") & (os.arch=="amd64")) | (os.family == "solaris") instead ? Looks good to me! /Robbin (not a Reviewer) On 04/25/2016 01:45 PM, Dmitry Samersoff wrote: > Everybody, > > Please review the test changes. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155009/webrev.01/ > > Coredump stackwalking is not implemented on OS X so skip corresponding test. > > -Dmitry > > From yasuenag at gmail.com Mon Apr 25 12:19:21 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 21:19:21 +0900 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: <56FD220A.2090600@oracle.com> References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> Message-ID: Hi Marcus, > Please see > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html > for the configuration string issue. It was sent out earlier today. Did you fix for trailing comma from decoration list? Comma for decoration exists yet in result of VM.log list jcmd. > Your suggested fix for the decorator listing is broken. The for loop you > modified iterates over all possible decorators, not all enabled > decorators. So unless you have the last possible decorator enabled you > will still get a trailing comma. I think we can fix as below. Should I file it to JBS as new issue? ------------------- diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 2016 +0200 +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 2016 +0900 @@ -408,10 +408,13 @@ out->print_cr("Log output configuration:"); for (size_t i = 0; i < _n_outputs; i++) { out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), _outputs[i]->config_string()); + bool first_decorator = true; for (size_t d = 0; d < LogDecorators::Count; d++) { LogDecorators::Decorator decorator = static_cast(d); if (_outputs[i]->decorators().is_decorator(decorator)) { - out->print("%s,", LogDecorators::name(decorator)); + out->print("%s%s", first_decorator ? "" : ",", + LogDecorators::name(decorator)); + first_decorator = false; } } out->cr(); ------------------- Thanks, Yasumasa On 2016/03/31 22:11, Marcus Larsson wrote: > Hi, > > On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> We can check log configuration through VM.log list jcmd: >> ------- >> Log output configuration: >> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >> #1: stderr all=warning uptime,level,tags, >> #2: gc.log gc=trace, uptime,level,tags, >> ------- >> >> Configuration string and decorators are ended with comma. >> We should remove it as below: >> ------- >> Log output configuration: >> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >> #1: stderr all=warning uptime,level,tags >> #2: gc.log gc=trace uptime,level,tags >> ------- >> >> >> I uploaded webrev for this issue. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ > > Please see > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html > for the configuration string issue. It was sent out earlier today. > > Your suggested fix for the decorator listing is broken. The for loop you > modified iterates over all possible decorators, not all enabled > decorators. So unless you have the last possible decorator enabled you > will still get a trailing comma. > > Also, please note that UL belongs to the serviceability subcomponent, > and patches like this should probably go to the serviceability-dev > mailing list. > > Thanks, > Marcus > >> >> >> I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> > From dmitry.samersoff at oracle.com Mon Apr 25 12:24:59 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Apr 2016 15:24:59 +0300 Subject: RFR(S): JDK-8155009 jstack subtest of BasicLauncherTest should not be executed under OS X In-Reply-To: <0eef1119-22b2-7439-1b2c-9b1561c9870c@oracle.com> References: <571E034A.6070002@oracle.com> <0eef1119-22b2-7439-1b2c-9b1561c9870c@oracle.com> Message-ID: <571E0C9B.6070304@oracle.com> Robbin, On 2016-04-25 15:17, Robbin Ehn wrote: > Hi Dmitry, > > For separate RFE, wouldn't it be nicer if these 4 tests where split into > 4 jtreg so we could use in this case: > > @requires ((os.family == "linux") & (os.arch=="amd64")) | (os.family == > "solaris") > > instead ? Yes, I think we should do it someday as well as change other similar tests. -Dmitry > > Looks good to me! > > /Robbin (not a Reviewer) > > > On 04/25/2016 01:45 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the test changes. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155009/webrev.01/ >> >> Coredump stackwalking is not implemented on OS X so skip corresponding >> test. >> >> -Dmitry >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Apr 25 12:44:54 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 25 Apr 2016 15:44:54 +0300 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> Message-ID: <571E1146.2020204@oracle.com> Yasumasa, It might be better to deal with first comma as: char delimiter[2] = {0,0}; for (...) { printf("%s%s", delimiter, LogDecorators::name(decorator)); *delimiter = ','; } -Dmitry On 2016-04-25 15:19, Yasumasa Suenaga wrote: > Hi Marcus, > >> Please see >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >> >> for the configuration string issue. It was sent out earlier today. > > Did you fix for trailing comma from decoration list? > Comma for decoration exists yet in result of VM.log list jcmd. > >> Your suggested fix for the decorator listing is broken. The for loop you >> modified iterates over all possible decorators, not all enabled >> decorators. So unless you have the last possible decorator enabled you >> will still get a trailing comma. > > I think we can fix as below. > Should I file it to JBS as new issue? > ------------------- > diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp > --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 2016 > +0200 > +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 2016 > +0900 > @@ -408,10 +408,13 @@ > out->print_cr("Log output configuration:"); > for (size_t i = 0; i < _n_outputs; i++) { > out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), > _outputs[i]->config_string()); > + bool first_decorator = true; > for (size_t d = 0; d < LogDecorators::Count; d++) { > LogDecorators::Decorator decorator = > static_cast(d); > if (_outputs[i]->decorators().is_decorator(decorator)) { > - out->print("%s,", LogDecorators::name(decorator)); > + out->print("%s%s", first_decorator ? "" : ",", > + LogDecorators::name(decorator)); > + first_decorator = false; > } > } > out->cr(); > ------------------- > > > Thanks, > > Yasumasa > > > On 2016/03/31 22:11, Marcus Larsson wrote: >> Hi, >> >> On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> We can check log configuration through VM.log list jcmd: >>> ------- >>> Log output configuration: >>> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >>> #1: stderr all=warning uptime,level,tags, >>> #2: gc.log gc=trace, uptime,level,tags, >>> ------- >>> >>> Configuration string and decorators are ended with comma. >>> We should remove it as below: >>> ------- >>> Log output configuration: >>> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >>> #1: stderr all=warning uptime,level,tags >>> #2: gc.log gc=trace uptime,level,tags >>> ------- >>> >>> >>> I uploaded webrev for this issue. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ >> >> Please see >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >> >> for the configuration string issue. It was sent out earlier today. >> >> Your suggested fix for the decorator listing is broken. The for loop you >> modified iterates over all possible decorators, not all enabled >> decorators. So unless you have the last possible decorator enabled you >> will still get a trailing comma. >> >> Also, please note that UL belongs to the serviceability subcomponent, >> and patches like this should probably go to the serviceability-dev >> mailing list. >> >> Thanks, >> Marcus >> >>> >>> >>> I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Apr 25 12:54:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 21:54:24 +0900 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: <571E1146.2020204@oracle.com> References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> <571E1146.2020204@oracle.com> Message-ID: <88bc78b4-8b3d-c01f-6486-e5e39fbf7dd0@gmail.com> Thanks Dmitry, If this change is accepted, I will fix as below: --------- char delimiter = 0; for (...) { printf("%c%s", delimiter, LogDecorators::name(decorator)); delimiter = ','; } --------- Thanks, Yasumasa On 2016/04/25 21:44, Dmitry Samersoff wrote: > Yasumasa, > > It might be better to deal with first comma as: > > char delimiter[2] = {0,0}; > > for (...) { > printf("%s%s", delimiter, LogDecorators::name(decorator)); > *delimiter = ','; > } > > -Dmitry > > On 2016-04-25 15:19, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>> Please see >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>> >>> for the configuration string issue. It was sent out earlier today. >> >> Did you fix for trailing comma from decoration list? >> Comma for decoration exists yet in result of VM.log list jcmd. >> >>> Your suggested fix for the decorator listing is broken. The for loop you >>> modified iterates over all possible decorators, not all enabled >>> decorators. So unless you have the last possible decorator enabled you >>> will still get a trailing comma. >> >> I think we can fix as below. >> Should I file it to JBS as new issue? >> ------------------- >> diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp >> --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 2016 >> +0200 >> +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 2016 >> +0900 >> @@ -408,10 +408,13 @@ >> out->print_cr("Log output configuration:"); >> for (size_t i = 0; i < _n_outputs; i++) { >> out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), >> _outputs[i]->config_string()); >> + bool first_decorator = true; > >> for (size_t d = 0; d < LogDecorators::Count; d++) { >> LogDecorators::Decorator decorator = >> static_cast(d); >> if (_outputs[i]->decorators().is_decorator(decorator)) { >> - out->print("%s,", LogDecorators::name(decorator)); >> + out->print("%s%s", first_decorator ? "" : ",", >> + LogDecorators::name(decorator)); >> + first_decorator = false; >> } >> } >> out->cr(); >> ------------------- >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/31 22:11, Marcus Larsson wrote: >>> Hi, >>> >>> On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> We can check log configuration through VM.log list jcmd: >>>> ------- >>>> Log output configuration: >>>> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >>>> #1: stderr all=warning uptime,level,tags, >>>> #2: gc.log gc=trace, uptime,level,tags, >>>> ------- >>>> >>>> Configuration string and decorators are ended with comma. >>>> We should remove it as below: >>>> ------- >>>> Log output configuration: >>>> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >>>> #1: stderr all=warning uptime,level,tags >>>> #2: gc.log gc=trace uptime,level,tags >>>> ------- >>>> >>>> >>>> I uploaded webrev for this issue. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ >>> >>> Please see >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>> >>> for the configuration string issue. It was sent out earlier today. >>> >>> Your suggested fix for the decorator listing is broken. The for loop you >>> modified iterates over all possible decorators, not all enabled >>> decorators. So unless you have the last possible decorator enabled you >>> will still get a trailing comma. >>> >>> Also, please note that UL belongs to the serviceability subcomponent, >>> and patches like this should probably go to the serviceability-dev >>> mailing list. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> >>>> I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>> > > From yasuenag at gmail.com Mon Apr 25 14:06:05 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 23:06:05 +0900 Subject: jhsdb jmap cannot set heapdump name Message-ID: Hi all, We cannot change heapdump name (heap.bin) when we genarate heapdump via jhsdb. I want to set it like a jmap. I think we can change SALauncher and JMap. For example, in SALauncher side, I think we can add --dumpfile option as below: ---------------------- diff -r 3d289e4ba366 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java Fri Apr 22 19:40:39 2016 +0200 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java Mon Apr 25 22:48:03 2016 +0900 @@ -73,6 +73,7 @@ System.out.println(" \tto print same info as Solaris pmap"); System.out.println(" --heap\tto print java heap summary"); System.out.println(" --binaryheap\tto dump java heap in hprof binary format"); + System.out.println(" --dumpfile\tname of the dump file"); System.out.println(" --histo\tto print histogram of java object heap"); System.out.println(" --clstats\tto print class loader statistics"); System.out.println(" --finalizerinfo\tto print information on objects awaiting finalization"); @@ -241,13 +242,15 @@ private static void runJMAP(String[] oldArgs) { SAGetopt sg = new SAGetopt(oldArgs); String[] longOpts = {"exe=", "core=", "pid=", - "heap", "binaryheap", "histo", "clstats", "finalizerinfo"}; + "heap", "binaryheap", "dumpfile=", "histo", "clstats", "finalizerinfo"}; ArrayList newArgs = new ArrayList(); String pid = null; String exe = null; String core = null; String s = null; + String dumpfile = null; + boolean requestHeapdump = false; while((s = sg.next(null, longOpts)) != null) { if (s.equals("exe")) { @@ -267,7 +270,11 @@ continue; } if (s.equals("binaryheap")) { - newArgs.add("-heap:format=b"); + requestHeapdump = true; + continue; + } + if (s.equals("dumpfile")) { + dumpfile = sg.getOptarg(); continue; } if (s.equals("histo")) { @@ -284,6 +291,16 @@ } } + if (requestHeapdump) { + if (dumpfile == null) { + newArgs.add("-heap:format=b"); + } else { + newArgs.add("-heap:format=b,file=" + dumpfile); + } + } else if (dumpfile != null) { + throw new IllegalArgumentException("dumpfile does not need."); + } + buildAttachArgs(newArgs, pid, exe, core, false); JMap.main(newArgs.toArray(new String[newArgs.size()])); } ---------------------- What do you think about it? If it is accepted, I will file it to JBS and send review request. Thanks, Yasumasa From serguei.spitsyn at oracle.com Mon Apr 25 21:06:52 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 25 Apr 2016 14:06:52 -0700 Subject: RFR(S): JDK-8155009 jstack subtest of BasicLauncherTest should not be executed under OS X In-Reply-To: <571E034A.6070002@oracle.com> References: <571E034A.6070002@oracle.com> Message-ID: <571E86EC.60107@oracle.com> Dmitry, Looks good. Thanks, Serguei On 4/25/16 04:45, Dmitry Samersoff wrote: > Everybody, > > Please review the test changes. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155009/webrev.01/ > > Coredump stackwalking is not implemented on OS X so skip corresponding test. > > -Dmitry > > From staffan.larsen at oracle.com Tue Apr 26 08:18:25 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Apr 2016 10:18:25 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 20 apr. 2016, at 13:47, Robbin Ehn wrote: > > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 26 08:19:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 26 Apr 2016 10:19:35 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: References: <57176C38.3000109@oracle.com> Message-ID: Thanks Staffan! /Robbin On 04/26/2016 10:18 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 20 apr. 2016, at 13:47, Robbin Ehn wrote: >> >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From marcus.larsson at oracle.com Tue Apr 26 08:35:41 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 26 Apr 2016 10:35:41 +0200 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> Message-ID: <571F285D.9040501@oracle.com> Hi, On 2016-04-25 14:19, Yasumasa Suenaga wrote: > Hi Marcus, > >> Please see >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >> >> for the configuration string issue. It was sent out earlier today. > > Did you fix for trailing comma from decoration list? > Comma for decoration exists yet in result of VM.log list jcmd. No, removing the trailing comma after decorators was not part of that fix. > >> Your suggested fix for the decorator listing is broken. The for loop you >> modified iterates over all possible decorators, not all enabled >> decorators. So unless you have the last possible decorator enabled you >> will still get a trailing comma. > > I think we can fix as below. > Should I file it to JBS as new issue? Sounds good to me. Thanks, Marcus > ------------------- > diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp > --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 > 2016 +0200 > +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 > 2016 +0900 > @@ -408,10 +408,13 @@ > out->print_cr("Log output configuration:"); > for (size_t i = 0; i < _n_outputs; i++) { > out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), > _outputs[i]->config_string()); > + bool first_decorator = true; > for (size_t d = 0; d < LogDecorators::Count; d++) { > LogDecorators::Decorator decorator = > static_cast(d); > if (_outputs[i]->decorators().is_decorator(decorator)) { > - out->print("%s,", LogDecorators::name(decorator)); > + out->print("%s%s", first_decorator ? "" : ",", > + LogDecorators::name(decorator)); > + first_decorator = false; > } > } > out->cr(); > ------------------- > > > Thanks, > > Yasumasa > > > On 2016/03/31 22:11, Marcus Larsson wrote: >> Hi, >> >> On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> We can check log configuration through VM.log list jcmd: >>> ------- >>> Log output configuration: >>> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >>> #1: stderr all=warning uptime,level,tags, >>> #2: gc.log gc=trace, uptime,level,tags, >>> ------- >>> >>> Configuration string and decorators are ended with comma. >>> We should remove it as below: >>> ------- >>> Log output configuration: >>> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >>> #1: stderr all=warning uptime,level,tags >>> #2: gc.log gc=trace uptime,level,tags >>> ------- >>> >>> >>> I uploaded webrev for this issue. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ >> >> Please see >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >> >> for the configuration string issue. It was sent out earlier today. >> >> Your suggested fix for the decorator listing is broken. The for loop you >> modified iterates over all possible decorators, not all enabled >> decorators. So unless you have the last possible decorator enabled you >> will still get a trailing comma. >> >> Also, please note that UL belongs to the serviceability subcomponent, >> and patches like this should probably go to the serviceability-dev >> mailing list. >> >> Thanks, >> Marcus >> >>> >>> >>> I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >> From marcus.larsson at oracle.com Tue Apr 26 08:39:13 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 26 Apr 2016 10:39:13 +0200 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: <88bc78b4-8b3d-c01f-6486-e5e39fbf7dd0@gmail.com> References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> <571E1146.2020204@oracle.com> <88bc78b4-8b3d-c01f-6486-e5e39fbf7dd0@gmail.com> Message-ID: <571F2931.3050106@oracle.com> On 2016-04-25 14:54, Yasumasa Suenaga wrote: > Thanks Dmitry, > > If this change is accepted, I will fix as below: > --------- > char delimiter = 0; > > for (...) { > printf("%c%s", delimiter, LogDecorators::name(decorator)); > delimiter = ','; > } > --------- If you make it a char then the string would be null terminated right in the beginning. Marcus > > > Thanks, > > Yasumasa > > > On 2016/04/25 21:44, Dmitry Samersoff wrote: >> Yasumasa, >> >> It might be better to deal with first comma as: >> >> char delimiter[2] = {0,0}; >> >> for (...) { >> printf("%s%s", delimiter, LogDecorators::name(decorator)); >> *delimiter = ','; >> } >> >> -Dmitry >> >> On 2016-04-25 15:19, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>> Please see >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>>> >>>> >>>> for the configuration string issue. It was sent out earlier today. >>> >>> Did you fix for trailing comma from decoration list? >>> Comma for decoration exists yet in result of VM.log list jcmd. >>> >>>> Your suggested fix for the decorator listing is broken. The for >>>> loop you >>>> modified iterates over all possible decorators, not all enabled >>>> decorators. So unless you have the last possible decorator enabled you >>>> will still get a trailing comma. >>> >>> I think we can fix as below. >>> Should I file it to JBS as new issue? >>> ------------------- >>> diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp >>> --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 >>> 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 >>> 2016 >>> +0900 >>> @@ -408,10 +408,13 @@ >>> out->print_cr("Log output configuration:"); >>> for (size_t i = 0; i < _n_outputs; i++) { >>> out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), >>> _outputs[i]->config_string()); >>> + bool first_decorator = true; >> >>> for (size_t d = 0; d < LogDecorators::Count; d++) { >>> LogDecorators::Decorator decorator = >>> static_cast(d); >>> if (_outputs[i]->decorators().is_decorator(decorator)) { >>> - out->print("%s,", LogDecorators::name(decorator)); >>> + out->print("%s%s", first_decorator ? "" : ",", >>> + LogDecorators::name(decorator)); >>> + first_decorator = false; >>> } >>> } >>> out->cr(); >>> ------------------- >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/31 22:11, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> We can check log configuration through VM.log list jcmd: >>>>> ------- >>>>> Log output configuration: >>>>> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >>>>> #1: stderr all=warning uptime,level,tags, >>>>> #2: gc.log gc=trace, uptime,level,tags, >>>>> ------- >>>>> >>>>> Configuration string and decorators are ended with comma. >>>>> We should remove it as below: >>>>> ------- >>>>> Log output configuration: >>>>> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >>>>> #1: stderr all=warning uptime,level,tags >>>>> #2: gc.log gc=trace uptime,level,tags >>>>> ------- >>>>> >>>>> >>>>> I uploaded webrev for this issue. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ >>>> >>>> Please see >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>>> >>>> >>>> for the configuration string issue. It was sent out earlier today. >>>> >>>> Your suggested fix for the decorator listing is broken. The for >>>> loop you >>>> modified iterates over all possible decorators, not all enabled >>>> decorators. So unless you have the last possible decorator enabled you >>>> will still get a trailing comma. >>>> >>>> Also, please note that UL belongs to the serviceability subcomponent, >>>> and patches like this should probably go to the serviceability-dev >>>> mailing list. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>> >> >> From serguei.spitsyn at oracle.com Tue Apr 26 08:48:40 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Apr 2016 01:48:40 -0700 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: <571F2B68.90803@oracle.com> Hi Robin, Looks good. Thanks, Serguei On 4/20/16 04:47, Robbin Ehn wrote: > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, > this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists > as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 26 08:49:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 26 Apr 2016 10:49:35 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <571F2B68.90803@oracle.com> References: <57176C38.3000109@oracle.com> <571F2B68.90803@oracle.com> Message-ID: <19009225-ff51-912d-ed98-3a86ddb7bfbb@oracle.com> Hi Serguei, Thanks! /Robbin On 04/26/2016 10:48 AM, serguei.spitsyn at oracle.com wrote: > Hi Robin, > > Looks good. > > Thanks, > Serguei > > > On 4/20/16 04:47, Robbin Ehn wrote: >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, >> this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists >> as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From sgehwolf at redhat.com Tue Apr 26 08:58:10 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Apr 2016 10:58:10 +0200 Subject: RFR(s) 8154529: some places in the invoke.c that use InvokeRequest* not protected with invokerLock Message-ID: <1461661090.3372.11.camel@redhat.com> Hi, Could somebody please review this patch for JDK-8154529. Some methods modifying values pointed to by the InvokeRequest pointer aren't holding the invokerLock. This can lead to some races. For example between invoker_doInvoke() and?threadControl_popFrames(). Perhaps?com/sun/jdi/PopAndInvokeTest.java can be enabled (un-ignored) these days? There was also one instance of dead code: invoker_isPending() isn't used anywhere. Bug:?https://bugs.openjdk.java.net/browse/JDK-8154529 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8154529/webrev.01/ Testing done: - com/sun/jdi test set. No regressions. - I've also run the following invoke tests 1500 times with no failures: com/sun/jdi/InterfaceMethodsTest.java com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java Thoughts? Once reviewed, I'd need somebody to sponsor this patch for me. Thanks, Severin From yasuenag at gmail.com Tue Apr 26 09:27:30 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 18:27:30 +0900 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: <571F2931.3050106@oracle.com> References: <56FD1D15.2060703@gmail.com> <56FD220A.2090600@oracle.com> <571E1146.2020204@oracle.com> <88bc78b4-8b3d-c01f-6486-e5e39fbf7dd0@gmail.com> <571F2931.3050106@oracle.com> Message-ID: <951bae53-6f6c-ab0d-602d-2aadc067fcf4@gmail.com> Hi Marcus, > If you make it a char then the string would be null terminated right in the beginning. Oh, thanks! I will merge Dmitry's suggestion in this change request. Thanks, Yasumasa On 2016/04/26 17:39, Marcus Larsson wrote: > > > On 2016-04-25 14:54, Yasumasa Suenaga wrote: >> Thanks Dmitry, >> >> If this change is accepted, I will fix as below: >> --------- >> char delimiter = 0; >> >> for (...) { >> printf("%c%s", delimiter, LogDecorators::name(decorator)); >> delimiter = ','; >> } >> --------- > > If you make it a char then the string would be null terminated right in the beginning. > > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/25 21:44, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> It might be better to deal with first comma as: >>> >>> char delimiter[2] = {0,0}; >>> >>> for (...) { >>> printf("%s%s", delimiter, LogDecorators::name(decorator)); >>> *delimiter = ','; >>> } >>> >>> -Dmitry >>> >>> On 2016-04-25 15:19, Yasumasa Suenaga wrote: >>>> Hi Marcus, >>>> >>>>> Please see >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>>>> >>>>> for the configuration string issue. It was sent out earlier today. >>>> >>>> Did you fix for trailing comma from decoration list? >>>> Comma for decoration exists yet in result of VM.log list jcmd. >>>> >>>>> Your suggested fix for the decorator listing is broken. The for loop you >>>>> modified iterates over all possible decorators, not all enabled >>>>> decorators. So unless you have the last possible decorator enabled you >>>>> will still get a trailing comma. >>>> >>>> I think we can fix as below. >>>> Should I file it to JBS as new issue? >>>> ------------------- >>>> diff -r 3d289e4ba366 src/share/vm/logging/logConfiguration.cpp >>>> --- a/src/share/vm/logging/logConfiguration.cpp Fri Apr 22 19:40:39 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logConfiguration.cpp Mon Apr 25 21:14:49 2016 >>>> +0900 >>>> @@ -408,10 +408,13 @@ >>>> out->print_cr("Log output configuration:"); >>>> for (size_t i = 0; i < _n_outputs; i++) { >>>> out->print("#" SIZE_FORMAT ": %s %s ", i, _outputs[i]->name(), >>>> _outputs[i]->config_string()); >>>> + bool first_decorator = true; >>> >>>> for (size_t d = 0; d < LogDecorators::Count; d++) { >>>> LogDecorators::Decorator decorator = >>>> static_cast(d); >>>> if (_outputs[i]->decorators().is_decorator(decorator)) { >>>> - out->print("%s,", LogDecorators::name(decorator)); >>>> + out->print("%s%s", first_decorator ? "" : ",", >>>> + LogDecorators::name(decorator)); >>>> + first_decorator = false; >>>> } >>>> } >>>> out->cr(); >>>> ------------------- >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 22:11, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 03/31/2016 02:50 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> We can check log configuration through VM.log list jcmd: >>>>>> ------- >>>>>> Log output configuration: >>>>>> #0: stdout vmoperation=debug,safepoint=info, uptime,level,tags, >>>>>> #1: stderr all=warning uptime,level,tags, >>>>>> #2: gc.log gc=trace, uptime,level,tags, >>>>>> ------- >>>>>> >>>>>> Configuration string and decorators are ended with comma. >>>>>> We should remove it as below: >>>>>> ------- >>>>>> Log output configuration: >>>>>> #0: stdout vmoperation=debug,safepoint=info uptime,level,tags >>>>>> #1: stderr all=warning uptime,level,tags >>>>>> #2: gc.log gc=trace uptime,level,tags >>>>>> ------- >>>>>> >>>>>> >>>>>> I uploaded webrev for this issue. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153191/webrev.00/ >>>>> >>>>> Please see >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019237.html >>>>> >>>>> for the configuration string issue. It was sent out earlier today. >>>>> >>>>> Your suggested fix for the decorator listing is broken. The for loop you >>>>> modified iterates over all possible decorators, not all enabled >>>>> decorators. So unless you have the last possible decorator enabled you >>>>> will still get a trailing comma. >>>>> >>>>> Also, please note that UL belongs to the serviceability subcomponent, >>>>> and patches like this should probably go to the serviceability-dev >>>>> mailing list. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> >>>>>> I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>> >>> >>> > From serguei.spitsyn at oracle.com Tue Apr 26 09:35:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Apr 2016 02:35:35 -0700 Subject: RFR(s) 8154529: some places in the invoke.c that use InvokeRequest* not protected with invokerLock In-Reply-To: <1461661090.3372.11.camel@redhat.com> References: <1461661090.3372.11.camel@redhat.com> Message-ID: <571F3667.5070005@oracle.com> Hi Severin, It looks good. Thank you for taking care. I can sponsor the fix after it is reviewed. Thanks, Serguei On 4/26/16 01:58, Severin Gehwolf wrote: > Hi, > > Could somebody please review this patch for JDK-8154529. Some methods > modifying values pointed to by the InvokeRequest pointer aren't holding > the invokerLock. This can lead to some races. For example between > invoker_doInvoke() and threadControl_popFrames(). > > Perhaps com/sun/jdi/PopAndInvokeTest.java can be enabled (un-ignored) > these days? > > There was also one instance of dead code: invoker_isPending() isn't > used anywhere. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154529 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8154529/webrev.01/ > > Testing done: > - com/sun/jdi test set. No regressions. > - I've also run the following invoke tests 1500 times with no failures: > com/sun/jdi/InterfaceMethodsTest.java > com/sun/jdi/InvokeTest.java > com/sun/jdi/InvokeHangTest.java > > Thoughts? Once reviewed, I'd need somebody to sponsor this patch for > me. > > Thanks, > Severin From alexander.kulyakhtin at oracle.com Tue Apr 26 09:36:41 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 26 Apr 2016 02:36:41 -0700 (PDT) Subject: RFR:8153992 (re-review, missed one file) : Some hotspot tests fail on compact2 due to an unnecessary test library dependency Message-ID: <7cf575b1-4a30-49b9-a7f9-1a892754785f@default> Hi, I've missed one file in the changeset reviewed before, therefore the push failed and I have to ask for a quick re-review. The missing change is here: http://cr.openjdk.java.net/~akulyakh/8153992_02/test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java.udiff.html I've verified that all the hotspot tests have passed with that change. The full changeset (reviewed before): CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02 Best regards, Alexander ----- Forwarded Message ----- From: mandy.chung at oracle.com To: alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com Cc: hotspot-dev at openjdk.java.net Sent: Thursday, April 21, 2016 8:48:23 PM GMT +03:00 Iraq Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency The patch looks fine to me. Due to ProcessTools.getVmInputArguments() dependency, any test using ProcessTools has @modules java.management even it does not use this method. It?d be good to refactor ProcessTools.getVmInputArguments() and maybe other test library to eliminate unnecessary dependency. Shura has cleaned up jdk/test/lib/testlibrary in the jdk side: https://bugs.openjdk.java.net/browse/JDK-8139430 Can you file a separate issue to refactor the hotspot test library and similar fix to JDK-8139430 can be applied in the future? thanks Mandy > On Apr 21, 2016, at 5:23 AM, Alexander Kulyakhtin wrote: > > Mandy, > > Thank you very much for your review. > > I have updated the fix per your comments, making ProcessTools.getProcessId() return long. > > The function ProcessTools.getVmInputArguments(), although does depend on the API from the java.management, is not used by any of the tests addressed by the CR. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: hotspot-dev at openjdk.java.net > Cc: mandy.chung at oracle.com > Sent: Thursday, April 21, 2016 3:11:46 PM GMT +03:00 Iraq > Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency > > Hi, > > Could you, please, review this fix (updated to address the findings of the previous review) > > CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02/index.html > > Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. > The API is not available on compact2 and below. Therefore the tests failed. > We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. > > Since, with this change ProcessTools.getProcessId() now returns long we are also trivially modifying all the affected tests. > > Best regards, > Alexander > > > > ----- Original Message ----- > From: mandy.chung at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Thursday, April 21, 2016 12:03:14 AM GMT +03:00 Iraq > Subject: Re: RFR:8153989:Some SVC tests fail on compact2 due to an unnecessary test library dependency > > >> On Apr 20, 2016, at 9:06 AM, Alexander Kulyakhtin wrote: >> >> Hi, >> >> Could you, please, review this small tests-only fix: >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153992/test/testlibrary/jdk/test/lib/ProcessTools.java.udiff.html >> >> Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. >> The API is not available on compact2 and below. Therefore the tests failed. >> >> We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. >> > > This looks okay. But I see that getVmInputArguments calls ManagementFactory.getRuntimeMXBean. So ProcessTools still has a dependency on java.management. > > The jdk test library ProcessTools::getProcessId has been long ago to call Process::getPid and the method is changed to return long. I thought that similar change would have been made in the hotspot test library at that time. > >> I am not sure how acceptable it is to cast from long to int this change. If it is not acceptable we can change the return type to long. >> This however, will cause massive changes throughout the hotspot tests which presently expect getProcessId() to return int. > > IMO it would be good to return long or have the callsite to call ProcessHandle.current().getPid(). > > Mandy > From dmitry.samersoff at oracle.com Tue Apr 26 10:12:54 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Apr 2016 13:12:54 +0300 Subject: RFR:8153992 (re-review, missed one file) : Some hotspot tests fail on compact2 due to an unnecessary test library dependency In-Reply-To: <7cf575b1-4a30-49b9-a7f9-1a892754785f@default> References: <7cf575b1-4a30-49b9-a7f9-1a892754785f@default> Message-ID: <571F3F26.7020606@oracle.com> Alexander, Looks good for me! -Dmitry On 2016-04-26 12:36, Alexander Kulyakhtin wrote: > Hi, > > I've missed one file in the changeset reviewed before, therefore the push failed and I have to ask for a quick re-review. > > The missing change is here: http://cr.openjdk.java.net/~akulyakh/8153992_02/test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java.udiff.html > > I've verified that all the hotspot tests have passed with that change. > > The full changeset (reviewed before): > > CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02 > > Best regards, > Alexander > > ----- Forwarded Message ----- > From: mandy.chung at oracle.com > To: alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Cc: hotspot-dev at openjdk.java.net > Sent: Thursday, April 21, 2016 8:48:23 PM GMT +03:00 Iraq > Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency > > The patch looks fine to me. > > Due to ProcessTools.getVmInputArguments() dependency, any test using ProcessTools has @modules java.management even it does not use this method. > > It?d be good to refactor ProcessTools.getVmInputArguments() and maybe other test library to eliminate unnecessary dependency. Shura has cleaned up jdk/test/lib/testlibrary in the jdk side: > https://bugs.openjdk.java.net/browse/JDK-8139430 > > Can you file a separate issue to refactor the hotspot test library and similar fix to JDK-8139430 can be applied in the future? > > thanks > Mandy > >> On Apr 21, 2016, at 5:23 AM, Alexander Kulyakhtin wrote: >> >> Mandy, >> >> Thank you very much for your review. >> >> I have updated the fix per your comments, making ProcessTools.getProcessId() return long. >> >> The function ProcessTools.getVmInputArguments(), although does depend on the API from the java.management, is not used by any of the tests addressed by the CR. >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From: alexander.kulyakhtin at oracle.com >> To: hotspot-dev at openjdk.java.net >> Cc: mandy.chung at oracle.com >> Sent: Thursday, April 21, 2016 3:11:46 PM GMT +03:00 Iraq >> Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency >> >> Hi, >> >> Could you, please, review this fix (updated to address the findings of the previous review) >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02/index.html >> >> Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. >> The API is not available on compact2 and below. Therefore the tests failed. >> We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. >> >> Since, with this change ProcessTools.getProcessId() now returns long we are also trivially modifying all the affected tests. >> >> Best regards, >> Alexander >> >> >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net >> Sent: Thursday, April 21, 2016 12:03:14 AM GMT +03:00 Iraq >> Subject: Re: RFR:8153989:Some SVC tests fail on compact2 due to an unnecessary test library dependency >> >> >>> On Apr 20, 2016, at 9:06 AM, Alexander Kulyakhtin wrote: >>> >>> Hi, >>> >>> Could you, please, review this small tests-only fix: >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" >>> Webrev: http://cr.openjdk.java.net/~akulyakh/8153992/test/testlibrary/jdk/test/lib/ProcessTools.java.udiff.html >>> >>> Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. >>> The API is not available on compact2 and below. Therefore the tests failed. >>> >>> We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. >>> >> >> This looks okay. But I see that getVmInputArguments calls ManagementFactory.getRuntimeMXBean. So ProcessTools still has a dependency on java.management. >> >> The jdk test library ProcessTools::getProcessId has been long ago to call Process::getPid and the method is changed to return long. I thought that similar change would have been made in the hotspot test library at that time. >> >>> I am not sure how acceptable it is to cast from long to int this change. If it is not acceptable we can change the return type to long. >>> This however, will cause massive changes throughout the hotspot tests which presently expect getProcessId() to return int. >> >> IMO it would be good to return long or have the callsite to call ProcessHandle.current().getPid(). >> >> Mandy >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Tue Apr 26 10:17:56 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 26 Apr 2016 03:17:56 -0700 (PDT) Subject: RFR:8153992 (re-review, missed one file) : Some hotspot tests fail on compact2 due to an unnecessary test library dependency Message-ID: <319dc8fc-58a6-440a-b3e5-caed9b4681df@default> Dmitry, Thank you very much for the review. Best regards, Alexander ----- Original Message ----- From: dmitry.samersoff at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Tuesday, April 26, 2016 1:12:56 PM GMT +03:00 Iraq Subject: Re: RFR:8153992 (re-review, missed one file) : Some hotspot tests fail on compact2 due to an unnecessary test library dependency Alexander, Looks good for me! -Dmitry On 2016-04-26 12:36, Alexander Kulyakhtin wrote: > Hi, > > I've missed one file in the changeset reviewed before, therefore the push failed and I have to ask for a quick re-review. > > The missing change is here: http://cr.openjdk.java.net/~akulyakh/8153992_02/test/testlibrary/jdk/test/lib/dcmd/FileJcmdExecutor.java.udiff.html > > I've verified that all the hotspot tests have passed with that change. > > The full changeset (reviewed before): > > CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02 > > Best regards, > Alexander > > ----- Forwarded Message ----- > From: mandy.chung at oracle.com > To: alexander.kulyakhtin at oracle.com, alexandre.iline at oracle.com > Cc: hotspot-dev at openjdk.java.net > Sent: Thursday, April 21, 2016 8:48:23 PM GMT +03:00 Iraq > Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency > > The patch looks fine to me. > > Due to ProcessTools.getVmInputArguments() dependency, any test using ProcessTools has @modules java.management even it does not use this method. > > It?d be good to refactor ProcessTools.getVmInputArguments() and maybe other test library to eliminate unnecessary dependency. Shura has cleaned up jdk/test/lib/testlibrary in the jdk side: > https://bugs.openjdk.java.net/browse/JDK-8139430 > > Can you file a separate issue to refactor the hotspot test library and similar fix to JDK-8139430 can be applied in the future? > > thanks > Mandy > >> On Apr 21, 2016, at 5:23 AM, Alexander Kulyakhtin wrote: >> >> Mandy, >> >> Thank you very much for your review. >> >> I have updated the fix per your comments, making ProcessTools.getProcessId() return long. >> >> The function ProcessTools.getVmInputArguments(), although does depend on the API from the java.management, is not used by any of the tests addressed by the CR. >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From: alexander.kulyakhtin at oracle.com >> To: hotspot-dev at openjdk.java.net >> Cc: mandy.chung at oracle.com >> Sent: Thursday, April 21, 2016 3:11:46 PM GMT +03:00 Iraq >> Subject: Re: RFR:8153992:Some hotspot tests fail on compact2 due to an unnecessary test library dependency >> >> Hi, >> >> Could you, please, review this fix (updated to address the findings of the previous review) >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153992_02/index.html >> >> Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. >> The API is not available on compact2 and below. Therefore the tests failed. >> We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. >> >> Since, with this change ProcessTools.getProcessId() now returns long we are also trivially modifying all the affected tests. >> >> Best regards, >> Alexander >> >> >> >> ----- Original Message ----- >> From: mandy.chung at oracle.com >> To: alexander.kulyakhtin at oracle.com >> Cc: serviceability-dev at openjdk.java.net >> Sent: Thursday, April 21, 2016 12:03:14 AM GMT +03:00 Iraq >> Subject: Re: RFR:8153989:Some SVC tests fail on compact2 due to an unnecessary test library dependency >> >> >>> On Apr 20, 2016, at 9:06 AM, Alexander Kulyakhtin wrote: >>> >>> Hi, >>> >>> Could you, please, review this small tests-only fix: >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8153992 "Some SVC tests fail on compact2 due to an unnecessary test library dependency" >>> Webrev: http://cr.openjdk.java.net/~akulyakh/8153992/test/testlibrary/jdk/test/lib/ProcessTools.java.udiff.html >>> >>> Before the fix the ProcessTools.getProcessId() used the ManagementFactory.getRuntimeMXBean() API. >>> The API is not available on compact2 and below. Therefore the tests failed. >>> >>> We are changing the ProcessTools.getProcessId() method to use the JDK 9 Process.getPid(). This eliminates the unnecessary dependency making the tests pass on compact2. >>> >> >> This looks okay. But I see that getVmInputArguments calls ManagementFactory.getRuntimeMXBean. So ProcessTools still has a dependency on java.management. >> >> The jdk test library ProcessTools::getProcessId has been long ago to call Process::getPid and the method is changed to return long. I thought that similar change would have been made in the hotspot test library at that time. >> >>> I am not sure how acceptable it is to cast from long to int this change. If it is not acceptable we can change the return type to long. >>> This however, will cause massive changes throughout the hotspot tests which presently expect getProcessId() to return int. >> >> IMO it would be good to return long or have the callsite to call ProcessHandle.current().getPid(). >> >> Mandy >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From j.bachorik at gmail.com Tue Apr 26 10:35:40 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Tue, 26 Apr 2016 12:35:40 +0200 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: <571DC6F3.2090502@oracle.com> References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> Message-ID: On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B < harsha.wardhana.b at oracle.com> wrote: > Hi, > > Please review below patch to disable concurrent GC option. > http://cr.openjdk.java.net/~hb/8154166/webrev.01/ > I'm sorry to be a PITA, but why it is not possible to use the @require tag? > > > Jaroslav, > > According to Javadoc of Runtime.gc(), > > > https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- > > The call will only make it's best effort to do a GC and provides no > guarantee that a given object can be collected even if GC runs. > It does not say that Runtime.gc() call will block till entire GC cycle is > finished and hence we cannot be making that assumption. > I know, I had the same discussion a while ago when fixing some other tests failing when run with allowed concurrent explicit GC and I was pointed to the fact that all the known implementation actually do wait until the complete GC cycle is over before returning. Otherwise all those tests relying on some memory having been reclaimed or some counters having been increased would have to be considered random. > > Hence it is required that we encapsulate the target object in > WeakReference and repeatedly call GC till weakRef returns null. > Granted that we will have a small window when weakRef returns null and the > target object is not removed from memory. But I see no way how to fix that > problem. > Exactly. The only guarantee for all the GC related metrics having been updated before proceeding with the test is being able to run the explicit GC in blocking manner. Otherwise the tests are not really deterministic and can intermittently fail. -JB- > > -Harsha > > > On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: > > The reproducer would be very time sensitive as with the provided > 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the invoker. > Otherwise, in the current implementation, calling Runtime.gc() would > guarantee the GC cycle has finished before that method returns. > > The WeakReference javadoc ( > https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) > is only stating that the referenced object will be made finalizable at the > same time as the reference is cleared. As a consequence a cleared reference > might not always mean that the heap usage has been changed (unless a > particular GC implementation makes some additional guarantees). > > I know we were stabilizing a bunch of related tests relying on GC doing > its work before checking for some post-conditions and the only way to make > the tests reliable was to forbid running those tests with > '-XX:+ExplicitGCInvokesConcurrent'. > > -JB- > > On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B < > harsha.wardhana.b at oracle.com> wrote: > >> Hello, >> >> The issue was not reproducible with or without, >> >> "-XX:+ExplicitGCInvokesConcurrent" >> >> Flag. The patch ensures that GC happens before we start measuring memory. >> Without the patch, GC might or might not happen. >> >> -Harsha >> >> >> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >> >> Hi, >> >> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < >> harsha.wardhana.b at oracle.com> wrote: >> >>> Hi, >>> >>> Please review the below simple fix for issue, >>> >>> issue : https://bugs.openjdk.java.net/browse/JDK-8154166 >>> webrev : http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>> >> >> Shouldn't this test rather declare the conditions when it is supposed to >> work? According to the issue this was caused by introducing the "-XX:+ExplicitGCInvokesConcurrent" >> which makes it very tricky to make any assumptions about the GC process. >> >> See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >> for enabling the test only for allowed configurations. >> >> Cheers, >> >> -JB- >> >> >>> >>> >>> -Harsha >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Tue Apr 26 11:22:39 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Apr 2016 13:22:39 +0200 Subject: RFR(s) 8154529: some places in the invoke.c that use InvokeRequest* not protected with invokerLock In-Reply-To: <571F3667.5070005@oracle.com> References: <1461661090.3372.11.camel@redhat.com> <571F3667.5070005@oracle.com> Message-ID: <1461669759.3372.26.camel@redhat.com> Hi Serguei, On Tue, 2016-04-26 at 02:35 -0700, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > It looks good. > Thank you for taking care. > I can sponsor the fix after it is reviewed. Thanks for the review! The hg exported changeset is here: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8154529/JDK-8154529-jdk9-jdk.export.patch Cheers, Severin > Thanks, > Serguei > > > On 4/26/16 01:58, Severin Gehwolf wrote: > > > > Hi, > > > > Could somebody please review this patch for JDK-8154529. Some > > methods > > modifying values pointed to by the InvokeRequest pointer aren't > > holding > > the invokerLock. This can lead to some races. For example between > > invoker_doInvoke() and threadControl_popFrames(). > > > > Perhaps com/sun/jdi/PopAndInvokeTest.java can be enabled (un- > > ignored) > > these days? > > > > There was also one instance of dead code: invoker_isPending() isn't > > used anywhere. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154529 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8154529/we > > brev.01/ > > > > Testing done: > > ? - com/sun/jdi test set. No regressions. > > ? - I've also run the following invoke tests 1500 times with no > > failures: > > ????com/sun/jdi/InterfaceMethodsTest.java > > ????com/sun/jdi/InvokeTest.java > > ????com/sun/jdi/InvokeHangTest.java > > > > Thoughts? Once reviewed, I'd need somebody to sponsor this patch > > for > > me. > > > > Thanks, > > Severin From yasuenag at gmail.com Tue Apr 26 13:08:51 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 22:08:51 +0900 Subject: RFR: JDK-8155089: UL: Remove trailing comma from log decoration list Message-ID: <4a31f5fd-1e80-6b95-2ea9-de0da0a2feae@gmail.com> Hi all, This review request relates [1]. We can check log configuration through VM.log list jcmd: ------- Log output configuration: #0: stdout vmoperation=debug,safepoint=info uptime,level,tags, #1: stderr all=warning uptime,level,tags, #2: gc.log gc=trace uptime,level,tags, ------- Decorators are ended with comma. We should remove it as below: ------- Log output configuration: #0: stdout vmoperation=debug,safepoint=info uptime,level,tags #1: stderr all=warning uptime,level,tags #2: gc.log gc=trace uptime,level,tags ------- I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8155089/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019506.html From dmitry.samersoff at oracle.com Tue Apr 26 13:50:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 26 Apr 2016 16:50:19 +0300 Subject: RFR: JDK-8155089: UL: Remove trailing comma from log decoration list In-Reply-To: <4a31f5fd-1e80-6b95-2ea9-de0da0a2feae@gmail.com> References: <4a31f5fd-1e80-6b95-2ea9-de0da0a2feae@gmail.com> Message-ID: <571F721B.9090809@oracle.com> Yasumasa, Looks good for me. -Dmitry On 2016-04-26 16:08, Yasumasa Suenaga wrote: > Hi all, > > This review request relates [1]. > > We can check log configuration through VM.log list jcmd: > ------- > Log output configuration: > #0: stdout vmoperation=debug,safepoint=info uptime,level,tags, > #1: stderr all=warning uptime,level,tags, > #2: gc.log gc=trace uptime,level,tags, > ------- > > Decorators are ended with comma. > We should remove it as below: > ------- > Log output configuration: > #0: stdout vmoperation=debug,safepoint=info uptime,level,tags > #1: stderr all=warning uptime,level,tags > #2: gc.log gc=trace uptime,level,tags > ------- > > I uploaded a webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8155089/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019506.html > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Tue Apr 26 18:56:11 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Apr 2016 19:56:11 +0100 Subject: RFR(L): JDK-8154258 [TESTBUG] Various serviceability tests fail compilation In-Reply-To: <571E0482.6050000@oracle.com> References: <5714CCCA.7030809@oracle.com> <571E0482.6050000@oracle.com> Message-ID: <80B4971C-0833-400F-BD63-B0D1F070D180@oracle.com> On 25 Apr 2016, at 12:50, Dmitry Samersoff wrote: > Everybody, > > Please review the changes. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8154258/webrev.04/ Thank you Dmitry. Your changes look good to me. As a follow up, it would be nice to refactor the current testlibrary so that the Unsafe dependency is put into its own testlibrary. I suspect that many of the @modules could then be removed from many tests that don?t actually depend on Unsafe. Anyway, that can some later. -Chris. > 1. Change hotspot/test/testlibrary/jdk/test/lib/Utils.java to match > /test/lib/share/classes/jdk/test/lib/Utils.java > i.e. replace sun.misc.Unsafe to jdk.internal.misc.Unsafe > > 2. Add the tag > @modules java.base/jdk.internal.misc > to all tests that uses testlibrary > > 3. Replace all occurrence of sun.misc.Unsafe to jdk.internal.misc.Unsafe > > Testing: local, RBT:hotspot_all > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Apr 27 03:53:51 2016 From: jini.george at oracle.com (Jini George) Date: Tue, 26 Apr 2016 20:53:51 -0700 (PDT) Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: Message-ID: <852083db-9e90-40b0-9f73-415580b1798e@default> Please hold off on this review (since I might have some modifications to the changes). Regds, Jini. From: Jini George Sent: Monday, April 25, 2016 2:29 PM To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Adding hotspot-runtime as well since this includes runtime changes. Regards, Jini. From: Jini George Sent: Monday, April 25, 2016 1:23 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: 1. Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) 2. Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT testsets: hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Wed Apr 27 06:11:10 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 27 Apr 2016 08:11:10 +0200 Subject: RFR: JDK-8155089: UL: Remove trailing comma from log decoration list In-Reply-To: <4a31f5fd-1e80-6b95-2ea9-de0da0a2feae@gmail.com> References: <4a31f5fd-1e80-6b95-2ea9-de0da0a2feae@gmail.com> Message-ID: Hi, On 04/26/2016 03:08 PM, Yasumasa Suenaga wrote: > Hi all, > > This review request relates [1]. > > We can check log configuration through VM.log list jcmd: > ------- > Log output configuration: > #0: stdout vmoperation=debug,safepoint=info uptime,level,tags, > #1: stderr all=warning uptime,level,tags, > #2: gc.log gc=trace uptime,level,tags, > ------- > > Decorators are ended with comma. > We should remove it as below: > ------- > Log output configuration: > #0: stdout vmoperation=debug,safepoint=info uptime,level,tags > #1: stderr all=warning uptime,level,tags > #2: gc.log gc=trace uptime,level,tags > ------- > > I uploaded a webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8155089/webrev.00/ Looks good. > > I cannot access JPRT. > So I need a sponsor. I can sponsor. Thanks, Marcus > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019506.html From harold.seigel at oracle.com Wed Apr 27 12:34:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Apr 2016 08:34:53 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output Message-ID: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> Hi, Please review this small change to add module information to the class histogram displayed by tools such as jmap and jcmd. The module name and version will follow the class name and be enclosed in parentheses. Classes not in modules will not contain module information. For example: num #instances #bytes class name (module) ------------------------------------------------------- 1: 7892 1575952 [B (java.base at 9-internal) 2: 1783 214672 java.lang.Class (java.base at 9-internal) 3: 5749 183968 java.util.HashMap$Node (java.base at 9-internal) 4: 7081 169944 java.lang.String (java.base at 9-internal) 5: 1881 95312 [Ljava.lang.Object; (java.base at 9-internal) 6: 785 90832 [I (java.base at 9-internal) ... 16: 1024 16384 ClassHistogramTest$TestClass ... Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 The fix was tested with JCK Lang, and VM tests, the UTE colocated and non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK java/io, java/lang, java/util, and java/security tests. Thanks, Harold From sundararajan.athijegannathan at oracle.com Wed Apr 27 12:41:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Apr 2016 18:11:51 +0530 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> Message-ID: <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> +1 PS. Don't we have to update the SA code that dumps histogram so that -F mode output would be similar? -Sundar On 4/27/2016 6:04 PM, harold seigel wrote: > Hi, > > Please review this small change to add module information to the class > histogram displayed by tools such as jmap and jcmd. The module name > and version will follow the class name and be enclosed in > parentheses. Classes not in modules will not contain module > information. For example: > > num #instances #bytes class name (module) > ------------------------------------------------------- > 1: 7892 1575952 [B (java.base at 9-internal) > 2: 1783 214672 java.lang.Class > (java.base at 9-internal) > 3: 5749 183968 java.util.HashMap$Node > (java.base at 9-internal) > 4: 7081 169944 java.lang.String > (java.base at 9-internal) > 5: 1881 95312 [Ljava.lang.Object; > (java.base at 9-internal) > 6: 785 90832 [I (java.base at 9-internal) > ... > 16: 1024 16384 ClassHistogramTest$TestClass > ... > > > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 > > The fix was tested with JCK Lang, and VM tests, the UTE colocated and > non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK > java/io, java/lang, java/util, and java/security tests. > > Thanks, Harold > From harold.seigel at oracle.com Wed Apr 27 17:35:32 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Apr 2016 13:35:32 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> Message-ID: <90ede06e-7c4d-7eb3-cdcf-bd1b33e26534@oracle.com> Hi Sundar, Thanks for reviewing my change. I'm unclear about what module related work is being done in SA. If a similar change is needed in SA then I'd prefer to handle it as a separate bug. Thanks! Harold On 4/27/2016 8:41 AM, Sundararajan Athijegannathan wrote: > +1 > > PS. Don't we have to update the SA code that dumps histogram so that -F > mode output would be similar? > > -Sundar > > On 4/27/2016 6:04 PM, harold seigel wrote: >> Hi, >> >> Please review this small change to add module information to the class >> histogram displayed by tools such as jmap and jcmd. The module name >> and version will follow the class name and be enclosed in >> parentheses. Classes not in modules will not contain module >> information. For example: >> >> num #instances #bytes class name (module) >> ------------------------------------------------------- >> 1: 7892 1575952 [B (java.base at 9-internal) >> 2: 1783 214672 java.lang.Class >> (java.base at 9-internal) >> 3: 5749 183968 java.util.HashMap$Node >> (java.base at 9-internal) >> 4: 7081 169944 java.lang.String >> (java.base at 9-internal) >> 5: 1881 95312 [Ljava.lang.Object; >> (java.base at 9-internal) >> 6: 785 90832 [I (java.base at 9-internal) >> ... >> 16: 1024 16384 ClassHistogramTest$TestClass >> ... >> >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 >> >> The fix was tested with JCK Lang, and VM tests, the UTE colocated and >> non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK >> java/io, java/lang, java/util, and java/security tests. >> >> Thanks, Harold >> From serguei.spitsyn at oracle.com Thu Apr 28 07:00:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 00:00:51 -0700 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B319.6000602@oracle.com> References: <5721B319.6000602@oracle.com> Message-ID: <5721B523.6040501@oracle.com> Please, review the JDWP spec change in the pubs repository. This is the jdwp-spec.html patch: diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 2016 -0700 +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 2016 -0700 @@ -277,6 +277,12 @@ is a value. +moduleID +same as objectID +Uniquely identifies an object in the target VM that is known to +be a module object + + classLoaderID same as objectID Uniquely identifies an object in the target VM that is known to @@ -296,7 +302,7 @@ referenceTypeID -same as objectID +Target VM-specific, up to 8 bytes (see below) Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are Summary: JDWP specification at https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html says: Name Size referenceTypeID | same as objectID | ... While the text at the bottom of the page is calling out referenceTypeID as being sized independently (along with objectID, fieidID, etc): "Object ids, reference type ids, field ids, method ids, and frame ids may be sized differently in different target VM implementations" IDSizes JDWP command also specifies referenceTypeID size. The referenceTypeID "Size" column should say: "Target VM-specific, up to 8 bytes (see below)". Also, the push of the "JDK-8049365: Update JDI and JDWP for modules" missed to update the jdwp-spec.html with introduction of the moduleID type: Name Size Description ----------+-------------------+----------------------------------------------- moduleID | same as objectID | Uniquely identifies an object in the target VM that is known to be a module object. Testing: Checked the jdwp-spec.html in the browser window. No other testing is needed. Thanks, Serguei From dmitry.samersoff at oracle.com Thu Apr 28 07:04:14 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 28 Apr 2016 10:04:14 +0300 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B523.6040501@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> Message-ID: <5721B5EE.6090401@oracle.com> Serguei, Should "same as objectID" be replaced to explicit size? Looks good for me. -Dmitry On 2016-04-28 10:00, serguei.spitsyn at oracle.com wrote: > Please, review the JDWP spec change in the pubs repository. > > This is the jdwp-spec.html patch: > > diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html > --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 2016 > -0700 > +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 2016 > -0700 > @@ -277,6 +277,12 @@ > is a value. > > > +moduleID > +same as objectID > +Uniquely identifies an object in the target VM that is known to > +be a module object > + > + > classLoaderID > same as objectID > Uniquely identifies an object in the target VM that is known to > @@ -296,7 +302,7 @@ > > > referenceTypeID > -same as objectID > +Target VM-specific, up to 8 bytes (see below) > Uniquely identifies a reference type in the target VM. It > should not be assumed that for a particular class, the > classObjectID and the referenceTypeID are > > > Summary: > > JDWP specification at > https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html > says: > Name Size > referenceTypeID | same as objectID | ... > > While the text at the bottom of the page is calling out > referenceTypeID as being sized independently (along with objectID, > fieidID, etc): > "Object ids, reference type ids, field ids, method ids, and frame ids > may be sized differently in different target VM implementations" > IDSizes JDWP command also specifies referenceTypeID size. > > The referenceTypeID "Size" column should say: "Target VM-specific, up > to 8 bytes (see below)". > > Also, the push of the "JDK-8049365: Update JDI and JDWP for modules" > missed to update > the jdwp-spec.html with introduction of the moduleID type: > > Name Size Description > ----------+-------------------+----------------------------------------------- > > moduleID | same as objectID | Uniquely identifies an object in the > target VM that is known to be a module object. > > > Testing: > > Checked the jdwp-spec.html in the browser window. > No other testing is needed. > > > Thanks, > Serguei > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu Apr 28 07:04:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 00:04:33 -0700 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B523.6040501@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> Message-ID: <5721B601.9090506@oracle.com> Sorry. Forgot to attach the resulting jdwp-spec.html file. Please, find it in the attachment now. Thanks, Serguei On 4/28/16 00:00, serguei.spitsyn at oracle.com wrote: > Please, review the JDWP spec change in the pubs repository. > > This is the jdwp-spec.html patch: > > diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html > --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 > 2016 -0700 > +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 > 2016 -0700 > @@ -277,6 +277,12 @@ > is a value. > > > +moduleID > +same as objectID > +Uniquely identifies an object in the target VM that is known to > +be a module object > + > + > classLoaderID > same as objectID > Uniquely identifies an object in the target VM that is known to > @@ -296,7 +302,7 @@ > > > referenceTypeID > -same as objectID > +Target VM-specific, up to 8 bytes (see below) > Uniquely identifies a reference type in the target VM. It > should not be assumed that for a particular class, the > classObjectID and the referenceTypeID are > > > Summary: > > JDWP specification at > https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html > says: > Name Size > referenceTypeID | same as objectID | ... > > While the text at the bottom of the page is calling out > referenceTypeID as being sized independently (along with objectID, > fieidID, etc): > "Object ids, reference type ids, field ids, method ids, and frame > ids may be sized differently in different target VM implementations" > IDSizes JDWP command also specifies referenceTypeID size. > > The referenceTypeID "Size" column should say: "Target VM-specific, > up to 8 bytes (see below)". > > Also, the push of the "JDK-8049365: Update JDI and JDWP for modules" > missed to update > the jdwp-spec.html with introduction of the moduleID type: > > Name Size Description > ----------+-------------------+----------------------------------------------- > > moduleID | same as objectID | Uniquely identifies an object in the > target VM that is known to be a module object. > > > Testing: > > Checked the jdwp-spec.html in the browser window. > No other testing is needed. > > > Thanks, > Serguei > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 28 07:13:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 00:13:17 -0700 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B5EE.6090401@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> <5721B5EE.6090401@oracle.com> Message-ID: <5721B80D.8070609@oracle.com> Dmitry, On 4/28/16 00:04, Dmitry Samersoff wrote: > Serguei, > > Should "same as objectID" be replaced to explicit size? No, it is VM implementation dependent. Please, see the following statement in the spec: "Object ids, reference type ids, field ids, method ids, and frame ids may be sized differently in different target VM implementations." > > Looks good for me. Thank you for the quick review! Serguei > > -Dmitry > > > On 2016-04-28 10:00, serguei.spitsyn at oracle.com wrote: >> Please, review the JDWP spec change in the pubs repository. >> >> This is the jdwp-spec.html patch: >> >> diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html >> --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 2016 >> -0700 >> +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 2016 >> -0700 >> @@ -277,6 +277,12 @@ >> is a value. >> >> >> +moduleID >> +same as objectID >> +Uniquely identifies an object in the target VM that is known to >> +be a module object >> + >> + >> classLoaderID >> same as objectID >> Uniquely identifies an object in the target VM that is known to >> @@ -296,7 +302,7 @@ >> >> >> referenceTypeID >> -same as objectID >> +Target VM-specific, up to 8 bytes (see below) >> Uniquely identifies a reference type in the target VM. It >> should not be assumed that for a particular class, the >> classObjectID and the referenceTypeID are >> >> >> Summary: >> >> JDWP specification at >> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html >> says: >> Name Size >> referenceTypeID | same as objectID | ... >> >> While the text at the bottom of the page is calling out >> referenceTypeID as being sized independently (along with objectID, >> fieidID, etc): >> "Object ids, reference type ids, field ids, method ids, and frame ids >> may be sized differently in different target VM implementations" >> IDSizes JDWP command also specifies referenceTypeID size. >> >> The referenceTypeID "Size" column should say: "Target VM-specific, up >> to 8 bytes (see below)". >> >> Also, the push of the "JDK-8049365: Update JDI and JDWP for modules" >> missed to update >> the jdwp-spec.html with introduction of the moduleID type: >> >> Name Size Description >> ----------+-------------------+----------------------------------------------- >> >> moduleID | same as objectID | Uniquely identifies an object in the >> target VM that is known to be a module object. >> >> >> Testing: >> >> Checked the jdwp-spec.html in the browser window. >> No other testing is needed. >> >> >> Thanks, >> Serguei >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Apr 28 07:22:23 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 28 Apr 2016 00:22:23 -0700 (PDT) Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely Message-ID: Hi, Pls review the change for bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8154144"JDK-8154144 - Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely Webrev: http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Apr 28 07:46:41 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 28 Apr 2016 09:46:41 +0200 Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: References: Message-ID: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> Hi Sharath, Can you explain more how this help with the problem in the bug? It looks like you are trying to avoid a race by not printing the "Input stream closed.? message while shutting down. You added this: 136 ((TTY)notifier).setShuttingDown(true); 137 Env.shutdown(shutdownMessageKey); The call on line 137 will result in a System.exit(0) call if I am reading the code right. So adding the shutdown flag to line 136 will maybe make the race smaller, but isn?t really solving it? What kind of testing have you run this fix through? Thanks, /Staffan > On 28 apr. 2016, at 09:22, Sharath Ballal wrote: > > Hi, > > Pls review the change for bug > > JDK-8154144 - Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely > > Webrev: > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ > > -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Apr 28 08:25:01 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 28 Apr 2016 01:25:01 -0700 (PDT) Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> Message-ID: <88b669d0-82cb-48d5-ba40-878127fce72c@default> Hi Staffan, The root cause of this problem is that BufferedReader.readLine() is intermittently returning 'null' during System.exit(0). In TTY.java:751 we are always blocking on readLine(). Whenever a user enters a command in JDB, the readLine() returns the command, which gets executed. This is running in the 'main' thread. When JDB is done, as part of the shutdown it calls System.exit() at Env.java:92 in a different thread 'event-handler'. Usually (in the passing cases) calling System.exit() is the end of the process and readLine() doesn't return 'null', but in the failing case readLine() at TTY.java:751 returns 'null'. This causes the string "Input stream closed." to be printed. The jtreg testcase looks for this string to decide that the testcase failed. ? The fix I have done is avoiding the print because we know that we are shutting down and hence can discard the ?null? returned by readLine(). ? Regarding the testing, I have run few of the failing jtreg testcases about 200 times and not seen the problem (earlier I was able to recreate without the fix).? I have to do other tests, but sent for review to do it in parallel. jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 708 BufferedReader in = 709 new BufferedReader(new InputStreamReader(System.in)); ....... ....... 748 // Process interactive commands. 749 MessageOutput.printPrompt(); 750 while (true) { 751 String ln = in.readLine(); 752 if (ln == null) { 753 MessageOutput.println("Input stream closed."); 754 ln = "quit"; 755 } jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java 79 static void shutdown(String message) { 80 if (connection != null) { 81 try { 82 connection.disposeVM(); 83 } catch (VMDisconnectedException e) { 84 // Shutting down after the VM has gone away. This is 85 // not an error, and we just ignore it. 86 } 87 } 88 if (message != null) { 89 MessageOutput.lnprint(message); 90 MessageOutput.println(); 91 } 92 System.exit(0); 93 } ? ? -Sharath Ballal ? ? From: Staffan Larsen Sent: Thursday, April 28, 2016 1:17 PM To: Sharath Ballal Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Hi Sharath, ? Can you explain more how this help with the problem in the bug?? ? It looks like you are trying to avoid a race by not printing the "Input stream closed.? message while shutting down. You added this: 136???????????? ((TTY)notifier).setShuttingDown(true); 137???????????? Env.shutdown(shutdownMessageKey); The call on line 137 will result in a System.exit(0) call if I am reading the code right. So?adding the shutdown flag to line 136 will maybe make the race smaller, but isn?t really solving it? ? What kind of testing have you run this fix through? ? Thanks, /Staffan ? ? ? On 28 apr. 2016, at 09:22, Sharath Ballal wrote: ? Hi, ? Pls review the change for bug? ? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8154144"JDK-8154144?- Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Webrev: http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ ? -Sharath Ballal ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Thu Apr 28 09:00:56 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Apr 2016 11:00:56 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5716EA4D.2030401@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> Message-ID: <1461834056.25448.18.camel@redhat.com> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: > > Hi Severin, > > > > I postpone a push for this fix. > > > > There are two nsk.jdi test failures (they look like deadlocks): > > ? nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) > > ? nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) > > > > and one jtreg sun/com/jdi failure (it looks like a deadlock too): > > ? com/sun/jdi/InvokeHangTes.java > > > > > > I'll double check if these failures are regressions caused by your fix? > > or not. > I confirm, the failures above are new regressions introduced by the fix. > The tests fail consistently with the fix and do not fail without the fix. OK this was caused by the locking done in invoker_doInvoke(). Note that holding either of them invoker lock or event handler lock causes this. Here is a new webrev with those hunks removed. It's sufficient to grab the locks again in invoke_completeInvokeRequest() when clearing the global references in order to not get those failures we've seen when the fix for JDK-4858370 was in place. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ Testing done: ?-?com/sun/jdi/InvokeTest.java?com/sun/jdi/InvokeHangTest.java and ? ?sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. ?- regular com/sun/jdi test set: no regressions Note that there are some rare cases where OomDebugTest times out which seems to be caused by the GC, though. See the bug for details. Since this problem is rare, it's still worthwhile having that test included. If it turns out a problem in practice we could consider disabling the test. Thoughts? Cheers, Severin From serguei.spitsyn at oracle.com Thu Apr 28 09:44:55 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 02:44:55 -0700 Subject: RFR (XS): 8153190 JVMTI GetAllModules should make it clear that it also returns unnamed module Message-ID: <5721DB97.4070903@oracle.com> Please, review the JVM TI spec one-liner fix below. The jvmti.xml patch: diff -r 888f37103953 src/share/vm/prims/jvmti.xml --- a/src/share/vm/prims/jvmti.xml Wed Apr 27 11:25:16 2016 +0200 +++ b/src/share/vm/prims/jvmti.xml Thu Apr 28 02:24:09 2016 -0700 @@ -6482,6 +6482,7 @@ Get All Modules Return an array of all modules loaded in the virtual machine. + This includes the unnamed module for each class loader. The number of modules in the array is returned via module_count_ptr, and the array itself via modules_ptr. Summary: The GetAllModules function returns all modules in the VM, this includes the unnamed module for each class loader. The JVM TI spec should make this clear. Testing: No testing is necessary. Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Apr 28 09:48:16 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Apr 2016 10:48:16 +0100 Subject: RFR (XS): 8153190 JVMTI GetAllModules should make it clear that it also returns unnamed module In-Reply-To: <5721DB97.4070903@oracle.com> References: <5721DB97.4070903@oracle.com> Message-ID: <5721DC60.7000303@oracle.com> On 28/04/2016 10:44, serguei.spitsyn at oracle.com wrote: > Please, review the JVM TI spec one-liner fix below. > > > The jvmti.xml patch: > > diff -r 888f37103953 src/share/vm/prims/jvmti.xml > --- a/src/share/vm/prims/jvmti.xml Wed Apr 27 11:25:16 2016 +0200 > +++ b/src/share/vm/prims/jvmti.xml Thu Apr 28 02:24:09 2016 -0700 > @@ -6482,6 +6482,7 @@ > Get All Modules > > Return an array of all modules loaded in the virtual machine. > + This includes the unnamed module for each class loader. Looks okay, alternative "The array include the unnamed module ...". -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 28 09:53:07 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 02:53:07 -0700 Subject: RFR (XS): 8153190 JVMTI GetAllModules should make it clear that it also returns unnamed module In-Reply-To: <5721DC60.7000303@oracle.com> References: <5721DB97.4070903@oracle.com> <5721DC60.7000303@oracle.com> Message-ID: <5721DD83.8060800@oracle.com> On 4/28/16 02:48, Alan Bateman wrote: > > > On 28/04/2016 10:44, serguei.spitsyn at oracle.com wrote: >> Please, review the JVM TI spec one-liner fix below. >> >> >> The jvmti.xml patch: >> >> diff -r 888f37103953 src/share/vm/prims/jvmti.xml >> --- a/src/share/vm/prims/jvmti.xml Wed Apr 27 11:25:16 2016 +0200 >> +++ b/src/share/vm/prims/jvmti.xml Thu Apr 28 02:24:09 2016 -0700 >> @@ -6482,6 +6482,7 @@ >> Get All Modules >> >> Return an array of all modules loaded in the virtual machine. >> + This includes the unnamed module for each class loader. > Looks okay, alternative "The array include the unnamed module ...". It makes sense, thanks. The updated patch is: diff -r 888f37103953 src/share/vm/prims/jvmti.xml --- a/src/share/vm/prims/jvmti.xml Wed Apr 27 11:25:16 2016 +0200 +++ b/src/share/vm/prims/jvmti.xml Thu Apr 28 02:51:43 2016 -0700 @@ -6482,6 +6482,7 @@ Get All Modules Return an array of all modules loaded in the virtual machine. + The array includes the unnamed module for each class loader. The number of modules in the array is returned via module_count_ptr, and the array itself via modules_ptr. Thanks, Serguei > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Apr 28 10:57:34 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 28 Apr 2016 12:57:34 +0200 Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <88b669d0-82cb-48d5-ba40-878127fce72c@default> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> <88b669d0-82cb-48d5-ba40-878127fce72c@default> Message-ID: Hi Sharath, Ah, I see: it is the call to System.exit() that is causing readLine to return. That makes sense, and I now understand the fix. Reviewed. Thanks, /Staffan > On 28 apr. 2016, at 10:25, Sharath Ballal wrote: > > Hi Staffan, > The root cause of this problem is that BufferedReader.readLine() is intermittently returning 'null' during System.exit(0). > > In TTY.java:751 we are always blocking on readLine(). Whenever a user enters a command in JDB, the readLine() returns the command, which gets executed. This is running in the 'main' thread. > > When JDB is done, as part of the shutdown it calls System.exit() at Env.java:92 in a different thread 'event-handler'. > > Usually (in the passing cases) calling System.exit() is the end of the process and readLine() doesn't return 'null', but in the failing case readLine() at TTY.java:751 returns 'null'. This causes the string "Input stream closed." to be printed. The jtreg testcase looks for this string to decide that the testcase failed. > > The fix I have done is avoiding the print because we know that we are shutting down and hence can discard the ?null? returned by readLine(). > > Regarding the testing, I have run few of the failing jtreg testcases about 200 times and not seen the problem (earlier I was able to recreate without the fix). I have to do other tests, but sent for review to do it in parallel. > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > > 708 BufferedReader in = > 709 new BufferedReader(new InputStreamReader(System.in)); > ....... > ....... > 748 // Process interactive commands. > 749 MessageOutput.printPrompt(); > 750 while (true) { > 751 String ln = in.readLine(); > 752 if (ln == null) { > 753 MessageOutput.println("Input stream closed."); > 754 ln = "quit"; > 755 } > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java > > 79 static void shutdown(String message) { > 80 if (connection != null) { > 81 try { > 82 connection.disposeVM(); > 83 } catch (VMDisconnectedException e) { > 84 // Shutting down after the VM has gone away. This is > 85 // not an error, and we just ignore it. > 86 } > 87 } > 88 if (message != null) { > 89 MessageOutput.lnprint(message); > 90 MessageOutput.println(); > 91 } > 92 System.exit(0); > 93 } > > > -Sharath Ballal > > > From: Staffan Larsen > Sent: Thursday, April 28, 2016 1:17 PM > To: Sharath Ballal > Cc: serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely > > Hi Sharath, > > Can you explain more how this help with the problem in the bug? > > It looks like you are trying to avoid a race by not printing the "Input stream closed.? message while shutting down. You added this: > 136 ((TTY)notifier).setShuttingDown(true); > 137 Env.shutdown(shutdownMessageKey); > The call on line 137 will result in a System.exit(0) call if I am reading the code right. So adding the shutdown flag to line 136 will maybe make the race smaller, but isn?t really solving it? > > What kind of testing have you run this fix through? > > Thanks, > /Staffan > > > > On 28 apr. 2016, at 09:22, Sharath Ballal > wrote: > > Hi, > > Pls review the change for bug > > JDK-8154144 - Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely > > Webrev: > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ > > -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Apr 28 11:59:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Apr 2016 12:59:17 +0100 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B523.6040501@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> Message-ID: <5721FB15.4060506@oracle.com> On 28/04/2016 08:00, serguei.spitsyn at oracle.com wrote: > Please, review the JDWP spec change in the pubs repository. > > This is the jdwp-spec.html patch: > I think this looks okay. -Alan From daniel.daugherty at oracle.com Thu Apr 28 13:49:58 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Apr 2016 07:49:58 -0600 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721B523.6040501@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> Message-ID: <57221506.10800@oracle.com> Ties moduleID to objectID and there's existing verbiage about objectID being possibly variant in size depending on the implementation. Thumbs up. Dan On 4/28/16 1:00 AM, serguei.spitsyn at oracle.com wrote: > Please, review the JDWP spec change in the pubs repository. > > This is the jdwp-spec.html patch: > > diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html > --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 > 2016 -0700 > +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 > 2016 -0700 > @@ -277,6 +277,12 @@ > is a value. > > > +moduleID > +same as objectID > +Uniquely identifies an object in the target VM that is known to > +be a module object > + > + > classLoaderID > same as objectID > Uniquely identifies an object in the target VM that is known to > @@ -296,7 +302,7 @@ > > > referenceTypeID > -same as objectID > +Target VM-specific, up to 8 bytes (see below) > Uniquely identifies a reference type in the target VM. It > should not be assumed that for a particular class, the > classObjectID and the referenceTypeID are > > > Summary: > > JDWP specification at > https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html > says: > Name Size > referenceTypeID | same as objectID | ... > > While the text at the bottom of the page is calling out > referenceTypeID as being sized independently (along with objectID, > fieidID, etc): > "Object ids, reference type ids, field ids, method ids, and frame > ids may be sized differently in different target VM implementations" > IDSizes JDWP command also specifies referenceTypeID size. > > The referenceTypeID "Size" column should say: "Target VM-specific, > up to 8 bytes (see below)". > > Also, the push of the "JDK-8049365: Update JDI and JDWP for modules" > missed to update > the jdwp-spec.html with introduction of the moduleID type: > > Name Size Description > ----------+-------------------+----------------------------------------------- > > moduleID | same as objectID | Uniquely identifies an object in the > target VM that is known to be a module object. > > > Testing: > > Checked the jdwp-spec.html in the browser window. > No other testing is needed. > > > Thanks, > Serguei > > > From daniel.daugherty at oracle.com Thu Apr 28 14:17:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Apr 2016 08:17:59 -0600 Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <88b669d0-82cb-48d5-ba40-878127fce72c@default> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> <88b669d0-82cb-48d5-ba40-878127fce72c@default> Message-ID: <57221B97.5040506@oracle.com> > When JDB is done, as part of the shutdown it calls System.exit() > at Env.java:92 in a different thread 'event-handler'. Based on the above line from below, I'm even more convinced that this bug is hit because the debuggee VM is allowed to run off the end of main() and that creates a race between debuggee VM's attempt to exit and the debugger trying to control the test execution. While this fix makes this bug "go away", I don't think this is the right solution. You're basically trying to harden our ability to handle this race condition instead of closing the race condition. I'll repeat part of the comment that I added to the bug on 04.13: > One possible solution is to add a breakpoint after main() returns and change > the debuggee <-> debugger protocol to always expect one final breakpoint. > Positive enforcement that the test reaches that point and it should catch any > accidental "run of the end of main()" issues. Dan On 4/28/16 2:25 AM, Sharath Ballal wrote: > > Hi Staffan, > > The root cause of this problem is that BufferedReader.readLine() is > intermittently returning 'null' during System.exit(0). > > In TTY.java:751 we are always blocking on readLine(). Whenever a user > enters a command in JDB, the readLine() returns the command, which > gets executed. This is running in the 'main' thread. > > When JDB is done, as part of the shutdown it calls System.exit() at > Env.java:92 in a different thread 'event-handler'. > > Usually (in the passing cases) calling System.exit() is the end of the > process and readLine() doesn't return 'null', but in the failing case > readLine() at TTY.java:751 returns 'null'. This causes the string > "Input stream closed." to be printed. The jtreg testcase looks for > this string to decide that the testcase failed. > > The fix I have done is avoiding the print because we know that we are > shutting down and hence can discard the ?null? returned by readLine(). > > Regarding the testing, I have run few of the failing jtreg testcases > about 200 times and not seen the problem (earlier I was able to > recreate without the fix). I have to do other tests, but sent for > review to do it in parallel. > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > > 708 BufferedReader in = > 709 new BufferedReader(new InputStreamReader(System.in)); > ....... > ....... > 748 // Process interactive commands. > 749 MessageOutput.printPrompt(); > 750 while (true) { > 751 String ln = in.readLine(); > 752 if (ln == null) { > 753 MessageOutput.println("Input stream closed."); > 754 ln = "quit"; > 755 } > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java > > 79 static void shutdown(String message) { > 80 if (connection != null) { > 81 try { > 82 connection.disposeVM(); > 83 } catch (VMDisconnectedException e) { > 84 // Shutting down after the VM has gone away. This is > 85 // not an error, and we just ignore it. > 86 } > 87 } > 88 if (message != null) { > 89 MessageOutput.lnprint(message); > 90 MessageOutput.println(); > 91 } > 92 System.exit(0); > 93 } > > -Sharath Ballal > > *From:*Staffan Larsen > *Sent:* Thursday, April 28, 2016 1:17 PM > *To:* Sharath Ballal > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: JDK-8154144 Tests in com/sun/jdi fails > intermittently with "jdb input stream closed prematurely > > Hi Sharath, > > Can you explain more how this help with the problem in the bug? > > It looks like you are trying to avoid a race by not printing the > "Input stream closed.? message while shutting down. You added this: > > *136 ((TTY)notifier).setShuttingDown(true);* > 137 Env.shutdown(shutdownMessageKey); > > The call on line 137 will result in a System.exit(0) call if I am > reading the code right. So adding the shutdown flag to line 136 will > maybe make the race smaller, but isn?t really solving it? > > What kind of testing have you run this fix through? > > Thanks, > > /Staffan > > On 28 apr. 2016, at 09:22, Sharath Ballal > > wrote: > > Hi, > > Pls review the change for bug > > JDK-8154144 - > Tests in com/sun/jdi fails intermittently with "jdb input stream > closed prematurely > > Webrev: > > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ > > > -Sharath Ballal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 28 18:11:29 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 11:11:29 -0700 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <5721FB15.4060506@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> <5721FB15.4060506@oracle.com> Message-ID: <57225251.9080002@oracle.com> On 4/28/16 04:59, Alan Bateman wrote: > > > On 28/04/2016 08:00, serguei.spitsyn at oracle.com wrote: >> Please, review the JDWP spec change in the pubs repository. >> >> This is the jdwp-spec.html patch: >> > I think this looks okay. Thanks! Serguei > > -Alan > From serguei.spitsyn at oracle.com Thu Apr 28 18:13:28 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Apr 2016 11:13:28 -0700 Subject: RFR (XS): 8150725 JDWP specification: referenceTypeID size needs clarification In-Reply-To: <57221506.10800@oracle.com> References: <5721B319.6000602@oracle.com> <5721B523.6040501@oracle.com> <57221506.10800@oracle.com> Message-ID: <572252C8.9000503@oracle.com> Thanks, Dan! Serguei On 4/28/16 06:49, Daniel D. Daugherty wrote: > Ties moduleID to objectID and there's existing verbiage about > objectID being possibly variant in size depending on the > implementation. > > Thumbs up. > > Dan > > > On 4/28/16 1:00 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the JDWP spec change in the pubs repository. >> >> This is the jdwp-spec.html patch: >> >> diff -r 419446ca4a1b docs/technotes/guides/jpda/jdwp-spec.html >> --- a/docs/technotes/guides/jpda/jdwp-spec.html Thu Apr 21 13:37:56 >> 2016 -0700 >> +++ b/docs/technotes/guides/jpda/jdwp-spec.html Wed Apr 27 20:02:12 >> 2016 -0700 >> @@ -277,6 +277,12 @@ >> is a value. >> >> >> +moduleID >> +same as objectID >> +Uniquely identifies an object in the target VM that is known to >> +be a module object >> + >> + >> classLoaderID >> same as objectID >> Uniquely identifies an object in the target VM that is known to >> @@ -296,7 +302,7 @@ >> >> >> referenceTypeID >> -same as objectID >> +Target VM-specific, up to 8 bytes (see below) >> Uniquely identifies a reference type in the target VM. It >> should not be assumed that for a particular class, the >> classObjectID and the referenceTypeID are >> >> >> Summary: >> >> JDWP specification at >> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/jdwp-spec.html >> says: >> Name Size >> referenceTypeID | same as objectID | ... >> >> While the text at the bottom of the page is calling out >> referenceTypeID as being sized independently (along with objectID, >> fieidID, etc): >> "Object ids, reference type ids, field ids, method ids, and frame >> ids may be sized differently in different target VM implementations" >> IDSizes JDWP command also specifies referenceTypeID size. >> >> The referenceTypeID "Size" column should say: "Target VM-specific, >> up to 8 bytes (see below)". >> >> Also, the push of the "JDK-8049365: Update JDI and JDWP for >> modules" missed to update >> the jdwp-spec.html with introduction of the moduleID type: >> >> Name Size Description >> ----------+-------------------+----------------------------------------------- >> >> moduleID | same as objectID | Uniquely identifies an object in the >> target VM that is known to be a module object. >> >> >> Testing: >> >> Checked the jdwp-spec.html in the browser window. >> No other testing is needed. >> >> >> Thanks, >> Serguei >> >> >> > From harsha.wardhana.b at oracle.com Fri Apr 29 04:20:46 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 29 Apr 2016 09:50:46 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> Message-ID: <5722E11E.9020403@oracle.com> Hi Jaroslav, I am not sure how @required tag works. I searched code base and it is not used in any file. Also, the documentation on Jtreg page is sparse. Could you paste an example as to how to use it? Also, I would still think that repeated gc via weak-reference is right and defensive approach. So I would like to leave that in place unless it is causing any side-effects. Thanks Harsha On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: > > > On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B > > > wrote: > > Hi, > > Please review below patch to disable concurrent GC option. > http://cr.openjdk.java.net/~hb/8154166/webrev.01/ > > > > I'm sorry to be a PITA, but why it is not possible to use the @require > tag? > > > > Jaroslav, > > According to Javadoc of Runtime.gc(), > > https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- > > The call will only make it's best effort to do a GC and provides > no guarantee that a given object can be collected even if GC runs. > It does not say that Runtime.gc() call will block till entire GC > cycle is finished and hence we cannot be making that assumption. > > > I know, I had the same discussion a while ago when fixing some other > tests failing when run with allowed concurrent explicit GC and I was > pointed to the fact that all the known implementation actually do wait > until the complete GC cycle is over before returning. Otherwise all > those tests relying on some memory having been reclaimed or some > counters having been increased would have to be considered random. > > > Hence it is required that we encapsulate the target object in > WeakReference and repeatedly call GC till weakRef returns null. > Granted that we will have a small window when weakRef returns null > and the target object is not removed from memory. But I see no way > how to fix that problem. > > > Exactly. The only guarantee for all the GC related metrics having been > updated before proceeding with the test is being able to run the > explicit GC in blocking manner. Otherwise the tests are not really > deterministic and can intermittently fail. > > -JB- > > > -Harsha > > > On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: >> The reproducer would be very time sensitive as with the provided >> 'ExplicitGCInvokesConcurrent' it will run GC concurrently with >> the invoker. Otherwise, in the current implementation, calling >> Runtime.gc() would guarantee the GC cycle has finished before >> that method returns. >> >> The WeakReference javadoc >> (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) >> is only stating that the referenced object will be made >> finalizable at the same time as the reference is cleared. As a >> consequence a cleared reference might not always mean that the >> heap usage has been changed (unless a particular GC >> implementation makes some additional guarantees). >> >> I know we were stabilizing a bunch of related tests relying on GC >> doing its work before checking for some post-conditions and the >> only way to make the tests reliable was to forbid running those >> tests with '-XX:+ExplicitGCInvokesConcurrent'. >> >> -JB- >> >> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B >> > > wrote: >> >> Hello, >> >> The issue was not reproducible with or without, >> >> "-XX:+ExplicitGCInvokesConcurrent" >> >> Flag. The patch ensures that GC happens before we start >> measuring memory. Without the patch, GC might or might not >> happen. >> >> -Harsha >> >> >> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >>> Hi, >>> >>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B >>> >> > wrote: >>> >>> Hi, >>> >>> Please review the below simple fix for issue, >>> >>> issue : https://bugs.openjdk.java.net/browse/JDK-8154166 >>> webrev : >>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>> >>> >>> >>> Shouldn't this test rather declare the conditions when it is >>> supposed to work? According to the issue this was caused by >>> introducing the "-XX:+ExplicitGCInvokesConcurrent" which >>> makes it very tricky to make any assumptions about the GC >>> process. >>> >>> See eg. >>> jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >>> for enabling the test only for allowed configurations. >>> >>> Cheers, >>> >>> -JB- >>> >>> >>> >>> -Harsha >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Apr 29 05:55:23 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 28 Apr 2016 22:55:23 -0700 (PDT) Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <57221B97.5040506@oracle.com> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> <88b669d0-82cb-48d5-ba40-878127fce72c@default> <57221B97.5040506@oracle.com> Message-ID: <890dc06b-99b7-4105-b734-9d9df227d74c@default> Hi Dan, ? The debugger has received a ?vmDeathEvent? and as part of handling this event, the System.exit() is being called (handleExitEvent() in EventHandler.java).? So the fact that debuggee has finished executing, is known to the debugger and the debugger is explicitly cleaning up after that.? This is similar to the breakpoint you mentioned.? Instead of breakpoint, we have an event.? Now as part of the explicit cleanup the readLine() (which is always blocking) sometimes returns with a ?null?.? Since we know we are cleaning up and we also know that the debuggee has done executing, I am avoiding printing the error message. ? -Sharath Ballal ? ? From: Daniel D. Daugherty Sent: Thursday, April 28, 2016 7:48 PM To: Sharath Ballal; Staffan Larsen Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? > When JDB is done, as part of the shutdown it calls System.exit() > at Env.java:92 in a different thread 'event-handler'. Based on the above line from below, I'm even more convinced that this bug is hit because the debuggee VM is allowed to run off the end of main() and that creates a race between debuggee VM's attempt to exit and the debugger trying to control the test execution. While this fix makes this bug "go away", I don't think this is the right solution. You're basically trying to harden our ability to handle this race condition instead of closing the race condition. I'll repeat part of the comment that I added to the bug on 04.13: > One possible solution is to add a breakpoint after main() returns and change > the debuggee <-> debugger protocol to always expect one final breakpoint. > Positive enforcement that the test reaches that point and it should catch any > accidental "run of the end of main()" issues. Dan On 4/28/16 2:25 AM, Sharath Ballal wrote: Hi Staffan, The root cause of this problem is that BufferedReader.readLine() is intermittently returning 'null' during System.exit(0). In TTY.java:751 we are always blocking on readLine(). Whenever a user enters a command in JDB, the readLine() returns the command, which gets executed. This is running in the 'main' thread. When JDB is done, as part of the shutdown it calls System.exit() at Env.java:92 in a different thread 'event-handler'. Usually (in the passing cases) calling System.exit() is the end of the process and readLine() doesn't return 'null', but in the failing case readLine() at TTY.java:751 returns 'null'. This causes the string "Input stream closed." to be printed. The jtreg testcase looks for this string to decide that the testcase failed. ? The fix I have done is avoiding the print because we know that we are shutting down and hence can discard the ?null? returned by readLine(). ? Regarding the testing, I have run few of the failing jtreg testcases about 200 times and not seen the problem (earlier I was able to recreate without the fix).? I have to do other tests, but sent for review to do it in parallel. jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 708 BufferedReader in = 709 new BufferedReader(new InputStreamReader(System.in)); ....... ....... 748 // Process interactive commands. 749 MessageOutput.printPrompt(); 750 while (true) { 751 String ln = in.readLine(); 752 if (ln == null) { 753 MessageOutput.println("Input stream closed."); 754 ln = "quit"; 755 } jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java 79 static void shutdown(String message) { 80 if (connection != null) { 81 try { 82 connection.disposeVM(); 83 } catch (VMDisconnectedException e) { 84 // Shutting down after the VM has gone away. This is 85 // not an error, and we just ignore it. 86 } 87 } 88 if (message != null) { 89 MessageOutput.lnprint(message); 90 MessageOutput.println(); 91 } 92 System.exit(0); 93 } ? ? -Sharath Ballal ? ? From: Staffan Larsen Sent: Thursday, April 28, 2016 1:17 PM To: Sharath Ballal Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Hi Sharath, ? Can you explain more how this help with the problem in the bug?? ? It looks like you are trying to avoid a race by not printing the "Input stream closed.? message while shutting down. You added this: 136???????????? ((TTY)notifier).setShuttingDown(true); 137???????????? Env.shutdown(shutdownMessageKey); The call on line 137 will result in a System.exit(0) call if I am reading the code right. So?adding the shutdown flag to line 136 will maybe make the race smaller, but isn?t really solving it? ? What kind of testing have you run this fix through? ? Thanks, /Staffan ? ? ? On 28 apr. 2016, at 09:22, Sharath Ballal wrote: ? Hi, ? Pls review the change for bug? ? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8154144"JDK-8154144?- Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Webrev: http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ ? -Sharath Ballal ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 29 08:34:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Apr 2016 01:34:18 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1461834056.25448.18.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> Message-ID: <57231C8A.3050406@oracle.com> Hi Severin, The fix looks good in general. I'm testing both fixes together at the moment. A couple of questions... It seems, there are more places where an invokerLock critical section is missed. The following functions: - invoker_enableInvokeRequests - invokeConstructor - invokeStatic - invokeNonvirtual - invokeVirtual - saveGlobalRef The first function is easy to fix. The last 5 functions are called from the invoker_doInvoke() that we already had a problem with. I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time? I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues. Thanks, Serguei On 4/28/16 02:00, Severin Gehwolf wrote: > On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: >>> Hi Severin, >>> >>> I postpone a push for this fix. >>> >>> There are two nsk.jdi test failures (they look like deadlocks): >>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) >>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>> >>> and one jtreg sun/com/jdi failure (it looks like a deadlock too): >>> com/sun/jdi/InvokeHangTes.java >>> >>> >>> I'll double check if these failures are regressions caused by your fix >>> or not. >> I confirm, the failures above are new regressions introduced by the fix. >> The tests fail consistently with the fix and do not fail without the fix. > OK this was caused by the locking done in invoker_doInvoke(). Note that > holding either of them invoker lock or event handler lock causes this. > > Here is a new webrev with those hunks removed. It's sufficient to grab > the locks again in invoke_completeInvokeRequest() when clearing the > global references in order to not get those failures we've seen when > the fix for JDK-4858370 was in place. > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ > > Testing done: > - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and > sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. > - regular com/sun/jdi test set: no regressions > > Note that there are some rare cases where OomDebugTest times out which > seems to be caused by the GC, though. See the bug for details. Since > this problem is rare, it's still worthwhile having that test included. > If it turns out a problem in practice we could consider disabling the > test. > > Thoughts? > > Cheers, > Severin -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bachorik at gmail.com Fri Apr 29 08:45:51 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Fri, 29 Apr 2016 10:45:51 +0200 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: <5722E11E.9020403@oracle.com> References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> <5722E11E.9020403@oracle.com> Message-ID: On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B < harsha.wardhana.b at oracle.com> wrote: > Hi Jaroslav, > > I am not sure how @required tag works. I searched code base and it is not > used in any file. Also, the documentation on Jtreg page is sparse. > > Could you paste an example as to how to use it? > Please, take a look at jdk/test/java/lang/management/MemoryMXBean/LowMemoryTest.java - actually, it is '@requires' tag. > > Also, I would still think that repeated gc via weak-reference is right and > defensive approach. So I would like to leave that in place unless it is > causing any side-effects. > No objections here. It does not break anything and makes the test intentions clearer. -JB- > > Thanks > Harsha > > > On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: > > > > On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B < > harsha.wardhana.b at oracle.com> wrote: > >> Hi, >> >> Please review below patch to disable concurrent GC option. >> http://cr.openjdk.java.net/~hb/8154166/webrev.01/ >> > > I'm sorry to be a PITA, but why it is not possible to use the @require tag? > > >> >> >> Jaroslav, >> >> According to Javadoc of Runtime.gc(), >> >> https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- >> >> The call will only make it's best effort to do a GC and provides no >> guarantee that a given object can be collected even if GC runs. >> It does not say that Runtime.gc() call will block till entire GC cycle is >> finished and hence we cannot be making that assumption. >> > > I know, I had the same discussion a while ago when fixing some other tests > failing when run with allowed concurrent explicit GC and I was pointed to > the fact that all the known implementation actually do wait until the > complete GC cycle is over before returning. Otherwise all those tests > relying on some memory having been reclaimed or some counters having been > increased would have to be considered random. > > >> >> Hence it is required that we encapsulate the target object in >> WeakReference and repeatedly call GC till weakRef returns null. >> Granted that we will have a small window when weakRef returns null and >> the target object is not removed from memory. But I see no way how to fix >> that problem. >> > > Exactly. The only guarantee for all the GC related metrics having been > updated before proceeding with the test is being able to run the explicit > GC in blocking manner. Otherwise the tests are not really deterministic and > can intermittently fail. > > -JB- > > >> >> -Harsha >> >> >> On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: >> >> The reproducer would be very time sensitive as with the provided >> 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the invoker. >> Otherwise, in the current implementation, calling Runtime.gc() would >> guarantee the GC cycle has finished before that method returns. >> >> The WeakReference javadoc ( >> >> https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) >> is only stating that the referenced object will be made finalizable at the >> same time as the reference is cleared. As a consequence a cleared reference >> might not always mean that the heap usage has been changed (unless a >> particular GC implementation makes some additional guarantees). >> >> I know we were stabilizing a bunch of related tests relying on GC doing >> its work before checking for some post-conditions and the only way to make >> the tests reliable was to forbid running those tests with >> '-XX:+ExplicitGCInvokesConcurrent'. >> >> -JB- >> >> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B < >> harsha.wardhana.b at oracle.com> wrote: >> >>> Hello, >>> >>> The issue was not reproducible with or without, >>> >>> "-XX:+ExplicitGCInvokesConcurrent" >>> >>> Flag. The patch ensures that GC happens before we start measuring >>> memory. Without the patch, GC might or might not happen. >>> >>> -Harsha >>> >>> >>> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >>> >>> Hi, >>> >>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < >>> harsha.wardhana.b at oracle.com> wrote: >>> >>>> Hi, >>>> >>>> Please review the below simple fix for issue, >>>> >>>> issue : >>>> https://bugs.openjdk.java.net/browse/JDK-8154166 >>>> webrev : >>>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>>> >>> >>> Shouldn't this test rather declare the conditions when it is supposed to >>> work? According to the issue this was caused by introducing the "-XX:+ExplicitGCInvokesConcurrent" >>> which makes it very tricky to make any assumptions about the GC process. >>> >>> See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >>> for enabling the test only for allowed configurations. >>> >>> Cheers, >>> >>> -JB- >>> >>> >>>> >>>> >>>> -Harsha >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Apr 29 08:56:06 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 29 Apr 2016 10:56:06 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57231C8A.3050406@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> Message-ID: <1461920166.3712.19.camel@redhat.com> Hi Serguei, On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > The fix looks good in general. > I'm testing both fixes together at the moment. That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. > A couple of questions... > > It seems, there are more places where an invokerLock critical section is missed. Right. > The following functions: > ? - invoker_enableInvokeRequests This should be fixed with the patch for JDK-8154529 > ? - invokeConstructor > ? - invokeStatic > ? - invokeNonvirtual > ? - invokeVirtual > ? - saveGlobalRef Correct. The intent would be to fix the callsites of saveGlobalRef. If we fix invoke* then saveGlobalRef should not be an issue. I didn't want to include this in this fix since it's pretty hairy and would like to fix this in incremental steps. > The first function is easy to fix. > The last 5 functions are called from the invoker_doInvoke() that we already had a problem with. > I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time? I'm not sure yet. Perhaps locking only while?saveGlobalRef is being called in invoke* functions will help. > I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues. Please keep me in the loop about your test results. Thanks for your help! Cheers, Severin > Thanks, > Serguei > > > On 4/28/16 02:00, Severin Gehwolf wrote: > > On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: > > > > Hi Severin, > > > > > > > > I postpone a push for this fix. > > > > > > > > There are two nsk.jdi test failures (they look like deadlocks): > > > > ? nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) > > > > ? nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) > > > > > > > > and one jtreg sun/com/jdi failure (it looks like a deadlock too): > > > > ? com/sun/jdi/InvokeHangTes.java > > > > > > > > > > > > I'll double check if these failures are regressions caused by your fix? > > > > or not. > > > I confirm, the failures above are new regressions introduced by the fix. > > > The tests fail consistently with the fix and do not fail without the fix. > > OK this was caused by the locking done in invoker_doInvoke(). Note that > > holding either of them invoker lock or event handler lock causes this. > > > > Here is a new webrev with those hunks removed. It's sufficient to grab > > the locks again in invoke_completeInvokeRequest() when clearing the > > global references in order to not get those failures we've seen when > > the fix for JDK-4858370 was in place. > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ > > > > Testing done: > > ?-?com/sun/jdi/InvokeTest.java?com/sun/jdi/InvokeHangTest.java and > > ? ?sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. > > ?- regular com/sun/jdi test set: no regressions > > > > Note that there are some rare cases where OomDebugTest times out which > > seems to be caused by the GC, though. See the bug for details. Since > > this problem is rare, it's still worthwhile having that test included. > > If it turns out a problem in practice we could consider disabling the > > test. > > > > Thoughts? > > > > Cheers, > > Severin > ? From alexander.kulyakhtin at oracle.com Fri Apr 29 13:12:28 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 29 Apr 2016 06:12:28 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> Hi, Could you, please, review these test-only changes (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the modules info as returned by the JVMTI" Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/ The new test verifies that JVMTI returns the correct info about the modules loaded at the application startup. It also verifies that the returned info is consistent with the same info returned by the Java API. It then loads a new named module and checks the correctness of the JVMTI info again. Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. Best regards, Alexander From Alan.Bateman at oracle.com Fri Apr 29 13:32:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Apr 2016 14:32:28 +0100 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> References: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> Message-ID: <5723626C.6050005@oracle.com> On 29/04/2016 14:12, Alexander Kulyakhtin wrote: > : > > Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. > The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. > Just to mention that we will doing a refresh from the jake forest into jdk9/dev next week and as part of this we have rev'ed the required version of jtreg to 4.2 b02. All the changes that we need for this update are in the jtreg repo. -Alan From daniel.daugherty at oracle.com Fri Apr 29 14:18:43 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Apr 2016 08:18:43 -0600 Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <890dc06b-99b7-4105-b734-9d9df227d74c@default> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> <88b669d0-82cb-48d5-ba40-878127fce72c@default> <57221B97.5040506@oracle.com> <890dc06b-99b7-4105-b734-9d9df227d74c@default> Message-ID: <57236D43.1020704@oracle.com> Thanks for the additional details. I'm good with the concept of this fix. > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ General comment Please update the copyright years before you push. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/EventHandler.java No comments. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java L763: if(!isShuttingDown()) { Nit: please add a space between 'if' and '('. Thumbs up. Dan P.S. Part of me wonders if this line: L764: MessageOutput.println("Input stream closed."); should change to: L764: MessageOutput.println("Input stream closed unexpectedly."); But that would likely require updating the tests that look for this pattern. Probably not worth it. On 4/28/16 11:55 PM, Sharath Ballal wrote: > > Hi Dan, > > The debugger has received a ?vmDeathEvent? and as part of handling > this event, the System.exit() is being called (handleExitEvent() in > EventHandler.java). So the fact that debuggee has finished executing, > is known to the debugger and the debugger is explicitly cleaning up > after that. This is similar to the breakpoint you mentioned. Instead > of breakpoint, we have an event. Now as part of the explicit cleanup > the readLine() (which is always blocking) sometimes returns with a > ?null?. Since we know we are cleaning up and we also know that the > debuggee has done executing, I am avoiding printing the error message. > > -Sharath Ballal > > *From:*Daniel D. Daugherty > *Sent:* Thursday, April 28, 2016 7:48 PM > *To:* Sharath Ballal; Staffan Larsen > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: JDK-8154144 Tests in com/sun/jdi fails > intermittently with "jdb input stream closed prematurely > > > When JDB is done, as part of the shutdown it calls System.exit() > > at Env.java:92 in a different thread 'event-handler'. > > Based on the above line from below, I'm even more convinced that > this bug is hit because the debuggee VM is allowed to run off the > end of main() and that creates a race between debuggee VM's attempt > to exit and the debugger trying to control the test execution. > > While this fix makes this bug "go away", I don't think this is the > right solution. You're basically trying to harden our ability to > handle this race condition instead of closing the race condition. > > I'll repeat part of the comment that I added to the bug on 04.13: > > > One possible solution is to add a breakpoint after main() returns and change > > the debuggee <-> debugger protocol to always expect one final breakpoint. > > Positive enforcement that the test reaches that point and it should catch any > > accidental "run of the end of main()" issues. > > Dan > > On 4/28/16 2:25 AM, Sharath Ballal wrote: > > Hi Staffan, > > The root cause of this problem is that BufferedReader.readLine() > is intermittently returning 'null' during System.exit(0). > > In TTY.java:751 we are always blocking on readLine(). Whenever a > user enters a command in JDB, the readLine() returns the command, > which gets executed. This is running in the 'main' thread. > > When JDB is done, as part of the shutdown it calls System.exit() > at Env.java:92 in a different thread 'event-handler'. > > Usually (in the passing cases) calling System.exit() is the end of > the process and readLine() doesn't return 'null', but in the > failing case readLine() at TTY.java:751 returns 'null'. This > causes the string "Input stream closed." to be printed. The jtreg > testcase looks for this string to decide that the testcase failed. > > The fix I have done is avoiding the print because we know that we > are shutting down and hence can discard the ?null? returned by > readLine(). > > Regarding the testing, I have run few of the failing jtreg > testcases about 200 times and not seen the problem (earlier I was > able to recreate without the fix). I have to do other tests, but > sent for review to do it in parallel. > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > > > 708 BufferedReader in = > 709 new BufferedReader(new InputStreamReader(System.in)); > ....... > ....... > 748 // Process interactive commands. > 749 MessageOutput.printPrompt(); > 750 while (true) { > 751 String ln = in.readLine(); > 752 if (ln == null) { > 753 MessageOutput.println("Input stream closed."); > 754 ln = "quit"; > 755 } > > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java > > > 79 static void shutdown(String message) { > 80 if (connection != null) { > 81 try { > 82 connection.disposeVM(); > 83 } catch (VMDisconnectedException e) { > 84 // Shutting down after the VM has gone away. This is > 85 // not an error, and we just ignore it. > 86 } > 87 } > 88 if (message != null) { > 89 MessageOutput.lnprint(message); > 90 MessageOutput.println(); > 91 } > 92 System.exit(0); > 93 } > > -Sharath Ballal > > *From:*Staffan Larsen > *Sent:* Thursday, April 28, 2016 1:17 PM > *To:* Sharath Ballal > *Cc:* serviceability-dev at openjdk.java.net > > *Subject:* Re: RFR: JDK-8154144 Tests in com/sun/jdi fails > intermittently with "jdb input stream closed prematurely > > Hi Sharath, > > Can you explain more how this help with the problem in the bug? > > It looks like you are trying to avoid a race by not printing the > "Input stream closed.? message while shutting down. You added this: > > *136 ((TTY)notifier).setShuttingDown(true);* > > 137 Env.shutdown(shutdownMessageKey); > > The call on line 137 will result in a System.exit(0) call if I am > reading the code right. So adding the shutdown flag to line 136 > will maybe make the race smaller, but isn?t really solving it? > > What kind of testing have you run this fix through? > > Thanks, > > /Staffan > > On 28 apr. 2016, at 09:22, Sharath Ballal > > > wrote: > > Hi, > > Pls review the change for bug > > JDK-8154144 > - Tests in > com/sun/jdi fails intermittently with "jdb input stream closed > prematurely > > Webrev: > > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ > > > -Sharath Ballal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harold.seigel at oracle.com Fri Apr 29 18:00:55 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 29 Apr 2016 14:00:55 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. Message-ID: Hi, Please review this extra small fix for test TimedAcquireLeak.java. The test was broken by the recent change to add module information to the JMAP class histogram. This fixes the test's regular expression to handle the possible additional module information. Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 Thanks! Harold From christian.tornqvist at oracle.com Fri Apr 29 18:14:51 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 29 Apr 2016 14:14:51 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: <1fd101d1a243$067451d0$135cf570$@oracle.com> Hi Harold, This looks good, thanks for fixing this! Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of harold seigel Sent: Friday, April 29, 2016 2:01 PM To: serviceability-dev at openjdk.java.net Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. Hi, Please review this extra small fix for test TimedAcquireLeak.java. The test was broken by the recent change to add module information to the JMAP class histogram. This fixes the test's regular expression to handle the possible additional module information. Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 Thanks! Harold From harold.seigel at oracle.com Fri Apr 29 18:16:40 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 29 Apr 2016 14:16:40 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: <1fd101d1a243$067451d0$135cf570$@oracle.com> References: <1fd101d1a243$067451d0$135cf570$@oracle.com> Message-ID: <680bcba2-835e-9580-4bfc-823b9865a72d@oracle.com> Thanks Christian! Harold On 4/29/2016 2:14 PM, Christian Tornqvist wrote: > Hi Harold, > > This looks good, thanks for fixing this! > > Thanks, > Christian > > -----Original Message----- > From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of harold seigel > Sent: Friday, April 29, 2016 2:01 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. > > Hi, > > Please review this extra small fix for test TimedAcquireLeak.java. The test was broken by the recent change to add module information to the JMAP class histogram. This fixes the test's regular expression to handle the possible additional module information. > > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 > > Thanks! Harold > > From ysr1729 at gmail.com Fri Apr 29 18:26:46 2016 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 29 Apr 2016 11:26:46 -0700 Subject: PerfData counter: sun.gc.policy.generations in JDK 8 In-Reply-To: <5710F000.6070708@oracle.com> References: <556E1D31.1040507@oracle.com> <5710F000.6070708@oracle.com> Message-ID: Sorry this fell off my plate. I'll dig up the test Jon pointed me to and see how i can write one for this, then update the old webrev. I'll try and get that done in the next few days. thanks for the reminder! \ -- ramki On Fri, Apr 15, 2016 at 6:43 AM, Stefan Karlsson wrote: > Hi Ramki and Jon, > > What's the status of this review thread? The bug is still open and > targeted for JDK 9. > > Thanks, > StefanK > > > On 2015-06-03 08:15, Srinivas Ramakrishna wrote: > > Thanks Jon for the review and the pointer to the test. I'll get back to > you later this week with a suitable test. > > -- Ramki > > ysr1729 > > On Jun 2, 2015, at 14:16, Jon Masamitsu < > jon.masamitsu at oracle.com> wrote: > > Ramki, > > Changes look good. > > I'm guessing you tested by generating the > perfdata by hand and verifying the contents > of the perfdata. Do you think a test can > be written to verify the change? If you look at > > test/gc/metaspace/TestMetaspacePerfCounters.java > > in your repository I think that is an example that > can be followed. > > It's a jtreg test. > > http://openjdk.java.net/jtreg/ > > Jon > > On 06/01/2015 11:39 AM, Srinivas Ramakrishna wrote: > > Thanks for the review of the patch for 8-dev (from the ticket), Staffan. > > Sorry for the delay in getting the official webrev out -- it took me a > while to first get set up with an hs9 repo (thanks Jon!) and then get my > openjdk credentials updated (thanks Mark!). > > Here's the webrev against hs9 for official review:- > > http://cr.openjdk.java.net/~ysr/JDK-8080345/webrev.00/ > > I built and tested the change (on both 8-dev whose patch was attached with > the original bug, as well as this with hs9) and verified that the counter > value for generations, in the perfdata file, was now 2 instead of the > previous 3. > > thanks! > -- ramki > > > On Mon, May 18, 2015 at 1:22 AM, Staffan Larsen < > staffan.larsen at oracle.com> wrote: > >> Looks like a good patch to me. >> >> /Staffan >> >> On 14 maj 2015, at 18:12, Srinivas Ramakrishna < >> ysr1729 at gmail.com> wrote: >> >> >> https://bugs.openjdk.java.net/browse/JDK-8080345 >> >> >> >> On Wed, May 13, 2015 at 1:08 PM, Srinivas Ramakrishna < >> ysr1729 at gmail.com> wrote: >> >>> >>> With perm gen going away (and being replaced by metaspace) in JDK 8, it >>> makes sense that the counter >>> sun.gc.policy.generations should be "2", rather than "3". However, in >>> JDK 8 that counter still says 3. >>> As I understand, the intention was that this counter would allow you to >>> (for example) know the range of >>> the sun.gc.generation.$num.* counters describing each of $num < >>> sun.gc.policy.generations in the heap. >>> Recall that the erstwhile perm gen in JDK 7 used to be synonymous with >>> sun.gc.generation.2, but the >>> JDK 8 avatars are now sun.gc.metaspace and sun.gc.compressedclassspace. >>> >>> The fix is simple, and I can submit a patch. Is there an existing bug >>> for this? >>> >>> thanks! >>> -- ramki >>> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Apr 29 19:19:45 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 Apr 2016 12:19:45 -0700 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: Apologies for taking over here ... This test is maintained externally in JSR166 CVS. We prefer a version that works well with both old and new outputs. I suggest instead "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; Does that work with latest serviceability changes? On Fri, Apr 29, 2016 at 11:00 AM, harold seigel wrote: > Hi, > > Please review this extra small fix for test TimedAcquireLeak.java. The test > was broken by the recent change to add module information to the JMAP class > histogram. This fixes the test's regular expression to handle the possible > additional module information. > > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 > > Thanks! Harold > From harold.seigel at oracle.com Fri Apr 29 19:30:04 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 29 Apr 2016 15:30:04 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: Hi Martin, Sure. I'll send out another RFR shortly. Harold On 4/29/2016 3:19 PM, Martin Buchholz wrote: > Apologies for taking over here ... This test is maintained externally > in JSR166 CVS. We prefer a version that works well with both old and > new outputs. I suggest instead > > "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; > > Does that work with latest serviceability changes? > > On Fri, Apr 29, 2016 at 11:00 AM, harold seigel > wrote: >> Hi, >> >> Please review this extra small fix for test TimedAcquireLeak.java. The test >> was broken by the recent change to add module information to the JMAP class >> histogram. This fixes the test's regular expression to handle the possible >> additional module information. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 >> >> Thanks! Harold >> From harold.seigel at oracle.com Fri Apr 29 19:32:42 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 29 Apr 2016 15:32:42 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: Please review this updated webrev that uses Martin's fix: New webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727.1/ Thanks, Harold On 4/29/2016 3:19 PM, Martin Buchholz wrote: > Apologies for taking over here ... This test is maintained externally > in JSR166 CVS. We prefer a version that works well with both old and > new outputs. I suggest instead > > "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; > > Does that work with latest serviceability changes? > > On Fri, Apr 29, 2016 at 11:00 AM, harold seigel > wrote: >> Hi, >> >> Please review this extra small fix for test TimedAcquireLeak.java. The test >> was broken by the recent change to add module information to the JMAP class >> histogram. This fixes the test's regular expression to handle the possible >> additional module information. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 >> >> Thanks! Harold >> From serguei.spitsyn at oracle.com Fri Apr 29 19:33:40 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Apr 2016 12:33:40 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1461920166.3712.19.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> Message-ID: <5723B714.7000503@oracle.com> On 4/29/16 01:56, Severin Gehwolf wrote: > Hi Serguei, > > On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: >> Hi Severin, >> >> The fix looks good in general. >> I'm testing both fixes together at the moment. > That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. > >> A couple of questions... >> >> It seems, there are more places where an invokerLock critical section is missed. > Right. > >> The following functions: >> - invoker_enableInvokeRequests > This should be fixed with the patch for JDK-8154529 > >> - invokeConstructor >> - invokeStatic >> - invokeNonvirtual >> - invokeVirtual >> - saveGlobalRef > Correct. The intent would be to fix the callsites of saveGlobalRef. If > we fix invoke* then saveGlobalRef should not be an issue. I didn't want > to include this in this fix since it's pretty hairy and would like to > fix this in incremental steps. > >> The first function is easy to fix. >> The last 5 functions are called from the invoker_doInvoke() that we already had a problem with. >> I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time? > I'm not sure yet. Perhaps locking only while saveGlobalRef is being > called in invoke* functions will help. > >> I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues. > Please keep me in the loop about your test results. Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are all passed. I also ran the 4 previously failed tests in big loops of 1000 runs: com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java com/sun/jdi/InterfaceMethodsTest.java com/sun/jdi/OomDebugTest.java (new test introduced in the webrev) The OomDebugTest.java failed with a timeout (most likely, a deadlock). Please, find the OomDebugTest.jtr file in attachments. Thanks, Serguei > > Thanks for your help! > > Cheers, > Severin > >> Thanks, >> Serguei >> >> >> On 4/28/16 02:00, Severin Gehwolf wrote: >>> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: >>>>> Hi Severin, >>>>> >>>>> I postpone a push for this fix. >>>>> >>>>> There are two nsk.jdi test failures (they look like deadlocks): >>>>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) >>>>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>>>> >>>>> and one jtreg sun/com/jdi failure (it looks like a deadlock too): >>>>> com/sun/jdi/InvokeHangTes.java >>>>> >>>>> >>>>> I'll double check if these failures are regressions caused by your fix >>>>> or not. >>>> I confirm, the failures above are new regressions introduced by the fix. >>>> The tests fail consistently with the fix and do not fail without the fix. >>> OK this was caused by the locking done in invoker_doInvoke(). Note that >>> holding either of them invoker lock or event handler lock causes this. >>> >>> Here is a new webrev with those hunks removed. It's sufficient to grab >>> the locks again in invoke_completeInvokeRequest() when clearing the >>> global references in order to not get those failures we've seen when >>> the fix for JDK-4858370 was in place. >>> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ >>> >>> Testing done: >>> - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and >>> sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. >>> - regular com/sun/jdi test set: no regressions >>> >>> Note that there are some rare cases where OomDebugTest times out which >>> seems to be caused by the GC, though. See the bug for details. Since >>> this problem is rare, it's still worthwhile having that test included. >>> If it turns out a problem in practice we could consider disabling the >>> test. >>> >>> Thoughts? >>> >>> Cheers, >>> Severin >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #Test Results (version 2) #Fri Apr 29 06:05:40 PDT 2016 #checksum:3e000f1cd4b3282c #-----testdescription----- $file=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi/OomDebugTest.java $root=/var/tmp/sspitsyn/jdk9.2/jdk/test author=Severin Gehwolf keywords=bug8153711 library=.. run=USER_SPECIFIED build TestScaffold VMConnection TargetListener TargetAdapter\nUSER_SPECIFIED compile -g OomDebugTest.java\nUSER_SPECIFIED main OomDebugTest OomDebugTestTarget test1\nUSER_SPECIFIED main OomDebugTest OomDebugTestTarget test2\nUSER_SPECIFIED main OomDebugTest OomDebugTestTarget test3\nUSER_SPECIFIED main OomDebugTest OomDebugTestTarget test4\nUSER_SPECIFIED main OomDebugTest OomDebugTestTarget test5\n source=OomDebugTest.java title=JDWP\: Memory Leak (global references not deleted after invokeMethod). #-----environment----- #-----testresult----- description=file\:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi/OomDebugTest.java elapsed=129113 0\:02\:09.113 end=Fri Apr 29 06\:05\:40 PDT 2016 environment=regtest execStatus=Error. Program `/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java' timed out (timeout set to 120000ms, elapsed time was 121059ms). hostname=sc11137378.us.oracle.com javatestOS=Linux 3.2.0-55-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.2 fcs b02 script=com.sun.javatest.regtest.RegressionScript sections=script_messages build compile build main build main start=Fri Apr 29 06\:03\:31 PDT 2016 test=com/sun/jdi/OomDebugTest.java testJDK=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk user.name=sspitsyn work=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/com/sun/jdi #section:script_messages ----------messages:(8/492)---------- JDK under test: /var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk java version "9-internal" Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-04-29-004440.sspitsyn.jdk9.2) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-04-29-004440.sspitsyn.jdk9.2, mixed mode) Library ..; kind: packages source directory: /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun class directory: /var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun #section:build ----------messages:(3/197)---------- command: build TestScaffold VMConnection TargetListener TargetAdapter reason: User specified action: run build TestScaffold VMConnection TargetListener TargetAdapter elapsed time (seconds): 0.001 result: Passed. All files up to date #section:compile ----------messages:(4/193)---------- command: compile -g /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi/OomDebugTest.java reason: User specified action: run compile -g OomDebugTest.java Mode: othervm elapsed time (seconds): 4.834 ----------configuration:(5/230)---------- javac compilation environment class path: /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi /var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi /var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun ----------rerun:(21/1470)*---------- DISPLAY=localhost:13.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac \\ -J-Dtest.src=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi \\ -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun \\ -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi \\ -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun \\ -J-Dtest.vm.opts= \\ -J-Dtest.tool.vm.opts= \\ -J-Dtest.compiler.opts= \\ -J-Dtest.java.opts= \\ -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dtest.timeout.factor=1.0 \\ -d /var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi \\ -sourcepath /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun \\ -classpath /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun \\ -g /var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi/OomDebugTest.java ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:build ----------messages:(3/95)---------- command: build OomDebugTest reason: Named class compiled on demand elapsed time (seconds): 0.0 result: Passed. All files up to date #section:main ----------messages:(4/175)---------- command: main OomDebugTest OomDebugTestTarget test1 reason: User specified action: run main OomDebugTest OomDebugTestTarget test1 Mode: othervm elapsed time (seconds): 2.462 ----------configuration:(0/0)---------- ----------System.out:(43/2380)---------- vmOpts: '-Xmx40m' javaOpts: '' JVM version:9-internal JDI version: 9.0 JVM description: Java Debug Interface (Reference Implementation) version 9.0 Java Debug Wire Protocol (Reference Implementation) version 9.0 JVM Debug Interface version 9.0 JVM version 9-internal (Java HotSpot(TM) 64-Bit Server VM, mixed mode, sharing) DEBUG: OomDebugTestTarget.main DEBUG: invoked constructor DEBUG: ------------> Running test1 DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 327471b5 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 4157f54e DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 90f6bfd DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 47f6473 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 15975490 DEBUG: Done invoking method via debugger. DEBUG: Done invoking method via debugger. DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 6b143ee9 DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 1936f0f5 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 6615435c DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 4909b8da DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 3a03464 DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 2d3fcdbd DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 617c74e5 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 6537cf78 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 67b6d4ae DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testMethod(FooCls)', foo == OomDebugTestTarget$FooCls at 34b7bfc0 DEBUG: Done invoking method via debugger. DEBUG: Finished running test 'test1'. DEBUG: More tests to run. Coninuing. ----------System.err:(2/80)---------- [10ms] run args: [OomDebugTestTarget, test1, OomDebugTestTarget] STATUS:Passed. ----------rerun:(19/1589)*---------- DISPLAY=localhost:13.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar \\ /var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java \\ -Dtest.src=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi \\ -Dtest.src.path=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun \\ -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi \\ -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun \\ -Dtest.vm.opts= \\ -Dtest.tool.vm.opts= \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dcompile.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dtest.timeout.factor=1.0 \\ com.sun.javatest.regtest.agent.MainWrapper /var/tmp/sspitsyn/tst/jdk9.2/JTwork/com/sun/jdi/OomDebugTest.d/main.0.jta OomDebugTestTarget test1 result: Passed. Execution successful #section:build ----------messages:(3/95)---------- command: build OomDebugTest reason: Named class compiled on demand elapsed time (seconds): 0.0 result: Passed. All files up to date #section:main ----------messages:(270/16605)---------- command: main OomDebugTest OomDebugTestTarget test2 reason: User specified action: run main OomDebugTest OomDebugTestTarget test2 Mode: othervm Timeout information: Running jstack on process 9040 2016-04-29 06:05:40 Full thread dump Java HotSpot(TM) 64-Bit Server VM (9-internal+0-2016-04-29-004440.sspitsyn.jdk9.2 mixed mode): "Attach Listener" #22 daemon prio=9 os_prio=0 tid=0x00007f6d80001000 nid=0x339a runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6d80001000 [0x339a] State: _call_back _has_called_back 1 _at_poll_safepoint 0 JavaThread state: _thread_blocked "Thread-1" #21 daemon prio=5 os_prio=0 tid=0x00007f6d60150800 nid=0x2404 in Object.wait() [0x00007f6d5bdfc000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6d60150800 [0x2404] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on <0x00000006d48042c0> (a com.sun.tools.jdi.EventQueueImpl) at java.lang.Object.wait(java.base at 9-internal/Object.java:516) at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 9-internal/EventQueueImpl.java:189) - waiting to re-lock in wait() <0x00000006d48042c0> (a com.sun.tools.jdi.EventQueueImpl) at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 9-internal/EventQueueImpl.java:96) at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 9-internal/EventQueueImpl.java:82) at TestScaffold$EventHandler.run(TestScaffold.java:252) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) "output reader" #20 prio=9 os_prio=0 tid=0x00007f6d60142000 nid=0x2403 runnable [0x00007f6d5befc000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native Thread: 0x00007f6d60142000 [0x2403] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_native at java.io.FileInputStream.readBytes(java.base at 9-internal/Native Method) at java.io.FileInputStream.read(java.base at 9-internal/FileInputStream.java:255) at java.io.BufferedInputStream.read1(java.base at 9-internal/BufferedInputStream.java:284) at java.io.BufferedInputStream.read(java.base at 9-internal/BufferedInputStream.java:345) - locked <0x00000006d496e5c8> (a java.lang.ProcessImpl$ProcessPipeInputStream) at sun.nio.cs.StreamDecoder.readBytes(java.base at 9-internal/StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(java.base at 9-internal/StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(java.base at 9-internal/StreamDecoder.java:178) - locked <0x00000006d48f64d0> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(java.base at 9-internal/InputStreamReader.java:185) at java.io.BufferedReader.fill(java.base at 9-internal/BufferedReader.java:161) at java.io.BufferedReader.readLine(java.base at 9-internal/BufferedReader.java:325) - locked <0x00000006d48f64d0> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(java.base at 9-internal/BufferedReader.java:390) at VMConnection.dumpStream(VMConnection.java:254) at VMConnection.access$000(VMConnection.java:35) at VMConnection$1.run(VMConnection.java:287) "output reader" #19 prio=9 os_prio=0 tid=0x00007f6d60140000 nid=0x2402 runnable [0x00007f6d9410f000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native Thread: 0x00007f6d60140000 [0x2402] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_native at java.io.FileInputStream.readBytes(java.base at 9-internal/Native Method) at java.io.FileInputStream.read(java.base at 9-internal/FileInputStream.java:255) at java.io.BufferedInputStream.read1(java.base at 9-internal/BufferedInputStream.java:284) at java.io.BufferedInputStream.read(java.base at 9-internal/BufferedInputStream.java:345) - locked <0x00000006d4970688> (a java.lang.ProcessImpl$ProcessPipeInputStream) at sun.nio.cs.StreamDecoder.readBytes(java.base at 9-internal/StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(java.base at 9-internal/StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(java.base at 9-internal/StreamDecoder.java:178) - locked <0x00000006d48b8f88> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(java.base at 9-internal/InputStreamReader.java:185) at java.io.BufferedReader.fill(java.base at 9-internal/BufferedReader.java:161) at java.io.BufferedReader.readLine(java.base at 9-internal/BufferedReader.java:325) - locked <0x00000006d48b8f88> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(java.base at 9-internal/BufferedReader.java:390) at VMConnection.dumpStream(VMConnection.java:254) at VMConnection.access$000(VMConnection.java:35) at VMConnection$1.run(VMConnection.java:287) "JDI Target VM Interface" #17 daemon prio=5 os_prio=0 tid=0x00007f6d60138800 nid=0x2400 runnable [0x00007f6d5bffe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native Thread: 0x00007f6d60138800 [0x2400] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_native at java.net.SocketInputStream.socketRead0(java.base at 9-internal/Native Method) at java.net.SocketInputStream.socketRead(java.base at 9-internal/SocketInputStream.java:116) at java.net.SocketInputStream.read(java.base at 9-internal/SocketInputStream.java:170) at java.net.SocketInputStream.read(java.base at 9-internal/SocketInputStream.java:141) at java.net.SocketInputStream.read(java.base at 9-internal/SocketInputStream.java:223) at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 9-internal/SocketTransportService.java:414) - locked <0x00000006d49ba8c0> (a java.lang.Object) at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 9-internal/TargetVM.java:118) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) "JDI Internal Event Handler" #18 daemon prio=5 os_prio=0 tid=0x00007f6d60133000 nid=0x23fa in Object.wait() [0x00007f6d94211000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6d60133000 [0x23fa] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on <0x00000006d4801290> (a com.sun.tools.jdi.EventQueueImpl) at java.lang.Object.wait(java.base at 9-internal/Object.java:516) at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 9-internal/EventQueueImpl.java:189) - waiting to re-lock in wait() <0x00000006d4801290> (a com.sun.tools.jdi.EventQueueImpl) at com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 9-internal/EventQueueImpl.java:124) at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 9-internal/InternalEventHandler.java:54) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) "process reaper" #14 daemon prio=10 os_prio=0 tid=0x00007f6d600e9800 nid=0x23ba runnable [0x00007f6de404f000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native Thread: 0x00007f6d600e9800 [0x23ba] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_native at java.lang.ProcessHandleImpl.waitForProcessExit0(java.base at 9-internal/Native Method) at java.lang.ProcessHandleImpl.lambda$completion$2(java.base at 9-internal/ProcessHandleImpl.java:133) at java.lang.ProcessHandleImpl$$Lambda$15/2007848456.run(java.base at 9-internal/Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-internal/ThreadPoolExecutor.java:1158) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-internal/ThreadPoolExecutor.java:632) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) "MainThread" #13 prio=5 os_prio=0 tid=0x00007f6de0490000 nid=0x238e in Object.wait() [0x00007f6d94310000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6de0490000 [0x238e] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on at java.lang.Object.wait(java.base at 9-internal/Object.java:516) at com.sun.tools.jdi.TargetVM.waitForReply(jdk.jdi at 9-internal/TargetVM.java:300) - waiting to re-lock in wait() <0x00000006d478d620> (a com.sun.tools.jdi.Packet) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(jdk.jdi at 9-internal/VirtualMachineImpl.java:1088) at com.sun.tools.jdi.PacketStream.waitForReply(jdk.jdi at 9-internal/PacketStream.java:69) at com.sun.tools.jdi.JDWP$ArrayType$NewInstance.waitForReply(jdk.jdi at 9-internal/JDWP.java:3680) at com.sun.tools.jdi.JDWP$ArrayType$NewInstance.process(jdk.jdi at 9-internal/JDWP.java:3656) at com.sun.tools.jdi.ArrayTypeImpl.newInstance(jdk.jdi at 9-internal/ArrayTypeImpl.java:46) at OomDebugTest.test2(OomDebugTest.java:207) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:531) at OomDebugTest.runTests(OomDebugTest.java:150) at TestScaffold.startTests(TestScaffold.java:431) at OomDebugTest.main(OomDebugTest.java:390) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) "Service Thread" #11 daemon prio=9 os_prio=0 tid=0x00007f6de0458800 nid=0x236c runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de0458800 [0x236c] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked "Common-Cleaner" #10 daemon prio=8 os_prio=0 tid=0x00007f6de033b800 nid=0x236b in Object.wait() [0x00007f6d94615000] java.lang.Thread.State: TIMED_WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6de033b800 [0x236b] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on at java.lang.ref.ReferenceQueue.remove(java.base at 9-internal/ReferenceQueue.java:151) - waiting to re-lock in wait() <0x00000006d4d3a870> (a java.lang.ref.ReferenceQueue$Lock) at jdk.internal.ref.CleanerImpl.run(java.base at 9-internal/CleanerImpl.java:148) at java.lang.Thread.run(java.base at 9-internal/Thread.java:843) at jdk.internal.misc.InnocuousThread.run(java.base at 9-internal/InnocuousThread.java:122) "Sweeper thread" #9 daemon prio=9 os_prio=0 tid=0x00007f6de02e1800 nid=0x2369 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02e1800 [0x2369] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked "C1 CompilerThread2" #8 daemon prio=9 os_prio=0 tid=0x00007f6de02df000 nid=0x2368 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02df000 [0x2368] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked No compile task "C2 CompilerThread1" #7 daemon prio=9 os_prio=0 tid=0x00007f6de02dc800 nid=0x2367 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02dc800 [0x2367] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked No compile task "C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00007f6de02da000 nid=0x2366 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02da000 [0x2366] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked No compile task "Signal Dispatcher" #5 daemon prio=9 os_prio=0 tid=0x00007f6de02d7800 nid=0x2365 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02d7800 [0x2365] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked "Reference Pending List Locker" #4 daemon prio=9 os_prio=0 tid=0x00007f6de02d5800 nid=0x2364 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked Thread: 0x00007f6de02d5800 [0x2364] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f6de02af800 nid=0x2363 in Object.wait() [0x00007f6d956fd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6de02af800 [0x2363] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on <0x00000006d4d09548> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(java.base at 9-internal/ReferenceQueue.java:151) - waiting to re-lock in wait() <0x00000006d4d09548> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(java.base at 9-internal/ReferenceQueue.java:172) at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 9-internal/Finalizer.java:216) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f6de02ad800 nid=0x2362 in Object.wait() [0x00007f6d957fe000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6de02ad800 [0x2362] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on <0x00000006d4d08c90> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(java.base at 9-internal/Object.java:516) at java.lang.ref.Reference.tryHandlePending(java.base at 9-internal/Reference.java:193) - waiting to re-lock in wait() <0x00000006d4d08c90> (a java.lang.ref.Reference$Lock) at java.lang.ref.Reference$ReferenceHandler.run(java.base at 9-internal/Reference.java:155) "main" #1 prio=5 os_prio=0 tid=0x00007f6de001a000 nid=0x2353 in Object.wait() [0x00007f6deabfd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked Thread: 0x00007f6de001a000 [0x2353] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_blocked at java.lang.Object.wait(java.base at 9-internal/Native Method) - waiting on <0x00000006d4b86768> (a java.lang.Thread) at java.lang.Thread.join(java.base at 9-internal/Thread.java:1352) - waiting to re-lock in wait() <0x00000006d4b86768> (a java.lang.Thread) at java.lang.Thread.join(java.base at 9-internal/Thread.java:1426) at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:74) "VM Thread" os_prio=0 tid=0x00007f6de0299000 nid=0x2361 runnable "GC Thread#0" os_prio=0 tid=0x00007f6de0037800 nid=0x2354 runnable "GC Thread#1" os_prio=0 tid=0x00007f6de0039800 nid=0x2355 runnable "GC Thread#2" os_prio=0 tid=0x00007f6de003b800 nid=0x2356 runnable "GC Thread#3" os_prio=0 tid=0x00007f6de003d800 nid=0x2357 runnable "G1 Main Marker" os_prio=0 tid=0x00007f6de008a800 nid=0x235d runnable "G1 Marker#0" os_prio=0 tid=0x00007f6de008c800 nid=0x235e runnable "G1 Refine#0" os_prio=0 tid=0x00007f6de0046000 nid=0x235b runnable "G1 Refine#1" os_prio=0 tid=0x00007f6de0044000 nid=0x235a runnable "G1 Refine#2" os_prio=0 tid=0x00007f6de0042000 nid=0x2359 runnable "G1 Refine#3" os_prio=0 tid=0x00007f6de0040000 nid=0x2358 runnable "G1 Young RemSet Sampling" os_prio=0 tid=0x00007f6de0048000 nid=0x235c runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007f6de045c000 nid=0x236e waiting on condition JNI global references: 337 --- Timeout information end. elapsed time (seconds): 121.066 ----------configuration:(0/0)---------- ----------System.out:(24/1088)---------- vmOpts: '-Xmx40m' javaOpts: '' JVM version:9-internal JDI version: 9.0 JVM description: Java Debug Interface (Reference Implementation) version 9.0 Java Debug Wire Protocol (Reference Implementation) version 9.0 JVM Debug Interface version 9.0 JVM version 9-internal (Java HotSpot(TM) 64-Bit Server VM, mixed mode, sharing) DEBUG: OomDebugTestTarget.main DEBUG: invoked constructor DEBUG: ------------> Running test2 DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 327471b5 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 4157f54e DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 90f6bfd DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 47f6473 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 15975490 DEBUG: Done invoking method via debugger. DEBUG: invoked 'void testPrimitive(byte[])', foo == [B at 6b143ee9 DEBUG: Done invoking method via debugger. Timeout signalled after 120 seconds ----------System.err:(1/65)---------- [10ms] run args: [OomDebugTestTarget, test2, OomDebugTestTarget] ----------rerun:(19/1589)*---------- DISPLAY=localhost:13.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar \\ /var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java \\ -Dtest.src=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi \\ -Dtest.src.path=/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun/jdi:/var/tmp/sspitsyn/jdk9.2/jdk/test/com/sun \\ -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi \\ -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun/jdi:/var/tmp/sspitsyn/tst/jdk9.2/JTwork/classes/com/sun \\ -Dtest.vm.opts= \\ -Dtest.tool.vm.opts= \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dcompile.jdk=/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dtest.timeout.factor=1.0 \\ com.sun.javatest.regtest.agent.MainWrapper /var/tmp/sspitsyn/tst/jdk9.2/JTwork/com/sun/jdi/OomDebugTest.d/main.1.jta OomDebugTestTarget test2 result: Error. Program `/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java' timed out (timeout set to 120000ms, elapsed time was 121059ms). test result: Error. Program `/var/tmp/sspitsyn/jdk9.2/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java' timed out (timeout set to 120000ms, elapsed time was 121059ms). From martinrb at google.com Fri Apr 29 19:39:22 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 Apr 2016 12:39:22 -0700 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: Thanks, looks good. (In future, please notify code owners using the relevant mailing lists, in this case core-libs-dev) On Fri, Apr 29, 2016 at 12:32 PM, harold seigel wrote: > Please review this updated webrev that uses Martin's fix: > > New webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727.1/ > > Thanks, Harold > > > On 4/29/2016 3:19 PM, Martin Buchholz wrote: >> >> Apologies for taking over here ... This test is maintained externally >> in JSR166 CVS. We prefer a version that works well with both old and >> new outputs. I suggest instead >> >> "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; >> >> Does that work with latest serviceability changes? >> >> On Fri, Apr 29, 2016 at 11:00 AM, harold seigel >> wrote: >>> >>> Hi, >>> >>> Please review this extra small fix for test TimedAcquireLeak.java. The >>> test >>> was broken by the recent change to add module information to the JMAP >>> class >>> histogram. This fixes the test's regular expression to handle the >>> possible >>> additional module information. >>> >>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ >>> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 >>> >>> Thanks! Harold >>> > From harold.seigel at oracle.com Fri Apr 29 19:42:18 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 29 Apr 2016 15:42:18 -0400 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: <05461681-4282-0607-7b51-bf9a0eacea08@oracle.com> Thanks for the review. Harold On 4/29/2016 3:39 PM, Martin Buchholz wrote: > Thanks, looks good. > > (In future, please notify code owners using the relevant mailing > lists, in this case core-libs-dev) > > On Fri, Apr 29, 2016 at 12:32 PM, harold seigel > wrote: >> Please review this updated webrev that uses Martin's fix: >> >> New webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727.1/ >> >> Thanks, Harold >> >> >> On 4/29/2016 3:19 PM, Martin Buchholz wrote: >>> Apologies for taking over here ... This test is maintained externally >>> in JSR166 CVS. We prefer a version that works well with both old and >>> new outputs. I suggest instead >>> >>> "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; >>> >>> Does that work with latest serviceability changes? >>> >>> On Fri, Apr 29, 2016 at 11:00 AM, harold seigel >>> wrote: >>>> Hi, >>>> >>>> Please review this extra small fix for test TimedAcquireLeak.java. The >>>> test >>>> was broken by the recent change to add module information to the JMAP >>>> class >>>> histogram. This fixes the test's regular expression to handle the >>>> possible >>>> additional module information. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ >>>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 >>>> >>>> Thanks! Harold >>>> From david.holmes at oracle.com Fri Apr 29 23:04:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 30 Apr 2016 09:04:01 +1000 Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. In-Reply-To: References: Message-ID: On 30/04/2016 5:39 AM, Martin Buchholz wrote: > Thanks, looks good. > > (In future, please notify code owners using the relevant mailing > lists, in this case core-libs-dev) Harold was given incorrect information as to the owning area in this case. Cheers, David > On Fri, Apr 29, 2016 at 12:32 PM, harold seigel > wrote: >> Please review this updated webrev that uses Martin's fix: >> >> New webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727.1/ >> >> Thanks, Harold >> >> >> On 4/29/2016 3:19 PM, Martin Buchholz wrote: >>> >>> Apologies for taking over here ... This test is maintained externally >>> in JSR166 CVS. We prefer a version that works well with both old and >>> new outputs. I suggest instead >>> >>> "(?m)^ *[0-9]+: +([0-9]+) +[0-9]+ +\\Q"+className+"\\E(?:$| )"; >>> >>> Does that work with latest serviceability changes? >>> >>> On Fri, Apr 29, 2016 at 11:00 AM, harold seigel >>> wrote: >>>> >>>> Hi, >>>> >>>> Please review this extra small fix for test TimedAcquireLeak.java. The >>>> test >>>> was broken by the recent change to add module information to the JMAP >>>> class >>>> histogram. This fixes the test's regular expression to handle the >>>> possible >>>> additional module information. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/ >>>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8155727 >>>> >>>> Thanks! Harold >>>> >>