From david.holmes at oracle.com Tue Mar 1 02:16:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Mar 2016 12:16:44 +1000 Subject: RFR[8u-dev]: 8139040: Fix initializations before ShouldNotReachHere() etc. and enable -Wuninitialized on linux. In-Reply-To: <9aa9caa4-ec27-4cf8-bbb1-683d5989b488@default> References: <56C2F6BB.3040508@oracle.com> <56CC2808.6090800@oracle.com> <728a91ae-67e8-4249-a0ab-a2b2eee650b9@default> <9aa9caa4-ec27-4cf8-bbb1-683d5989b488@default> Message-ID: <56D4FB8C.4040704@oracle.com> On 29/02/2016 8:45 PM, Cheleswer Sahu wrote: > Hi David, > > Mattis and I feel it's best to leave the change for "-Wuninitialized " in backport, do you agree with this opinion? That's fine. Thanks, David > Regards, > Cheleswer > > > -----Original Message----- > From: Mattis Castegren > Sent: Wednesday, February 24, 2016 3:45 PM > To: David Holmes; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net > Cc: Mattis Castegren > Subject: RE: RFR[8u-dev]: 8139040: Fix initializations before ShouldNotReachHere() etc. and enable -Wuninitialized on linux. > > Hi > > Regarding: "You can add a check for gcc >= 4.8 when enabling this flag. Although our official compilers are quite old for 8u there may be other community members who use later versions." > > If we don't build with this flag in our official builds, I think there is a pretty big risk that we could break things for any OpenJDK engineers who build with 4.8. Adding a new warning flag for those engineers will not give them any benefit, it will only add the risk that they can't build with their gcc version. I suggest we keep the change as it is, and don't include the -Wuninitialized flag on Linux > > Kind Regards > /Mattis > > -----Original Message----- > From: David Holmes > Sent: den 23 februari 2016 10:36 > To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[8u-dev]: 8139040: Fix initializations before ShouldNotReachHere() etc. and enable -Wuninitialized on linux. > > Hi Cheleswer, > > On 23/02/2016 7:06 PM, Cheleswer Sahu wrote: >> Could somebody please review the below backport changes. >> >> Hi, >> >> Please review the code changes for backport "https://bugs.openjdk.java.net/browse/JDK-8139040". >> >> JBS link: https://bugs.openjdk.java.net/browse/JDK-8139040 >> JDK9 changeset: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/825cee2cd7a6 >> JDK9 review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-Octobe >> r/016005.html >> >> JDK8u webrev: http://cr.openjdk.java.net/~csahu/8139040/ > > Looks ok. > >> List of files not included in this backport: >> src/share/vm/classfile/compactHashtable.cpp >> src/share/vm/opto/compile.hpp >> src/share/vm/opto/superword.cpp >> src/share/vm/runtime/arguments.cpp >> Reason: Above file are either not available in JDK8u or changes are not applicable. > > Ok. > >> make/linux/makefiles/gcc.make >> Reason: This file contain changes related "-Wuninitialized" flag which is available since gcc4.8 . JDK8u is supporting lower version of gcc, hence not included this fix. > > You can add a check for gcc >= 4.8 when enabling this flag. Although our official compilers are quite old for 8u there may be other community members who use later versions. > > Thanks, > David > ----- > >> >> Regards, >> Cheleswer >> From david.holmes at oracle.com Tue Mar 1 04:29:04 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Mar 2016 14:29:04 +1000 Subject: RFR(S): 8149557: Resource mark breaks printing to string stream In-Reply-To: References: <26852801ffaa4671a95ee2e1b0077e57@DEWDFE13DE09.global.corp.sap> <56CA5C7C.5040606@oracle.com> Message-ID: <56D51A90.7030508@oracle.com> Hi Goetz, On 29/02/2016 11:09 PM, Lindenmaier, Goetz wrote: > Hi David, Thomas, > > you are right, I need to check for NULL. I had the linux > case in mind. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.02/ I can't help but feel there is a bug in the Resource-area memory management code here. The problem as I understand it is that we have: void Symbol::print_symbol_on(outputStream* st) const { ResourceMark rm; st = st ? st : tty; st->print("%s", as_quoted_ascii()); } where we need the ResourceMark for the string returned by as_quoted_ascii. But if st is itself a resource-area object and needs to re-size in st->print then it does that in the context of the new ResourceMark, which fails the assert: "stringStream is re-allocated with a different ResourceMark." That seems to be the bug to me - a resource-area object that needs resizing should be able to do it in the context of an outer ResourceMark. :( So the workaround is to use a separate ResourceMark to call as_quoted_ascii and then copy the result to a malloc'd string, which is used for the st->print (which may realloc in the context of the existing outer ResourceMark) and is then free()'d. Yuck. :( Reluctantly Reviewed. Thanks, David > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Montag, 22. Februar 2016 01:55 >> To: Lindenmaier, Goetz ; 'Thomas St?fe' >> >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string stream >> >> On 19/02/2016 11:05 PM, Lindenmaier, Goetz wrote: >>> Hi Thomas, >>> >>> thanks for looking at this. >>> >>>> you should check the return value of os::strdup(). >>> strdup returns null on oom, %s should be ?null?, and >> >> What are you assuming takes care of %s to 'null' conversion? gcc printf >> may do it but AFAIK it is undefined at the C library level. >> >> David >> ----- >> >>> free handles null properly, too. So I think this is fine. >>> >>> If I remove the RM, I might break callers. E.g. >> TestLogTouchedMethods.java. >>> Also, in that test, all logged method names will accumulate in memory. >>> >>> Best regards, >>> Goetz. >>> >>> >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>> Sent: Thursday, February 11, 2016 9:41 AM >>> To: Lindenmaier, Goetz >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string >> stream >>> >>> Hi Goetz, >>> >>> Thank you for fixing this. I see you are restless :-) >>> >>> you should check the return value of os::strdup(). The change looks fine >> otherwise, though I wonder whether we could just omit the ResourceMark >> and using the one of the caller. At least it is inconsistent, because >> Symbol::print_utf8_on() does not have a ResourceMark either. >>> >>> Kind regards, Thomas >>> >>> >>> >>> On Thu, Feb 11, 2016 at 9:24 AM, Lindenmaier, Goetz >> > wrote: >>> Hi >>> >>> Please review this change. I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.01/ >>> >>> If a stringStream is passed to Symbol::print_symbol_on(), >>> assertion "stringStream is re-allocated with a different ResourceMark." can >> fire in stringStream::write(const char* s, size_t len). >>> This can be verified by running TestLogTouchedMethods.java after adding >> the patch below to the VM. >>> >>> My fix copies the string to locally managed memory before popping the >> ResoreceMark. >>> A better solution would be to guarantee enough space on the stream >>> before doing the resource mark, but outputStream has no such >>> method as 'ensureCapacity' or the like. >>> Alternatively the ResourceMark could be skipped altogether. >>> But then the aux memory used remains on the ResourceArea too long. >>> Also, various ResourceMarks have to be added in other places. >>> >>> Best regards, >>> Goetz. >>> >>> >>> --- a/src/share/vm/runtime/java.cpp Wed Jan 13 11:33:21 2016 +0100 >>> +++ b/src/share/vm/runtime/java.cpp Wed Feb 10 08:56:14 2016 +0100 >>> @@ -340,7 +340,10 @@ >>> } >>> >>> if (LogTouchedMethods && PrintTouchedMethodsAtExit) { >>> - Method::print_touched_methods(tty); >>> + ResourceMark rm; >>> + stringStream st(16); >>> + Method::print_touched_methods(&st); >>> + tty->print("%s", st.as_string()); >>> } >>> >>> if (PrintBiasedLockingStatistics) { >>> From david.holmes at oracle.com Tue Mar 1 05:30:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Mar 2016 15:30:39 +1000 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> Message-ID: <56D528FF.3030308@oracle.com> Hi Thomas, On 1/03/2016 3:23 AM, Thomas St?fe wrote: > Hi David, > > On Mon, Feb 29, 2016 at 4:44 AM, David Holmes > wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, Thomas St?fe wrote: > > Hi, > > please take a look at this proposed fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > This adds a replacement function os::strerror() as a drop-in for > strerror(), which has a number of issues. > > strerror() is unsafe to use and may cause (and has caused) > crashes in > multithreaded scenarios. It is also not ideal for log files > because of the > implicit localization of the error messages. > > For details please see the discussion under the bug report. > > > I just came across strerror_l, which is required to be thread-safe. > Is that a possible alternative? (I'm not sure how locale's are > obtained). > > > Sorry, I think this API is glibc only. At least I cannot find this in > our AIX headers, nor on Solaris. It is a POSIX API: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html added in 2006 but part of POSIX.1-2008. But as per Dalibor's link not necessarily available: "This function is missing on some platforms: glibc 2.3.6, Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, mingw, MSVC 9, Interix 3.5, BeOS. " Pity. > Otherwise what you have seems okay - though I do dislike having to > duplicate all that details already buried in the system > headers/library. Not sure we need to the long text at the VM level - > which would simplify things a bit. > > > I agree, I dislike this too. Like everyone else in this thread. But I > think this is a pragmatic solution. > > I am a bit stuck here - should we really get rid of the long text > feature? There are some callsites of strerror() in the hotspot where > arguably the long text is better suited: > - in assert_status() (see debug.hpp) - this ends up in the header of > error files, if this suddenly changes to a literalized errno, people may > be upset I added assert_status purely to expand on what the failing status was :) I'm happy to see EINVAL in that context rather than "invalid argument" (or whatever) :) > - when failing to write a heap dump file - see services/heapDumper.cpp. > Which ends as printout on the command line, I think. Maybe ... if it is an error the user can fix. > The safe option would be to provide both variants (short and long text). > Or, provide the safe, short variant for all logging calls - when > "EINVAL" is enough, and let users continue to use strerror() for those > few cases where the long text is needed. > > What do you think? Trying to decide what makes me least unhappy. :) Given you've already done the work I guess having long and short forms is okay. Thanks, David > Thanks, Thomas > > Thanks, > David > > > Please note that I did not yet change any call sites, although > all call > sites in the os namespace should already use the new function. I > wanted to > see whether there would be any general objections. > > Kind Regards, Thomas > > From thomas.stuefe at gmail.com Tue Mar 1 07:12:28 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Mar 2016 08:12:28 +0100 Subject: RFR(S): 8149557: Resource mark breaks printing to string stream In-Reply-To: <56D51A90.7030508@oracle.com> References: <26852801ffaa4671a95ee2e1b0077e57@DEWDFE13DE09.global.corp.sap> <56CA5C7C.5040606@oracle.com> <56D51A90.7030508@oracle.com> Message-ID: Hi David, On Tue, Mar 1, 2016 at 5:29 AM, David Holmes wrote: > Hi Goetz, > > On 29/02/2016 11:09 PM, Lindenmaier, Goetz wrote: > >> Hi David, Thomas, >> >> you are right, I need to check for NULL. I had the linux >> case in mind. >> New webrev: >> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.02/ >> > > I can't help but feel there is a bug in the Resource-area memory > management code here. The problem as I understand it is that we have: > > void Symbol::print_symbol_on(outputStream* st) const { > ResourceMark rm; > st = st ? st : tty; > st->print("%s", as_quoted_ascii()); > } > > where we need the ResourceMark for the string returned by as_quoted_ascii. > But if st is itself a resource-area object and needs to re-size in > st->print then it does that in the context of the new ResourceMark, which > fails the assert: "stringStream is re-allocated with a different > ResourceMark." That seems to be the bug to me - a resource-area object that > needs resizing should be able to do it in the context of an outer > ResourceMark. :( > > I think the way resource areas are designed this is not possible. ResourceArea is a thread-local memory stack (actually a linked list of chunks), and ResourceMark just a watermark into this stack. In order to "allocate in the context of any ResourceMark" on the stack above the call site, each ResourceMark would have to itself own an expandable arena. I think this would be more expensive and complicated. I also think cases like this are rare - where objects keep pointers to resource area storage and the objects themselves are handed up and down the stack. The only other case I know was Marcus' ttyLocker replacement message buffer for UL. > So the workaround is to use a separate ResourceMark to call > as_quoted_ascii and then copy the result to a malloc'd string, which is > used for the st->print (which may realloc in the context of the existing > outer ResourceMark) and is then free()'d. Yuck. :( > > Another workaround would have been to get rid of the ResourceMark altogether, because it is used inconsequently. Symbol class has a number of print functions, not all of those who use ResourceArea also establish ResourceMarks. E.g. Symbol::print_utf8_on(). But definitely, a comment in stringStream would help - warning the user that the expandable version of stringStream uses ResourceArea. Kind Regards, Thomas > Reluctantly Reviewed. > > Thanks, > David > > > > Best regards, >> Goetz. >> >> >> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Montag, 22. Februar 2016 01:55 >>> To: Lindenmaier, Goetz ; 'Thomas St?fe' >>> >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string >>> stream >>> >>> On 19/02/2016 11:05 PM, Lindenmaier, Goetz wrote: >>> >>>> Hi Thomas, >>>> >>>> thanks for looking at this. >>>> >>>> you should check the return value of os::strdup(). >>>>> >>>> strdup returns null on oom, %s should be ?null?, and >>>> >>> >>> What are you assuming takes care of %s to 'null' conversion? gcc printf >>> may do it but AFAIK it is undefined at the C library level. >>> >>> David >>> ----- >>> >>> free handles null properly, too. So I think this is fine. >>>> >>>> If I remove the RM, I might break callers. E.g. >>>> >>> TestLogTouchedMethods.java. >>> >>>> Also, in that test, all logged method names will accumulate in memory. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> Sent: Thursday, February 11, 2016 9:41 AM >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string >>>> >>> stream >>> >>>> >>>> Hi Goetz, >>>> >>>> Thank you for fixing this. I see you are restless :-) >>>> >>>> you should check the return value of os::strdup(). The change looks fine >>>> >>> otherwise, though I wonder whether we could just omit the ResourceMark >>> and using the one of the caller. At least it is inconsistent, because >>> Symbol::print_utf8_on() does not have a ResourceMark either. >>> >>>> >>>> Kind regards, Thomas >>>> >>>> >>>> >>>> On Thu, Feb 11, 2016 at 9:24 AM, Lindenmaier, Goetz >>>> >>> > wrote: >>> >>>> Hi >>>> >>>> Please review this change. I please need a sponsor. >>>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.01/ >>>> >>>> If a stringStream is passed to Symbol::print_symbol_on(), >>>> assertion "stringStream is re-allocated with a different ResourceMark." >>>> can >>>> >>> fire in stringStream::write(const char* s, size_t len). >>> >>>> This can be verified by running TestLogTouchedMethods.java after adding >>>> >>> the patch below to the VM. >>> >>>> >>>> My fix copies the string to locally managed memory before popping the >>>> >>> ResoreceMark. >>> >>>> A better solution would be to guarantee enough space on the stream >>>> before doing the resource mark, but outputStream has no such >>>> method as 'ensureCapacity' or the like. >>>> Alternatively the ResourceMark could be skipped altogether. >>>> But then the aux memory used remains on the ResourceArea too long. >>>> Also, various ResourceMarks have to be added in other places. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> --- a/src/share/vm/runtime/java.cpp Wed Jan 13 11:33:21 2016 +0100 >>>> +++ b/src/share/vm/runtime/java.cpp Wed Feb 10 08:56:14 2016 +0100 >>>> @@ -340,7 +340,10 @@ >>>> } >>>> >>>> if (LogTouchedMethods && PrintTouchedMethodsAtExit) { >>>> - Method::print_touched_methods(tty); >>>> + ResourceMark rm; >>>> + stringStream st(16); >>>> + Method::print_touched_methods(&st); >>>> + tty->print("%s", st.as_string()); >>>> } >>>> >>>> if (PrintBiasedLockingStatistics) { >>>> >>>> From thomas.stuefe at gmail.com Tue Mar 1 07:18:02 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Mar 2016 08:18:02 +0100 Subject: RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times In-Reply-To: <56D4B452.7090705@oracle.com> References: <56D4B452.7090705@oracle.com> Message-ID: Hi David, On Mon, Feb 29, 2016 at 10:12 PM, David Holmes wrote: > Hi Thomas, > > On 1/03/2016 3:14 AM, Thomas St?fe wrote: > >> Hi all, >> >> please review and sponsor this small fix. >> >> It fixes an error in os::getTimesSecs() for windows which causes the >> numbers for kernel- and usertime to be off. This does not cause an error, >> because the sole user of this function, the TraceCpuTime class, uses this >> function to measure twice and calculate the deltas. >> >> I still think it is a good idea to fix this bug - with the fix, the >> returned values are based on the process start and will be the same for >> all >> platforms (the *nix platforms use times()). >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 >> webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/ >> > > So the error is that kernel and user times are treated as-if they were > absolute times - which they are not. > > I still find this somewhat confusing though: > > 955 jlong user_millis = jlong_from(user_time.dwHighDateTime, > user_time.dwLowDateTime); > 956 jlong system_millis = jlong_from(kernel_time.dwHighDateTime, > kernel_time.dwLowDateTime); > > > as neither of those calculations will give a value that represents > milliseconds. I'd rather see the adjustment to millis occur above rather > than here: > > 958 *process_user_time = ((double) user_millis) / ((double) (10 * > MICROUNITS)); > 959 *process_system_time = ((double) system_millis) / ((double) (10 * > MICROUNITS)); > > You are right, this is confusing. But if I do the division with a jlong, I loose precision (the code before did too). So, I do now the conversion in one step: http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/ So, the new version not only returns values with the correct offset now, they are also more precise, which actually may benefit GC statistics. Kind Regards, Thomas > > Thanks, > David > > > > Kind Regards, Thomas >> >> From david.holmes at oracle.com Tue Mar 1 07:32:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Mar 2016 17:32:10 +1000 Subject: RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times In-Reply-To: References: <56D4B452.7090705@oracle.com> Message-ID: <56D5457A.5070302@oracle.com> On 1/03/2016 5:18 PM, Thomas St?fe wrote: > Hi David, > > On Mon, Feb 29, 2016 at 10:12 PM, David Holmes > wrote: > > Hi Thomas, > > On 1/03/2016 3:14 AM, Thomas St?fe wrote: > > Hi all, > > please review and sponsor this small fix. > > It fixes an error in os::getTimesSecs() for windows which causes the > numbers for kernel- and usertime to be off. This does not cause > an error, > because the sole user of this function, the TraceCpuTime class, > uses this > function to measure twice and calculate the deltas. > > I still think it is a good idea to fix this bug - with the fix, the > returned values are based on the process start and will be the > same for all > platforms (the *nix platforms use times()). > > bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/ > > > So the error is that kernel and user times are treated as-if they > were absolute times - which they are not. > > I still find this somewhat confusing though: > > 955 jlong user_millis = jlong_from(user_time.dwHighDateTime, > user_time.dwLowDateTime); > 956 jlong system_millis = > jlong_from(kernel_time.dwHighDateTime, kernel_time.dwLowDateTime); > > > as neither of those calculations will give a value that represents > milliseconds. I'd rather see the adjustment to millis occur above > rather than here: > > 958 *process_user_time = ((double) user_millis) / ((double) (10 > * MICROUNITS)); > 959 *process_system_time = ((double) system_millis) / > ((double) (10 * MICROUNITS)); > > > You are right, this is confusing. But if I do the division with a jlong, > I loose precision (the code before did too). So, I do now the conversion > in one step: > > http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/ > > So, the new version not only returns values with the correct offset now, > they are also more precise, which actually may benefit GC statistics. Looks good. You're right those local temporaries are not needed. :) Thanks, David > Kind Regards, Thomas > > > Thanks, > David > > > > Kind Regards, Thomas > > From thomas.stuefe at gmail.com Tue Mar 1 07:45:39 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Mar 2016 08:45:39 +0100 Subject: RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times In-Reply-To: <56D5457A.5070302@oracle.com> References: <56D4B452.7090705@oracle.com> <56D5457A.5070302@oracle.com> Message-ID: On Tue, Mar 1, 2016 at 8:32 AM, David Holmes wrote: > On 1/03/2016 5:18 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Mon, Feb 29, 2016 at 10:12 PM, David Holmes > > wrote: >> >> Hi Thomas, >> >> On 1/03/2016 3:14 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please review and sponsor this small fix. >> >> It fixes an error in os::getTimesSecs() for windows which causes >> the >> numbers for kernel- and usertime to be off. This does not cause >> an error, >> because the sole user of this function, the TraceCpuTime class, >> uses this >> function to measure twice and calculate the deltas. >> >> I still think it is a good idea to fix this bug - with the fix, >> the >> returned values are based on the process start and will be the >> same for all >> platforms (the *nix platforms use times()). >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 >> webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/ >> >> >> So the error is that kernel and user times are treated as-if they >> were absolute times - which they are not. >> >> I still find this somewhat confusing though: >> >> 955 jlong user_millis = jlong_from(user_time.dwHighDateTime, >> user_time.dwLowDateTime); >> 956 jlong system_millis = >> jlong_from(kernel_time.dwHighDateTime, kernel_time.dwLowDateTime); >> >> >> as neither of those calculations will give a value that represents >> milliseconds. I'd rather see the adjustment to millis occur above >> rather than here: >> >> 958 *process_user_time = ((double) user_millis) / ((double) (10 >> * MICROUNITS)); >> 959 *process_system_time = ((double) system_millis) / >> ((double) (10 * MICROUNITS)); >> >> >> You are right, this is confusing. But if I do the division with a jlong, >> I loose precision (the code before did too). So, I do now the conversion >> in one step: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/ >> >> So, the new version not only returns values with the correct offset now, >> they are also more precise, which actually may benefit GC statistics. >> > > Looks good. You're right those local temporaries are not needed. :) > > Okay, thanks for the review! > > Thanks, > David > > Kind Regards, Thomas >> >> >> Thanks, >> David >> >> >> >> Kind Regards, Thomas >> >> >> From marcus.larsson at oracle.com Tue Mar 1 11:11:53 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 1 Mar 2016 12:11:53 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL (was: Truncate new UL log files) In-Reply-To: <5697B7F2.50104@oracle.com> References: <5697B7F2.50104@oracle.com> Message-ID: <56D578F9.6090602@oracle.com> Hi again, Taking a different approach to this. New webrev: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). Tested with included jtreg test through JPRT. Thanks, Marcus On 01/14/2016 04:00 PM, Marcus Larsson wrote: > Hi, > > Please review the following patch to make sure UL truncates existing > log files before writing to them. Since files are opened in append > mode, truncation isn't done automatically, so instead the patch adds > an attempt to remove the log file before opening it. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146879 > > Testing: > Included test through JPRT > > Thanks, > Marcus From thomas.stuefe at gmail.com Tue Mar 1 13:21:19 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Mar 2016 14:21:19 +0100 Subject: RFR(xs): 8150619: Improve thread based logging introduced with 8149036 In-Reply-To: <56D4AF49.5080905@oracle.com> References: <56D3DD36.70907@oracle.com> <56D403B5.9030104@oracle.com> <56D4AF49.5080905@oracle.com> Message-ID: Hi David, >> Okay I'm confused - I thought the whole point of using >> os+thread >> here was that you had to enable os _and_ thread level >> logging ??? >> Else why bother using the two? I would not have expected >> the above >> to work! :( >> >> >> No, the logging line is just tagged with both keywords. As far as >> I >> understand multiple tags in UL there is no way to specify >> conditions >> like "&&" or "||" - you just tag them - and specifying rules >> happens on >> the command line with "os+thread" or "os,thread". So all of >> this: "os*", >> "thread*", "os+thread" should produce an output, the last one >> will stop >> producing output as soon as someone adds a third tag to the >> logging calls. >> >> >> I thought "os,thread" meant os _and_ thread not os _or_ thread. >> Having "thread*" enable this particular logging is very unintuitive >> to me - though "*thread" might make some sense. >> >> >> I do not understand what you mean with "*thread". >> > > I was considering the ordering of tags to be significant - which as Markus > points out it is not. So I did not expect "thread*" to match "os,thread" - > but I would have considered "*thread" a match :) Ah, now I get you. > > > When marking these log lines with "os" and "thread", I may either >> >> - enable "os*" and see all these log lines and anything else marked with >> "os" - aka "anything os-related" >> - enable "thread*" and see all these log lines and anything else marked >> with "thread" - aka "anything thread related" >> - enable "os+thread" and see only these log lines - aka "anything thread >> related at os level" >> > > > >> Not sure why you find this unintuitive? >> > > I was considering "os,thread" to form a "thread" namespace within the "os" > namespace and so to see "os,thread" you had to first enable the "os" part. > > No, I was just enumerating keywords. I think UL just gives as tags and what we do with them is up to us (which may be a problem, because there seems to be no standard). I think the GC people use tags hierarchically: with "gc" is the outside scope and all their other tags inner scope. But I thought they are the exception, all other tags seem to be plain keywords. Kind Regards, Thomas > Cheers, > David > > > Kind Regards, Thomas >> >> Thanks, >> David >> ----- >> >> >> Note that I added the "thread" keyword because Marcus requested >> this: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/018154.html >> >> But I simplified the test to test once for "os+thread" instead >> of each >> tag separately. Note that with this change, the test will have to >> be >> modified if someone adds a third tag. >> >> >> FYI the test passed on our JPRT system. >> >> >> Great, thanks. >> >> Thank you, >> >> Thomas >> >> Thanks, >> David >> >> >> Thanks & Kind Regards, Thomas >> >> >> >> From dmitry.samersoff at oracle.com Tue Mar 1 13:32:21 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 1 Mar 2016 16:32:21 +0300 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56D578F9.6090602@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> Message-ID: <56D599E5.40504@oracle.com> Marcus, logFileOutput.cpp: 77: Please move this function to include file 149: you have to check that file is a regular one, before any attempt to rotate. Please, move this function to include file. 164: As soon as size_t can't represent more than 10 decimal digits, please replace ceil(log10(static_cast(SIZE_MAX))) to 10 168: It might be better to replace SIZE_MAX to some reasonable value (e.g. 100) and give a message on overflow. Otherwise VM never starts in bad no-log-removal case. 169: please make sure that you produce logname.001, logname.002 etc, not logname.1 ... logname.10 Many filesystems sorts files alphabetically and tons of user scripts rely on it. 186: Please print a reason of fail (os error) -Dmitry On 2016-03-01 14:11, Marcus Larsson wrote: > Hi again, > > Taking a different approach to this. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ > > Existing files will now by default be renamed/archived with a .X suffix > where X is the lowest number such that the resulting file name is > available (jvm.log becomes jvm.log.0). A mode option for controlling > this behavior has been added as well. It can be set to archive, append, > or truncate (i.e. -Xlog::jvm.log::mode=truncate). > > Tested with included jtreg test through JPRT. > > Thanks, > Marcus > > On 01/14/2016 04:00 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to make sure UL truncates existing >> log files before writing to them. Since files are opened in append >> mode, truncation isn't done automatically, so instead the patch adds >> an attempt to remove the log file before opening it. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8146879 >> >> Testing: >> Included test through JPRT >> >> Thanks, >> Marcus > -- 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 Mar 1 14:05:47 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 1 Mar 2016 15:05:47 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56D578F9.6090602@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> Message-ID: <56D5A1BB.6030403@oracle.com> Hi, After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. Thanks, Marcus On 03/01/2016 12:11 PM, Marcus Larsson wrote: > Hi again, > > Taking a different approach to this. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ > > Existing files will now by default be renamed/archived with a .X > suffix where X is the lowest number such that the resulting file name > is available (jvm.log becomes jvm.log.0). A mode option for > controlling this behavior has been added as well. It can be set to > archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). > > Tested with included jtreg test through JPRT. > > Thanks, > Marcus > > On 01/14/2016 04:00 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to make sure UL truncates existing >> log files before writing to them. Since files are opened in append >> mode, truncation isn't done automatically, so instead the patch adds >> an attempt to remove the log file before opening it. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8146879 >> >> Testing: >> Included test through JPRT >> >> Thanks, >> Marcus > From marcus.larsson at oracle.com Tue Mar 1 14:10:36 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 1 Mar 2016 15:10:36 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56D599E5.40504@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D599E5.40504@oracle.com> Message-ID: <56D5A2DC.7040407@oracle.com> Hi Dmitry, Thanks for reviewing, but I'm withdrawing the current patch since I might choose to solve it in a different way. Sorry about that. Marcus On 03/01/2016 02:32 PM, Dmitry Samersoff wrote: > Marcus, > > logFileOutput.cpp: > > 77: Please move this function to include file > > 149: you have to check that file is a regular one, before any attempt to > rotate. > > Please, move this function to include file. > > 164: As soon as size_t can't represent more than 10 decimal digits, > please replace ceil(log10(static_cast(SIZE_MAX))) to 10 > > > 168: It might be better to replace SIZE_MAX to some reasonable value > (e.g. 100) and give a message on overflow. Otherwise VM never starts in > bad no-log-removal case. > > 169: please make sure that you produce logname.001, logname.002 etc, > not logname.1 ... logname.10 > > Many filesystems sorts files alphabetically and tons of user scripts > rely on it. > > 186: Please print a reason of fail (os error) > > -Dmitry > > On 2016-03-01 14:11, Marcus Larsson wrote: >> Hi again, >> >> Taking a different approach to this. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >> >> Existing files will now by default be renamed/archived with a .X suffix >> where X is the lowest number such that the resulting file name is >> available (jvm.log becomes jvm.log.0). A mode option for controlling >> this behavior has been added as well. It can be set to archive, append, >> or truncate (i.e. -Xlog::jvm.log::mode=truncate). >> >> Tested with included jtreg test through JPRT. >> >> Thanks, >> Marcus >> >> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to make sure UL truncates existing >>> log files before writing to them. Since files are opened in append >>> mode, truncation isn't done automatically, so instead the patch adds >>> an attempt to remove the log file before opening it. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>> >>> Testing: >>> Included test through JPRT >>> >>> Thanks, >>> Marcus > From rachel.protacio at oracle.com Tue Mar 1 14:59:54 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 1 Mar 2016 09:59:54 -0500 Subject: RFR (XS): 8150746: runtime/logging/ItablesTest.java fails with: java.lang.RuntimeException: 'Resolving: klass: ' missing from stdout/stderr In-Reply-To: <8D4FDBAD-B7C4-4347-83F8-43B6DABBD5BD@oracle.com> References: <56D4B799.2030704@oracle.com> <8D4FDBAD-B7C4-4347-83F8-43B6DABBD5BD@oracle.com> Message-ID: <56D5AE6A.9070307@oracle.com> Thanks for the reviews, Coleen and Christian! Rachel On 2/29/2016 5:44 PM, Christian Thalinger wrote: > Looks good. > >> On Feb 29, 2016, at 11:26 AM, Rachel Protacio wrote: >> >> Hello! >> >> Please review this fix for a failing AOT nightly test. Not only was the logging only printing for non-test-specific klasses, but the logging statement itself has been declared unnecessary by the person who added it originally (i.e. Coleen). I have therefore deleted the logging message completely. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150746 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150746.01/ >> >> The code builds and passes the shortened jtreg test. >> >> Thank you, >> Rachel From max.ockner at oracle.com Tue Mar 1 22:30:22 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 01 Mar 2016 17:30:22 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened Message-ID: <56D617FE.9010504@oracle.com> Hello, Please review this small fix which attempts to shorten the output from -Xlog:classresolve=info to an acceptable length. Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 lines of output. This is unacceptably verbose for info level logging and most of the output is not useful. "java -Xlog:classresolve=info -version" used to produce: - 3,683 total lines of output. - 3,121 total lines of output from ConstantPool::trace_class_resolution(). - 1,329 unique lines of output. - 767 unique lines of output from ConstantPool::trace_class_resolution(). - 562 total lines of output from all other sources, all unique. The code in ConstantPool which called ConstantPool::trace_class_resolution() was doing approximately this: if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} else { resolve the class } So if logging was turned on, the class would not be resolved properly, but it would produce a log entry saying that the class was being resolved. As a result, the constant pool entry would still contain a Symbol* the next time this piece of code was reached, and it would produce yet another classresolve log entry. In some cases, this was producing many consecutive identical log entries, taking up full pages at worst, and averaging a little over 4 duplicates per message. Not cool. The above duplication issue has been fixed, and the ConstantPool::trace_class_resolution output has been moved to the debug leve. There are still 562 unique lines of output for "java -Xlog:classresolve=info -version". There are now 767 additional unique lines of output when for the "java -Xlog:classresolve=debug -version" . This is better than before but still quite a lot. It seems like all of the info level output is equally important(or unimportant), as you can see in the sample below: [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object (super) [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) [0.026s][info][classresolve] java.lang.Class java.io.Serializable (interface) [0.026s][info][classresolve] java.lang.Class java.lang.reflect.GenericDeclaration (interface) [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type (interface) [0.026s][info][classresolve] java.lang.Class java.lang.reflect.AnnotatedElement (interface) [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object (super) [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object (super) [0.027s][info][classresolve] java.lang.System java.lang.Object (super) [0.027s][info][classresolve] java.lang.Throwable java.lang.Object (super) [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable (interface) [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error (super) How do you feel about this? Possible solutions include setting all output to debug level, or removing some of the logging messages. Tested with jtreg runtime tests. ClassResolutionTest.java has been modified to check for the new output. Thanks, Max From david.holmes at oracle.com Tue Mar 1 23:50:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Mar 2016 09:50:00 +1000 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D617FE.9010504@oracle.com> References: <56D617FE.9010504@oracle.com> Message-ID: <56D62AA8.3000108@oracle.com> Hi Max, On 2/03/2016 8:30 AM, Max Ockner wrote: > Hello, > > Please review this small fix which attempts to shorten the output from > -Xlog:classresolve=info to an acceptable length. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 > Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ > > Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 > lines of output. This is unacceptably verbose for info level logging and > most of the output is not useful. > > "java -Xlog:classresolve=info -version" used to produce: > - 3,683 total lines of output. > - 3,121 total lines of output from > ConstantPool::trace_class_resolution(). > - 1,329 unique lines of output. > - 767 unique lines of output from > ConstantPool::trace_class_resolution(). > - 562 total lines of output from all other sources, all unique. > > The code in ConstantPool which called > ConstantPool::trace_class_resolution() was doing approximately this: > > if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} > else { resolve the class } > > So if logging was turned on, the class would not be resolved properly, > but it would produce a log entry saying that the class was being > resolved. As a result, the constant pool entry would still contain a > Symbol* the next time this piece of code was reached, and it would > produce yet another classresolve log entry. In some cases, this was > producing many consecutive identical log entries, taking up full pages > at worst, and averaging a little over 4 duplicates per message. Not cool. But to be clear the TraceClassResolution version was doing the same thing. > The above duplication issue has been fixed, and the > ConstantPool::trace_class_resolution output has been moved to the debug > leve. There are still 562 unique lines of output for "java > -Xlog:classresolve=info -version". There are now 767 additional unique > lines of output when for the "java -Xlog:classresolve=debug -version" . > This is better than before but still quite a lot. It seems like all of > the info level output is equally important(or unimportant), as you can > see in the sample below: > > [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object > (super) > [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) > [0.026s][info][classresolve] java.lang.Class java.io.Serializable > (interface) > [0.026s][info][classresolve] java.lang.Class > java.lang.reflect.GenericDeclaration (interface) > [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type > (interface) > [0.026s][info][classresolve] java.lang.Class > java.lang.reflect.AnnotatedElement (interface) > [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object (super) > [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object (super) > [0.027s][info][classresolve] java.lang.System java.lang.Object (super) > [0.027s][info][classresolve] java.lang.Throwable java.lang.Object (super) > [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable > (interface) > [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) > [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error (super) > > How do you feel about this? Possible solutions include setting all > output to debug level, or removing some of the logging messages. I expect tracing class resolution to show me at least one line for every class that gets resolved, so the above seems fine. Only the extra detailed info should be deferred to debug-level. But I'm not a consumer of this data so ... :) > Tested with jtreg runtime tests. ClassResolutionTest.java has been > modified to check for the new output. I'm puzzled by a couple of changes: public static class Thing1 { + static int number=5; public static int getThingNumber() { ! return number; } Significance? Also here: ! o = new OutputAnalyzer(pb.start()); ! o.getOutput(); ! o.shouldContain("[classresolve] ... o.getOutput() isn't doing anything. Thanks, David > Thanks, > Max > > From kim.barrett at oracle.com Wed Mar 2 03:10:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Mar 2016 22:10:40 -0500 Subject: RFR: 8150688: Fix os_windows siglabel Message-ID: Please review this change to avoid a build error with VS2015. C++11 forbids implicit narrowing conversions in brace initializers, and VS2015 (unlike earlier versions) enforces that restriction. The struct siglabel has an int "number" member, but some of the values in the brace initializer for exceptlabels are unsigned int. As a result, VS2015 complains. To resolve this, we changed the member type to uint. Made some other nearby cleanups while we're here, including misuse of struct siglable in get_signal_number. This change is based on a patch provided by Timo Kinnunen. CR: https://bugs.openjdk.java.net/browse/JDK-8150688 Webrev: http://cr.openjdk.java.net/~kbarrett/8150688/webrev.00/ Testing: JPRT Aurora ad-hoc defaults + Runtime nightly tests. Note that I've not tested these changes with VS2015; there are many other reasons why we can't presently build with that compiler. From david.holmes at oracle.com Wed Mar 2 03:38:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Mar 2016 13:38:26 +1000 Subject: RFR: 8150688: Fix os_windows siglabel In-Reply-To: References: Message-ID: <56D66032.5050409@oracle.com> On 2/03/2016 1:10 PM, Kim Barrett wrote: > Please review this change to avoid a build error with VS2015. > > C++11 forbids implicit narrowing conversions in brace initializers, > and VS2015 (unlike earlier versions) enforces that restriction. The > struct siglabel has an int "number" member, but some of the values in > the brace initializer for exceptlabels are unsigned int. As a result, > VS2015 complains. To resolve this, we changed the member type to uint. OK. > Made some other nearby cleanups while we're here, including misuse of > struct siglable in get_signal_number. Ah - my bad on the review of that one. Not sure why we didn't just reuse "struct siglabel" instead of defining an anonymous struct. Was it actually incorrect or just odd looking? Ship it! Thanks, David > This change is based on a patch provided by Timo Kinnunen. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8150688 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8150688/webrev.00/ > > Testing: > JPRT > Aurora ad-hoc defaults + Runtime nightly tests. > > Note that I've not tested these changes with VS2015; there are many > other reasons why we can't presently build with that compiler. > From coleen.phillimore at oracle.com Wed Mar 2 18:44:07 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 13:44:07 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM Message-ID: <56D73477.4030100@oracle.com> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[] These improvements were found during the investigation for replacing Throwable with the StackWalkAPI. This change also adds iterator for BacktraceBuilder to make changing format of backtrace easier. Tested with -testset core, RBT nightly hotspot nightly tests on all platforms, and jck tests on linux x64. Compatibility request is approved. open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot bug link https://bugs.openjdk.java.net/browse/JDK-8150778 Thanks, Coleen From daniel.fuchs at oracle.com Wed Mar 2 18:57:32 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Mar 2016 19:57:32 +0100 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D73477.4030100@oracle.com> References: <56D73477.4030100@oracle.com> Message-ID: <56D7379C.3030006@oracle.com> Hi Coleen, Nice improvement! Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/ 1. StackTraceElement.java Does the new constructor in StackTraceElement really need to be public? Can't we keep that package protected? 2. Throwable.java:902 902 * package-protection for use by SharedSecrets. If I'm not mistaken we removed the shared secrets access - IIRC that was used by java.util.logging.LogRecord - which now uses the StackWalker API instead. So maybe you could make the method private and remove the comment as further cleanup. Please don't count me as (R)eviewer for the hotspot changes :-) best regards, -- daniel On 02/03/16 19:44, Coleen Phillimore wrote: > Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, > with JVM_GetStackTraceElements that gets all the elements in the > StackTraceElement[] > > These improvements were found during the investigation for replacing > Throwable with the StackWalkAPI. This change also adds iterator for > BacktraceBuilder to make changing format of backtrace easier. > > Tested with -testset core, RBT nightly hotspot nightly tests on all > platforms, and jck tests on linux x64. Compatibility request is approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot > bug link https://bugs.openjdk.java.net/browse/JDK-8150778 > > Thanks, > Coleen From aleksey.shipilev at oracle.com Wed Mar 2 18:58:37 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 2 Mar 2016 21:58:37 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D73477.4030100@oracle.com> References: <56D73477.4030100@oracle.com> Message-ID: <56D737DD.7000700@oracle.com> Hi Coleen, On 03/02/2016 09:44 PM, Coleen Phillimore wrote: > Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, > with JVM_GetStackTraceElements that gets all the elements in the > StackTraceElement[] > > These improvements were found during the investigation for replacing > Throwable with the StackWalkAPI. This change also adds iterator for > BacktraceBuilder to make changing format of backtrace easier. > > Tested with -testset core, RBT nightly hotspot nightly tests on all > platforms, and jck tests on linux x64. Compatibility request is approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot > bug link https://bugs.openjdk.java.net/browse/JDK-8150778 Looks interesting! Is there an underlying reason why we can't return the pre-filled StackTraceElements[] array from the JVM_GetStackTraceElements to begin with? This will avoid leaking StackTraceElement constructor into standard library, *and* allows to make StackTraceElement fields final. Taking stuff back from the standard library is hard, if not impossible, so we better expose as little as possible. Other minor nits: * Initializing fields to their default values is a code smell in Java: private transient int depth = 0; * Passing a null array to getStackTraceElement probably SEGVs? I don't see the null checks in native parts. Thanks, -Aleksey From tom.benson at oracle.com Wed Mar 2 19:11:22 2016 From: tom.benson at oracle.com (Tom Benson) Date: Wed, 2 Mar 2016 14:11:22 -0500 Subject: RFR: 8150688: Fix os_windows siglabel In-Reply-To: <56D66032.5050409@oracle.com> References: <56D66032.5050409@oracle.com> Message-ID: <56D73ADA.9000903@oracle.com> Looks good to me. Though as long as you're "cleaning up" line 5643, you could change the "!strcmp(...)" to "strcmp(...) == 0". Maybe it's just me, but I've never liked the former. Looks like the latter is used about 2 to 1 in the Hotspot source. Your call. Tom On 3/1/2016 10:38 PM, David Holmes wrote: > On 2/03/2016 1:10 PM, Kim Barrett wrote: >> Please review this change to avoid a build error with VS2015. >> >> C++11 forbids implicit narrowing conversions in brace initializers, >> and VS2015 (unlike earlier versions) enforces that restriction. The >> struct siglabel has an int "number" member, but some of the values in >> the brace initializer for exceptlabels are unsigned int. As a result, >> VS2015 complains. To resolve this, we changed the member type to uint. > > OK. > >> Made some other nearby cleanups while we're here, including misuse of >> struct siglable in get_signal_number. > > Ah - my bad on the review of that one. Not sure why we didn't just > reuse "struct siglabel" instead of defining an anonymous struct. Was > it actually incorrect or just odd looking? > > Ship it! > > Thanks, > David > >> This change is based on a patch provided by Timo Kinnunen. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8150688 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8150688/webrev.00/ >> >> Testing: >> JPRT >> Aurora ad-hoc defaults + Runtime nightly tests. >> >> Note that I've not tested these changes with VS2015; there are many >> other reasons why we can't presently build with that compiler. >> From coleen.phillimore at oracle.com Wed Mar 2 19:29:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 14:29:57 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7379C.3030006@oracle.com> References: <56D73477.4030100@oracle.com> <56D7379C.3030006@oracle.com> Message-ID: <56D73F35.3030500@oracle.com> Hi Daniel, Thank you for looking at this so quickly. On 3/2/16 1:57 PM, Daniel Fuchs wrote: > Hi Coleen, > > Nice improvement! > > Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/ > > 1. StackTraceElement.java > > Does the new constructor in StackTraceElement really need to be > public? Can't we keep that package protected? So I just removed the public keyword, and that seems good. Thanks! > > > 2. Throwable.java:902 > > 902 * package-protection for use by SharedSecrets. > > If I'm not mistaken we removed the shared secrets access - IIRC that > was used by java.util.logging.LogRecord - which now uses the > StackWalker API instead. > > So maybe you could make the method private and remove the comment > as further cleanup. I had just copied the SharedSecrets comments. I'll make getStackTraceElements private also. > > Please don't count me as (R)eviewer for the hotspot changes :-) Oh, but you know this code in hotspot, now. That's ok, you don't need to review hotspot code. Thanks! Coleen > > best regards, > > -- daniel > > On 02/03/16 19:44, Coleen Phillimore wrote: >> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >> with JVM_GetStackTraceElements that gets all the elements in the >> StackTraceElement[] >> >> These improvements were found during the investigation for replacing >> Throwable with the StackWalkAPI. This change also adds iterator for >> BacktraceBuilder to make changing format of backtrace easier. >> >> Tested with -testset core, RBT nightly hotspot nightly tests on all >> platforms, and jck tests on linux x64. Compatibility request is >> approved. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Wed Mar 2 19:57:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 14:57:43 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D737DD.7000700@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> Message-ID: <56D745B7.4040508@oracle.com> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: > Hi Coleen, > > On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >> with JVM_GetStackTraceElements that gets all the elements in the >> StackTraceElement[] >> >> These improvements were found during the investigation for replacing >> Throwable with the StackWalkAPI. This change also adds iterator for >> BacktraceBuilder to make changing format of backtrace easier. >> >> Tested with -testset core, RBT nightly hotspot nightly tests on all >> platforms, and jck tests on linux x64. Compatibility request is approved. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 > Looks interesting! > > Is there an underlying reason why we can't return the pre-filled > StackTraceElements[] array from the JVM_GetStackTraceElements to begin > with? This will avoid leaking StackTraceElement constructor into > standard library, *and* allows to make StackTraceElement fields final. > Taking stuff back from the standard library is hard, if not impossible, > so we better expose as little as possible. We measured that it's faster to allocate the StackTraceElement array in Java and it seems cleaner to the Java guys. It came from similar code we've been prototyping for StackFrameInfo. > > Other minor nits: > > * Initializing fields to their default values is a code smell in Java: > private transient int depth = 0; ok, not sure what "code smell" means but it doesn't have to be initialized like this. It's set in the native code. > > * Passing a null array to getStackTraceElement probably SEGVs? I don't > see the null checks in native parts. Yes, it would SEGV. I'll add some checks for null and make sure it's an array of StackTraceElement. Thanks, Coleen > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Wed Mar 2 20:21:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 2 Mar 2016 23:21:31 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D745B7.4040508@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> Message-ID: <56D74B4B.9090708@oracle.com> On 03/02/2016 10:57 PM, Coleen Phillimore wrote: > On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >> Is there an underlying reason why we can't return the pre-filled >> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >> with? This will avoid leaking StackTraceElement constructor into >> standard library, *and* allows to make StackTraceElement fields final. >> Taking stuff back from the standard library is hard, if not impossible, >> so we better expose as little as possible. > > We measured that it's faster to allocate the StackTraceElement array > in Java and it seems cleaner to the Java guys. It came from similar > code we've been prototyping for StackFrameInfo. OK, it's not perfectly clean from implementation standpoint, but this RFE might not be the best opportunity to polish that. At least make StackTraceElement constructor private (better), or package-private (acceptable), and then we are good to go. Also, I think you can drop this line: 836 int depth = getStackTraceDepth(); Thanks, -Aleksey From coleen.phillimore at oracle.com Wed Mar 2 20:36:27 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 15:36:27 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D74B4B.9090708@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> Message-ID: <56D74ECB.7020503@oracle.com> On 3/2/16 3:21 PM, Aleksey Shipilev wrote: > On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>> with? This will avoid leaking StackTraceElement constructor into >>> standard library, *and* allows to make StackTraceElement fields final. >>> Taking stuff back from the standard library is hard, if not impossible, >>> so we better expose as little as possible. >> We measured that it's faster to allocate the StackTraceElement array >> in Java and it seems cleaner to the Java guys. It came from similar >> code we've been prototyping for StackFrameInfo. > OK, it's not perfectly clean from implementation standpoint, but this > RFE might not be the best opportunity to polish that. At least make > StackTraceElement constructor private (better), or package-private > (acceptable), and then we are good to go. Well, the RFE is intended to clean this up but I don't think there's agreement about what the cleanest thing is. If the cleaner API is: StackTraceElement[] getStackTraceElements(); we should change it once and not twice. I'd like to hear other opinions! Since StackTraceElement constructor is called by Throwable it has to be package private but can't be private. I have made it package private. > > Also, I think you can drop this line: > 836 int depth = getStackTraceDepth(); Oh, right, I can do that. I was hiding the field depth. i don't need the function either. Thanks! Thank you for looking at this so quickly. Coleen > > Thanks, > -Aleksey > From max.ockner at oracle.com Wed Mar 2 22:16:03 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 02 Mar 2016 17:16:03 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D62AA8.3000108@oracle.com> References: <56D617FE.9010504@oracle.com> <56D62AA8.3000108@oracle.com> Message-ID: <56D76623.4040906@oracle.com> David, The changes that were puzzling you have been removed. I think setting all of the output to debug level would be the best solution, but I want to see what others have to say. Thanks, Max Webrev: http://cr.openjdk.java.net/~mockner/8146551.03/ On 3/1/2016 6:50 PM, David Holmes wrote: > Hi Max, > > On 2/03/2016 8:30 AM, Max Ockner wrote: >> Hello, >> >> Please review this small fix which attempts to shorten the output from >> -Xlog:classresolve=info to an acceptable length. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >> >> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >> lines of output. This is unacceptably verbose for info level logging and >> most of the output is not useful. >> >> "java -Xlog:classresolve=info -version" used to produce: >> - 3,683 total lines of output. >> - 3,121 total lines of output from >> ConstantPool::trace_class_resolution(). >> - 1,329 unique lines of output. >> - 767 unique lines of output from >> ConstantPool::trace_class_resolution(). >> - 562 total lines of output from all other sources, all unique. >> >> The code in ConstantPool which called >> ConstantPool::trace_class_resolution() was doing approximately this: >> >> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >> else { resolve the class } >> >> So if logging was turned on, the class would not be resolved properly, >> but it would produce a log entry saying that the class was being >> resolved. As a result, the constant pool entry would still contain a >> Symbol* the next time this piece of code was reached, and it would >> produce yet another classresolve log entry. In some cases, this was >> producing many consecutive identical log entries, taking up full pages >> at worst, and averaging a little over 4 duplicates per message. Not >> cool. > > But to be clear the TraceClassResolution version was doing the same > thing. > >> The above duplication issue has been fixed, and the >> ConstantPool::trace_class_resolution output has been moved to the debug >> leve. There are still 562 unique lines of output for "java >> -Xlog:classresolve=info -version". There are now 767 additional unique >> lines of output when for the "java -Xlog:classresolve=debug -version" . >> This is better than before but still quite a lot. It seems like all of >> the info level output is equally important(or unimportant), as you can >> see in the sample below: >> >> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >> (super) >> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >> (interface) >> [0.026s][info][classresolve] java.lang.Class >> java.lang.reflect.GenericDeclaration (interface) >> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >> (interface) >> [0.026s][info][classresolve] java.lang.Class >> java.lang.reflect.AnnotatedElement (interface) >> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >> (interface) >> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) >> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >> (super) >> >> How do you feel about this? Possible solutions include setting all >> output to debug level, or removing some of the logging messages. > > I expect tracing class resolution to show me at least one line for > every class that gets resolved, so the above seems fine. Only the > extra detailed info should be deferred to debug-level. But I'm not a > consumer of this data so ... :) > >> Tested with jtreg runtime tests. ClassResolutionTest.java has been >> modified to check for the new output. > > I'm puzzled by a couple of changes: > > public static class Thing1 { > + static int number=5; > public static int getThingNumber() { > ! return number; > } > > Significance? > > Also here: > > ! o = new OutputAnalyzer(pb.start()); > ! o.getOutput(); > ! o.shouldContain("[classresolve] ... > > o.getOutput() isn't doing anything. > > Thanks, > David > >> Thanks, >> Max >> >> From coleen.phillimore at oracle.com Thu Mar 3 00:03:33 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 19:03:33 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D745B7.4040508@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> Message-ID: <56D77F55.9010801@oracle.com> Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by Aleksey. I've kept the StackTraceElement[] allocation in Java to match the new API that was approved. open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ Thanks, Coleen On 3/2/16 2:57 PM, Coleen Phillimore wrote: > > > On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >> Hi Coleen, >> >> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>> with JVM_GetStackTraceElements that gets all the elements in the >>> StackTraceElement[] >>> >>> These improvements were found during the investigation for replacing >>> Throwable with the StackWalkAPI. This change also adds iterator for >>> BacktraceBuilder to make changing format of backtrace easier. >>> >>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>> platforms, and jck tests on linux x64. Compatibility request is >>> approved. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >> Looks interesting! >> >> Is there an underlying reason why we can't return the pre-filled >> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >> with? This will avoid leaking StackTraceElement constructor into >> standard library, *and* allows to make StackTraceElement fields final. >> Taking stuff back from the standard library is hard, if not impossible, >> so we better expose as little as possible. > > We measured that it's faster to allocate the StackTraceElement array > in Java and it seems cleaner to the Java guys. > It came from similar code we've been prototyping for StackFrameInfo. >> >> Other minor nits: >> >> * Initializing fields to their default values is a code smell in Java: >> private transient int depth = 0; > > ok, not sure what "code smell" means but it doesn't have to be > initialized like this. It's set in the native code. >> >> * Passing a null array to getStackTraceElement probably SEGVs? I don't >> see the null checks in native parts. > > Yes, it would SEGV. I'll add some checks for null and make sure it's > an array of StackTraceElement. > > Thanks, > Coleen >> >> Thanks, >> -Aleksey >> > From kim.barrett at oracle.com Thu Mar 3 01:02:33 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Mar 2016 20:02:33 -0500 Subject: RFR: 8150688: Fix os_windows siglabel In-Reply-To: <56D66032.5050409@oracle.com> References: <56D66032.5050409@oracle.com> Message-ID: > On Mar 1, 2016, at 10:38 PM, David Holmes wrote: >> Made some other nearby cleanups while we're here, including misuse of >> struct siglable in get_signal_number. > > Ah - my bad on the review of that one. Not sure why we didn't just reuse "struct siglabel" instead of defining an anonymous struct. Was it actually incorrect or just odd looking? The structs *were* structurally identical, so it was only odd. > Ship it! Thaks, David. From kim.barrett at oracle.com Thu Mar 3 01:04:05 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Mar 2016 20:04:05 -0500 Subject: RFR: 8150688: Fix os_windows siglabel In-Reply-To: <56D73ADA.9000903@oracle.com> References: <56D66032.5050409@oracle.com> <56D73ADA.9000903@oracle.com> Message-ID: <0BEEC967-BE83-44F4-A9D0-66D647B65A1D@oracle.com> > On Mar 2, 2016, at 2:11 PM, Tom Benson wrote: > > Looks good to me. Thanks, Tom. > Though as long as you're "cleaning up" line 5643, you could change the "!strcmp(...)" to "strcmp(...) == 0". Maybe it's just me, but I've never liked the former. Looks like the latter is used about 2 to 1 in the Hotspot source. Looks more like 10 to 1 outside of adlc. OK. From david.holmes at oracle.com Thu Mar 3 01:51:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2016 11:51:42 +1000 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D77F55.9010801@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> Message-ID: <56D798AE.8010509@oracle.com> On 3/03/2016 10:03 AM, Coleen Phillimore wrote: > Freshly tested changes with jck tests, with missing checks and other > changes to use the depth field, as pointed out by Aleksey. I've kept > the StackTraceElement[] allocation in Java to match the new API that was > approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ I get a 404 on that - the actual name seems to be jck. :) David > Thanks, > Coleen > > On 3/2/16 2:57 PM, Coleen Phillimore wrote: >> >> >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Hi Coleen, >>> >>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>> with JVM_GetStackTraceElements that gets all the elements in the >>>> StackTraceElement[] >>>> >>>> These improvements were found during the investigation for replacing >>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>> BacktraceBuilder to make changing format of backtrace easier. >>>> >>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>> platforms, and jck tests on linux x64. Compatibility request is >>>> approved. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>> Looks interesting! >>> >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>> with? This will avoid leaking StackTraceElement constructor into >>> standard library, *and* allows to make StackTraceElement fields final. >>> Taking stuff back from the standard library is hard, if not impossible, >>> so we better expose as little as possible. >> >> We measured that it's faster to allocate the StackTraceElement array >> in Java and it seems cleaner to the Java guys. >> It came from similar code we've been prototyping for StackFrameInfo. >>> >>> Other minor nits: >>> >>> * Initializing fields to their default values is a code smell in Java: >>> private transient int depth = 0; >> >> ok, not sure what "code smell" means but it doesn't have to be >> initialized like this. It's set in the native code. >>> >>> * Passing a null array to getStackTraceElement probably SEGVs? I don't >>> see the null checks in native parts. >> >> Yes, it would SEGV. I'll add some checks for null and make sure it's >> an array of StackTraceElement. >> >> Thanks, >> Coleen >>> >>> Thanks, >>> -Aleksey >>> >> > From coleen.phillimore at oracle.com Thu Mar 3 02:17:56 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 21:17:56 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D798AE.8010509@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D798AE.8010509@oracle.com> Message-ID: <56D79ED4.1020409@oracle.com> On 3/2/16 8:51 PM, David Holmes wrote: > On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >> Freshly tested changes with jck tests, with missing checks and other >> changes to use the depth field, as pointed out by Aleksey. I've kept >> the StackTraceElement[] allocation in Java to match the new API that was >> approved. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ > > I get a 404 on that - the actual name seems to be jck. :) I had jck on my mind. Updated. thanks, Coleen > > David > >> Thanks, >> Coleen >> >> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>> >>> >>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Hi Coleen, >>>> >>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>> StackTraceElement[] >>>>> >>>>> These improvements were found during the investigation for replacing >>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>> >>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>> approved. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>> Looks interesting! >>>> >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not >>>> impossible, >>>> so we better expose as little as possible. >>> >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. >>> It came from similar code we've been prototyping for StackFrameInfo. >>>> >>>> Other minor nits: >>>> >>>> * Initializing fields to their default values is a code smell in >>>> Java: >>>> private transient int depth = 0; >>> >>> ok, not sure what "code smell" means but it doesn't have to be >>> initialized like this. It's set in the native code. >>>> >>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>> don't >>>> see the null checks in native parts. >>> >>> Yes, it would SEGV. I'll add some checks for null and make sure it's >>> an array of StackTraceElement. >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> >> From mandy.chung at oracle.com Thu Mar 3 02:18:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Mar 2016 18:18:40 -0800 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D77F55.9010801@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> Message-ID: <37875252-7E11-4A18-B58A-84DC048AE6A7@oracle.com> > On Mar 2, 2016, at 4:03 PM, Coleen Phillimore wrote: > > Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by Aleksey. I've kept the StackTraceElement[] allocation in Java to match the new API that was approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ typo in your link: http://cr.openjdk.java.net/~coleenp/8150778.02_jck/ StackTraceElement.java 80 * @since 1.9 This is not needed. Simply take this out. Throwable.java 215 * Native code sets the depth of the backtrace for later retrieval s/Native code/VM/ since VM is setting the depth field. 896 private native void getStackTraceElements(StackTraceElement[] elements); Can you add the method description ?Gets the stack trace elements." I only skimmed on the hotspot change. Looks okay to me. TestThrowable.java 43 int getDepth(Throwable t) throws Exception { 44 for (Field f : Throwable.class.getDeclaredFields()) { 45 if (f.getName().equals("depth")) { You can replace the above with Throwable.class.getDeclaredField(?depth?) Otherwise, looks okay. Mandy From david.holmes at oracle.com Thu Mar 3 02:29:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2016 12:29:57 +1000 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D77F55.9010801@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> Message-ID: <56D7A1A5.6090808@oracle.com> Hi Coleen, On 3/03/2016 10:03 AM, Coleen Phillimore wrote: > Freshly tested changes with jck tests, with missing checks and other > changes to use the depth field, as pointed out by Aleksey. I've kept > the StackTraceElement[] allocation in Java to match the new API that was > approved. I would have argued for returning a constructed array instead but if that decision has already been made then it has already been made. > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ Overall this looks good - makes me wonder why we didn't do it this way earlier ?? :) javaClasses.cpp: 2044 { 2045 ResourceMark rm; 2046 log_info(stacktrace)("%s, %d", throwable->klass()->external_name(), chunk_count); 2047 } There is already a ResourceMark earlier in the method. (Otherwise it should be inside a "log is enabled" guard.) 2063 if (throwable.is_null() || stack_trace_array_h.is_null() || 2064 !is_StackTraceElementArray(stack_trace_array_h)) { 2065 THROW(vmSymbols::java_lang_NullPointerException()); 2066 } Not sure the type check for the array is needed (we don't check the throwable object really is a Throwable) - but if it is then throwing NPE seems misleading. test/runtime/Throwable/TestThrowable.java Does that reflection hack still work in a modular VM? Thanks, David > Thanks, > Coleen > > On 3/2/16 2:57 PM, Coleen Phillimore wrote: >> >> >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Hi Coleen, >>> >>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>> with JVM_GetStackTraceElements that gets all the elements in the >>>> StackTraceElement[] >>>> >>>> These improvements were found during the investigation for replacing >>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>> BacktraceBuilder to make changing format of backtrace easier. >>>> >>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>> platforms, and jck tests on linux x64. Compatibility request is >>>> approved. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>> Looks interesting! >>> >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>> with? This will avoid leaking StackTraceElement constructor into >>> standard library, *and* allows to make StackTraceElement fields final. >>> Taking stuff back from the standard library is hard, if not impossible, >>> so we better expose as little as possible. >> >> We measured that it's faster to allocate the StackTraceElement array >> in Java and it seems cleaner to the Java guys. >> It came from similar code we've been prototyping for StackFrameInfo. >>> >>> Other minor nits: >>> >>> * Initializing fields to their default values is a code smell in Java: >>> private transient int depth = 0; >> >> ok, not sure what "code smell" means but it doesn't have to be >> initialized like this. It's set in the native code. >>> >>> * Passing a null array to getStackTraceElement probably SEGVs? I don't >>> see the null checks in native parts. >> >> Yes, it would SEGV. I'll add some checks for null and make sure it's >> an array of StackTraceElement. >> >> Thanks, >> Coleen >>> >>> Thanks, >>> -Aleksey >>> >> > From mandy.chung at oracle.com Thu Mar 3 02:54:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Mar 2016 18:54:55 -0800 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7A1A5.6090808@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D7A1A5.6090808@oracle.com> Message-ID: > On Mar 2, 2016, at 6:29 PM, David Holmes wrote: > > Hi Coleen, > > On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >> Freshly tested changes with jck tests, with missing checks and other >> changes to use the depth field, as pointed out by Aleksey. I've kept >> the StackTraceElement[] allocation in Java to match the new API that was >> approved. > > I would have argued for returning a constructed array instead but if that decision has already been made then it has already been made. Correct me if I?m wrong, AFAIK, allocating objects in Java is faster than done in VM. This JVM_GetStackTraceElements function is only used by Throwable. Generally I prefer to keep things done in Java rather than in VM. I don?t have a strong opinion on this case as VM has to fill in StackTraceElement fields anyway. > >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ > > Overall this looks good - makes me wonder why we didn't do it this way earlier ?? :) > > javaClasses.cpp: > > 2044 { > 2045 ResourceMark rm; > 2046 log_info(stacktrace)("%s, %d", throwable->klass()->external_name(), chunk_count); > 2047 } > > There is already a ResourceMark earlier in the method. (Otherwise it should be inside a "log is enabled" guard.) > > 2063 if (throwable.is_null() || stack_trace_array_h.is_null() || > 2064 !is_StackTraceElementArray(stack_trace_array_h)) { > 2065 THROW(vmSymbols::java_lang_NullPointerException()); > 2066 } > > Not sure the type check for the array is needed (we don't check the throwable object really is a Throwable) - but if it is then throwing NPE seems misleading. > > test/runtime/Throwable/TestThrowable.java > > Does that reflection hack still work in a modular VM? > java.lang.Throwable::depth is in an exported package and so it will work when module access check is enforced. If a test accesses a non-exported package, jtreg has added @modules tag for tests to specify what non-exported packages a test needs to access and jtreg will run the test with -XaddExports to set up the access. Mandy > Thanks, > David > >> Thanks, >> Coleen >> >> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>> >>> >>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Hi Coleen, >>>> >>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>> StackTraceElement[] >>>>> >>>>> These improvements were found during the investigation for replacing >>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>> >>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>> approved. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>> Looks interesting! >>>> >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not impossible, >>>> so we better expose as little as possible. >>> >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. >>> It came from similar code we've been prototyping for StackFrameInfo. >>>> >>>> Other minor nits: >>>> >>>> * Initializing fields to their default values is a code smell in Java: >>>> private transient int depth = 0; >>> >>> ok, not sure what "code smell" means but it doesn't have to be >>> initialized like this. It's set in the native code. >>>> >>>> * Passing a null array to getStackTraceElement probably SEGVs? I don't >>>> see the null checks in native parts. >>> >>> Yes, it would SEGV. I'll add some checks for null and make sure it's >>> an array of StackTraceElement. >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> >> From coleen.phillimore at oracle.com Thu Mar 3 02:55:09 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 21:55:09 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <37875252-7E11-4A18-B58A-84DC048AE6A7@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <37875252-7E11-4A18-B58A-84DC048AE6A7@oracle.com> Message-ID: <56D7A78D.7040500@oracle.com> Mandy, thank you for reviewing this. On 3/2/16 9:18 PM, Mandy Chung wrote: >> On Mar 2, 2016, at 4:03 PM, Coleen Phillimore wrote: >> >> Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by Aleksey. I've kept the StackTraceElement[] allocation in Java to match the new API that was approved. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ > typo in your link: > http://cr.openjdk.java.net/~coleenp/8150778.02_jck/ > > StackTraceElement.java > 80 * @since 1.9 Okay, good because it's probably 9.0 anyway. > > This is not needed. Simply take this out. > > Throwable.java > > 215 * Native code sets the depth of the backtrace for later retrieval > > s/Native code/VM/ I changed it to "The JVM sets the depth..." There was another sentence just like this for the backtrace field, which I also changed. > since VM is setting the depth field. > > > 896 private native void getStackTraceElements(StackTraceElement[] elements); > > Can you add the method description > ?Gets the stack trace elements." Fixed. > I only skimmed on the hotspot change. Looks okay to me. > > TestThrowable.java > > 43 int getDepth(Throwable t) throws Exception { > 44 for (Field f : Throwable.class.getDeclaredFields()) { > 45 if (f.getName().equals("depth")) { > > > You can replace the above with Throwable.class.getDeclaredField(?depth?) Yes, that's better. > Otherwise, looks okay. Thanks! Coleen > Mandy From coleen.phillimore at oracle.com Thu Mar 3 03:11:22 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 2 Mar 2016 22:11:22 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7A1A5.6090808@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D7A1A5.6090808@oracle.com> Message-ID: <56D7AB5A.6010601@oracle.com> On 3/2/16 9:29 PM, David Holmes wrote: > Hi Coleen, > > On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >> Freshly tested changes with jck tests, with missing checks and other >> changes to use the depth field, as pointed out by Aleksey. I've kept >> the StackTraceElement[] allocation in Java to match the new API that was >> approved. > > I would have argued for returning a constructed array instead but if > that decision has already been made then it has already been made. I see Mandy's reply afterward, but it's really an opinion question and I don't think there's a strong technical or correctness reason to do it one way rather than the other. The preference is to write most code in Java and it is faster to allocate these in Java. But this isn't a critical path for performance, it just helps. > >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ > > Overall this looks good - makes me wonder why we didn't do it this way > earlier ?? :) > No idea! > javaClasses.cpp: > > 2044 { > 2045 ResourceMark rm; > 2046 log_info(stacktrace)("%s, %d", > throwable->klass()->external_name(), chunk_count); > 2047 } > > There is already a ResourceMark earlier in the method. (Otherwise it > should be inside a "log is enabled" guard.) I was being more cautious here but the one above is fine to use. > > 2063 if (throwable.is_null() || stack_trace_array_h.is_null() || > 2064 !is_StackTraceElementArray(stack_trace_array_h)) { > 2065 THROW(vmSymbols::java_lang_NullPointerException()); > 2066 } > > Not sure the type check for the array is needed (we don't check the > throwable object really is a Throwable) - but if it is then throwing > NPE seems misleading. > I was being overly cautious even though the only caller is the code in the jdk in Throwable. I could just check for NULL and if it's an array, but then I decided to check the element type. Actually, there's an assert later for element type. I can take it out. You're right, we don't check if throwable is a Throwable. If I leave it in, what else should I throw? > test/runtime/Throwable/TestThrowable.java > > Does that reflection hack still work in a modular VM? Good thing Mandy answered that. Thanks! Coleen > > Thanks, > David > >> Thanks, >> Coleen >> >> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>> >>> >>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Hi Coleen, >>>> >>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>> StackTraceElement[] >>>>> >>>>> These improvements were found during the investigation for replacing >>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>> >>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>> approved. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>> Looks interesting! >>>> >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not >>>> impossible, >>>> so we better expose as little as possible. >>> >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. >>> It came from similar code we've been prototyping for StackFrameInfo. >>>> >>>> Other minor nits: >>>> >>>> * Initializing fields to their default values is a code smell in >>>> Java: >>>> private transient int depth = 0; >>> >>> ok, not sure what "code smell" means but it doesn't have to be >>> initialized like this. It's set in the native code. >>>> >>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>> don't >>>> see the null checks in native parts. >>> >>> Yes, it would SEGV. I'll add some checks for null and make sure it's >>> an array of StackTraceElement. >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> >> From david.holmes at oracle.com Thu Mar 3 04:13:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2016 14:13:15 +1000 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7AB5A.6010601@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D7A1A5.6090808@oracle.com> <56D7AB5A.6010601@oracle.com> Message-ID: <56D7B9DB.30601@oracle.com> On 3/03/2016 1:11 PM, Coleen Phillimore wrote: > > > On 3/2/16 9:29 PM, David Holmes wrote: >> Hi Coleen, >> >> On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >>> Freshly tested changes with jck tests, with missing checks and other >>> changes to use the depth field, as pointed out by Aleksey. I've kept >>> the StackTraceElement[] allocation in Java to match the new API that was >>> approved. >> >> I would have argued for returning a constructed array instead but if >> that decision has already been made then it has already been made. > > I see Mandy's reply afterward, but it's really an opinion question and I > don't think there's a strong technical or correctness reason to do it > one way rather than the other. The preference is to write most code in > Java and it is faster to allocate these in Java. But this isn't a > critical path for performance, it just helps. I'm not sure how it can be faster to allocate in Java when the VM does the allocation anyway ?? It is certainly easier to write the array initialization code in the Java. The ugly part of doing it in Java is that the VM has to poke the right length into the depth field. From an API design perspective it is cleaner for the called function to allocate exactly the size and type of array needed rather than having to communicate that information out, and then add checks to make sure a different sized (or typed) array is not passed in. Just my 2c. >> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >> >> Overall this looks good - makes me wonder why we didn't do it this way >> earlier ?? :) >> > > No idea! >> javaClasses.cpp: >> >> 2044 { >> 2045 ResourceMark rm; >> 2046 log_info(stacktrace)("%s, %d", >> throwable->klass()->external_name(), chunk_count); >> 2047 } >> >> There is already a ResourceMark earlier in the method. (Otherwise it >> should be inside a "log is enabled" guard.) > > I was being more cautious here but the one above is fine to use. >> >> 2063 if (throwable.is_null() || stack_trace_array_h.is_null() || >> 2064 !is_StackTraceElementArray(stack_trace_array_h)) { >> 2065 THROW(vmSymbols::java_lang_NullPointerException()); >> 2066 } >> >> Not sure the type check for the array is needed (we don't check the >> throwable object really is a Throwable) - but if it is then throwing >> NPE seems misleading. >> > I was being overly cautious even though the only caller is the code in > the jdk in Throwable. I could just check for NULL and if it's an array, > but then I decided to check the element type. Actually, there's an > assert later for element type. I can take it out. You're right, we > don't check if throwable is a Throwable. > > If I leave it in, what else should I throw? ClassCastException would be the closest thing to signify an incorrect type. But as this is a private internal API that should never be called incorrectly then asserts regarding the array type should be fine. >> test/runtime/Throwable/TestThrowable.java >> >> Does that reflection hack still work in a modular VM? > > Good thing Mandy answered that. :) Yeah I haven't caught up with Jigsaw yet. Cheers, David > Thanks! > Coleen >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>> Hi Coleen, >>>>> >>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>> StackTraceElement[] >>>>>> >>>>>> These improvements were found during the investigation for replacing >>>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>> >>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>> approved. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>> Looks interesting! >>>>> >>>>> Is there an underlying reason why we can't return the pre-filled >>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>>> with? This will avoid leaking StackTraceElement constructor into >>>>> standard library, *and* allows to make StackTraceElement fields final. >>>>> Taking stuff back from the standard library is hard, if not >>>>> impossible, >>>>> so we better expose as little as possible. >>>> >>>> We measured that it's faster to allocate the StackTraceElement array >>>> in Java and it seems cleaner to the Java guys. >>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>> >>>>> Other minor nits: >>>>> >>>>> * Initializing fields to their default values is a code smell in >>>>> Java: >>>>> private transient int depth = 0; >>>> >>>> ok, not sure what "code smell" means but it doesn't have to be >>>> initialized like this. It's set in the native code. >>>>> >>>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>>> don't >>>>> see the null checks in native parts. >>>> >>>> Yes, it would SEGV. I'll add some checks for null and make sure it's >>>> an array of StackTraceElement. >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>> >>> > From mikael.gerdin at oracle.com Thu Mar 3 09:40:23 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 3 Mar 2016 10:40:23 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D617FE.9010504@oracle.com> References: <56D617FE.9010504@oracle.com> Message-ID: <56D80687.6060501@oracle.com> Hi Max, On 2016-03-01 23:30, Max Ockner wrote: > Hello, > > Please review this small fix which attempts to shorten the output from > -Xlog:classresolve=info to an acceptable length. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 > Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ > > Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 > lines of output. This is unacceptably verbose for info level logging and > most of the output is not useful. > > "java -Xlog:classresolve=info -version" used to produce: > - 3,683 total lines of output. > - 3,121 total lines of output from > ConstantPool::trace_class_resolution(). > - 1,329 unique lines of output. > - 767 unique lines of output from > ConstantPool::trace_class_resolution(). > - 562 total lines of output from all other sources, all unique. > > The code in ConstantPool which called > ConstantPool::trace_class_resolution() was doing approximately this: > > if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} > else { resolve the class } > > So if logging was turned on, the class would not be resolved properly, > but it would produce a log entry saying that the class was being > resolved. As a result, the constant pool entry would still contain a > Symbol* the next time this piece of code was reached, and it would > produce yet another classresolve log entry. In some cases, this was > producing many consecutive identical log entries, taking up full pages > at worst, and averaging a little over 4 duplicates per message. Not cool. > > The above duplication issue has been fixed, and the > ConstantPool::trace_class_resolution output has been moved to the debug > leve. There are still 562 unique lines of output for "java > -Xlog:classresolve=info -version". There are now 767 additional unique > lines of output when for the "java -Xlog:classresolve=debug -version" . > This is better than before but still quite a lot. It seems like all of > the info level output is equally important(or unimportant), as you can > see in the sample below: > > [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object > (super) > [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) > [0.026s][info][classresolve] java.lang.Class java.io.Serializable > (interface) > [0.026s][info][classresolve] java.lang.Class > java.lang.reflect.GenericDeclaration (interface) > [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type > (interface) > [0.026s][info][classresolve] java.lang.Class > java.lang.reflect.AnnotatedElement (interface) > [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object (super) > [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object (super) > [0.027s][info][classresolve] java.lang.System java.lang.Object (super) > [0.027s][info][classresolve] java.lang.Throwable java.lang.Object (super) > [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable > (interface) > [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) > [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error (super) > > How do you feel about this? Possible solutions include setting all > output to debug level, or removing some of the logging messages. As I stated in the bug my personal opinion is that "info" level logging should be fairly limited in order to make "-Xlog:all" a useful flag to get a reasonable amount of output about what is happening in a JVM. One approach could be to move the most verbose output to classresolve=trace and keep the rest of classresolve output on the debug level. The fact that the flag was called "TraceClassResolution" is in my mind a hint that if it produces large amounts of output then perhaps that output should be logged on the "trace" log level. /Mikael > > Tested with jtreg runtime tests. ClassResolutionTest.java has been > modified to check for the new output. > > Thanks, > Max > > From bengt.rutisson at oracle.com Thu Mar 3 09:45:29 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 3 Mar 2016 10:45:29 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D80687.6060501@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> Message-ID: <56D807B9.3000709@oracle.com> Hi Max and Mikael, On 2016-03-03 10:40, Mikael Gerdin wrote: > Hi Max, > > On 2016-03-01 23:30, Max Ockner wrote: >> Hello, >> >> Please review this small fix which attempts to shorten the output from >> -Xlog:classresolve=info to an acceptable length. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >> >> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >> lines of output. This is unacceptably verbose for info level logging and >> most of the output is not useful. >> >> "java -Xlog:classresolve=info -version" used to produce: >> - 3,683 total lines of output. >> - 3,121 total lines of output from >> ConstantPool::trace_class_resolution(). >> - 1,329 unique lines of output. >> - 767 unique lines of output from >> ConstantPool::trace_class_resolution(). >> - 562 total lines of output from all other sources, all unique. >> >> The code in ConstantPool which called >> ConstantPool::trace_class_resolution() was doing approximately this: >> >> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >> else { resolve the class } >> >> So if logging was turned on, the class would not be resolved properly, >> but it would produce a log entry saying that the class was being >> resolved. As a result, the constant pool entry would still contain a >> Symbol* the next time this piece of code was reached, and it would >> produce yet another classresolve log entry. In some cases, this was >> producing many consecutive identical log entries, taking up full pages >> at worst, and averaging a little over 4 duplicates per message. Not >> cool. >> >> The above duplication issue has been fixed, and the >> ConstantPool::trace_class_resolution output has been moved to the debug >> leve. There are still 562 unique lines of output for "java >> -Xlog:classresolve=info -version". There are now 767 additional unique >> lines of output when for the "java -Xlog:classresolve=debug -version" . >> This is better than before but still quite a lot. It seems like all of >> the info level output is equally important(or unimportant), as you can >> see in the sample below: >> >> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >> (super) >> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >> (interface) >> [0.026s][info][classresolve] java.lang.Class >> java.lang.reflect.GenericDeclaration (interface) >> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >> (interface) >> [0.026s][info][classresolve] java.lang.Class >> java.lang.reflect.AnnotatedElement (interface) >> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >> (super) >> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >> (interface) >> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) >> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >> (super) >> >> How do you feel about this? Possible solutions include setting all >> output to debug level, or removing some of the logging messages. > > As I stated in the bug my personal opinion is that "info" level > logging should be fairly limited in order to make "-Xlog:all" a useful > flag to get a reasonable amount of output about what is happening in a > JVM. > > One approach could be to move the most verbose output to > classresolve=trace and keep the rest of classresolve output on the > debug level. > > The fact that the flag was called "TraceClassResolution" is in my mind > a hint that if it produces large amounts of output then perhaps that > output should be logged on the "trace" log level. +1 for this approach. I quite agree with Mikael that we should be a bit careful what we log at info level. Thanks, Bengt > > /Mikael > >> >> Tested with jtreg runtime tests. ClassResolutionTest.java has been >> modified to check for the new output. >> >> Thanks, >> Max >> >> From thomas.stuefe at gmail.com Thu Mar 3 12:01:11 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Mar 2016 13:01:11 +0100 Subject: RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times In-Reply-To: References: Message-ID: Hi all, I still need a second reviewer and a sponsor for this small Windows-only fix. bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 Current webrev is: http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/ Thank you! ..Thomas On Mon, Feb 29, 2016 at 6:14 PM, Thomas St?fe wrote: > Hi all, > > please review and sponsor this small fix. > > It fixes an error in os::getTimesSecs() for windows which causes the > numbers for kernel- and usertime to be off. This does not cause an error, > because the sole user of this function, the TraceCpuTime class, uses this > function to measure twice and calculate the deltas. > > I still think it is a good idea to fix this bug - with the fix, the > returned values are based on the process start and will be the same for all > platforms (the *nix platforms use times()). > > bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/ > > Kind Regards, Thomas > From daniel.daugherty at oracle.com Thu Mar 3 16:20:45 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 3 Mar 2016 09:20:45 -0700 Subject: RFR: 8150688: Fix os_windows siglabel In-Reply-To: <0BEEC967-BE83-44F4-A9D0-66D647B65A1D@oracle.com> References: <56D66032.5050409@oracle.com> <56D73ADA.9000903@oracle.com> <0BEEC967-BE83-44F4-A9D0-66D647B65A1D@oracle.com> Message-ID: <56D8645D.6040208@oracle.com> On 3/2/16 6:04 PM, Kim Barrett wrote: >> On Mar 2, 2016, at 2:11 PM, Tom Benson wrote: >> >> Looks good to me. > Thanks, Tom. > >> Though as long as you're "cleaning up" line 5643, you could change the "!strcmp(...)" to "strcmp(...) == 0". Maybe it's just me, but I've never liked the former. Looks like the latter is used about 2 to 1 in the Hotspot source. > Looks more like 10 to 1 outside of adlc. OK. > I believe that "!strcmp(...)" falls under the "no implied booleans" guidance for HotSpot style. I try to fix them as I run across them... Dan From cheleswer.sahu at oracle.com Thu Mar 3 16:28:58 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 3 Mar 2016 08:28:58 -0800 (PST) Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: <56CD11F5.9060002@oracle.com> References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> Message-ID: <2fecd625-4723-4fbe-b148-36f7bb654df6@default> Hi, Please review the new code changes for this bug. I have removed " fstat()" call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ Regards, Cheleswer -----Original Message----- From: Dean Long Sent: Wednesday, February 24, 2016 7:44 AM To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: > On 2/23/16 5:56 AM, Thomas St?fe wrote: >> Hi Cheleswer, >> >> >> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >> >> wrote: >> >>> Hi, >>> >>> >>> >>> Please review the code changes for >>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>> >>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>> >>> >>> >>> Bug Brief: >>> >>> While investigating bug >>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>> it has been observed that "check_addr0() " function is not written >>> efficiently. >>> >>> This function is trying to read each "prmap_t" entry in >>> "/proc/self/map" >>> file one by one which is time taking and can cause in long pauses. >>> >>> >>> >>> Solution proposed: >>> >>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one >>> by one, read the entries in chunks. There can be many entries in "map" >>> file, >>> so I have decided to read these >>> >>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>> a lot of read calls and results in smaller pause times. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> >> >> We saw cases, especially on Solaris, where the content of a file in the >> proc file system changed under us while we were reading it. So this >> should >> be kept in mind. The original code seems also broken in that regard, >> because it assumes the ::read() call to read the full size of a prmap_t >> entry, but it may theoretically read an incomplete entry. >> >> As for your coding, you first estimate the size of the mapping file and >> then use this to determine how many entries to read; but when >> reading, this >> information may already be stale. I think it would be more robust and >> also >> simpler to just try to read as many entries as possible - in chunks, to >> make reading faster - until you get EOF. >> >> Kind Regards, Thomas > > I'm really sure that we've been down this road before. In particular, > Dmitry Samersoff has worked on this issue (or one very much like it) > before, but he is on vacation until the end of the month. > There was a similar issue with Linux /proc/self/maps, and whether it was safe to read the file with buffered stdio or not. See 8009062 and 7017193. dl > Dan > > >> >> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >> >> wrote: >> >>> Hi, >>> >>> >>> >>> Please review the code changes for >>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>> >>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>> >>> >>> >>> Bug Brief: >>> >>> While investigating bug >>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>> it has been observed that "check_addr0() " function is not written >>> efficiently. >>> >>> This function is trying to read each "prmap_t" entry in >>> "/proc/self/map" >>> file one by one which is time taking and can cause in long pauses. >>> >>> >>> >>> Solution proposed: >>> >>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by >>> one, read the entries in chunks. There can be many entries in "map" >>> file, >>> so I have decided to read these >>> >>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>> a lot >>> of read calls and results in smaller pause times. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> > From aleksey.shipilev at oracle.com Thu Mar 3 19:05:35 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 3 Mar 2016 22:05:35 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7B9DB.30601@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D7A1A5.6090808@oracle.com> <56D7AB5A.6010601@oracle.com> <56D7B9DB.30601@oracle.com> Message-ID: <56D88AFF.6090200@oracle.com> On 03/03/2016 07:13 AM, David Holmes wrote: > On 3/03/2016 1:11 PM, Coleen Phillimore wrote: >> On 3/2/16 9:29 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >>>> Freshly tested changes with jck tests, with missing checks and other >>>> changes to use the depth field, as pointed out by Aleksey. I've kept >>>> the StackTraceElement[] allocation in Java to match the new API that >>>> was >>>> approved. >>> >>> I would have argued for returning a constructed array instead but if >>> that decision has already been made then it has already been made. >> >> I see Mandy's reply afterward, but it's really an opinion question and I >> don't think there's a strong technical or correctness reason to do it >> one way rather than the other. The preference is to write most code in >> Java and it is faster to allocate these in Java. But this isn't a >> critical path for performance, it just helps. > > I'm not sure how it can be faster to allocate in Java when the VM does > the allocation anyway ?? It is certainly easier to write the array > initialization code in the Java. The ugly part of doing it in Java is > that the VM has to poke the right length into the depth field. From an > API design perspective it is cleaner for the called function to allocate > exactly the size and type of array needed rather than having to > communicate that information out, and then add checks to make sure a > different sized (or typed) array is not passed in. I think if you we don't want to revisit this in future, we need to explore the VM angle on this. Do we know if we can speed up VM array allocation enough to make a cleaner API for this feature? I can help with this, but not today. Thanks, -Aleksey From max.ockner at oracle.com Thu Mar 3 20:34:37 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 03 Mar 2016 15:34:37 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D807B9.3000709@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> Message-ID: <56D89FDD.40804@oracle.com> Thanks for the additional feedback. I have set all of the output to the debug level. webrev: http://cr.openjdk.java.net/~mockner/8146551.04/ You can't really infer anything about the verbosity of a Trace* option from the face that it starts with "Trace", though I agree that it would make a lot more sense if that were the case... I chose to put all of the output on debug after accounting for 2 things; (1) The output is extremely verbose, even for java -version. Therefore, all output should be either debug or trace level. (2) None of the output ever conditioned on Verbose or WizardMode. Based on the conventions we have been following, the output shouldn't be on trace level. ==> Debug level. Thanks, Max On 3/3/2016 4:45 AM, Bengt Rutisson wrote: > > Hi Max and Mikael, > > On 2016-03-03 10:40, Mikael Gerdin wrote: >> Hi Max, >> >> On 2016-03-01 23:30, Max Ockner wrote: >>> Hello, >>> >>> Please review this small fix which attempts to shorten the output from >>> -Xlog:classresolve=info to an acceptable length. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>> >>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>> lines of output. This is unacceptably verbose for info level logging >>> and >>> most of the output is not useful. >>> >>> "java -Xlog:classresolve=info -version" used to produce: >>> - 3,683 total lines of output. >>> - 3,121 total lines of output from >>> ConstantPool::trace_class_resolution(). >>> - 1,329 unique lines of output. >>> - 767 unique lines of output from >>> ConstantPool::trace_class_resolution(). >>> - 562 total lines of output from all other sources, all unique. >>> >>> The code in ConstantPool which called >>> ConstantPool::trace_class_resolution() was doing approximately this: >>> >>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>> else { resolve the class } >>> >>> So if logging was turned on, the class would not be resolved properly, >>> but it would produce a log entry saying that the class was being >>> resolved. As a result, the constant pool entry would still contain a >>> Symbol* the next time this piece of code was reached, and it would >>> produce yet another classresolve log entry. In some cases, this was >>> producing many consecutive identical log entries, taking up full pages >>> at worst, and averaging a little over 4 duplicates per message. Not >>> cool. >>> >>> The above duplication issue has been fixed, and the >>> ConstantPool::trace_class_resolution output has been moved to the debug >>> leve. There are still 562 unique lines of output for "java >>> -Xlog:classresolve=info -version". There are now 767 additional unique >>> lines of output when for the "java -Xlog:classresolve=debug -version" . >>> This is better than before but still quite a lot. It seems like all of >>> the info level output is equally important(or unimportant), as you can >>> see in the sample below: >>> >>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>> (super) >>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>> (interface) >>> [0.026s][info][classresolve] java.lang.Class >>> java.lang.reflect.GenericDeclaration (interface) >>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>> (interface) >>> [0.026s][info][classresolve] java.lang.Class >>> java.lang.reflect.AnnotatedElement (interface) >>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>> (interface) >>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>> (super) >>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>> (super) >>> >>> How do you feel about this? Possible solutions include setting all >>> output to debug level, or removing some of the logging messages. >> >> As I stated in the bug my personal opinion is that "info" level >> logging should be fairly limited in order to make "-Xlog:all" a >> useful flag to get a reasonable amount of output about what is >> happening in a JVM. >> >> One approach could be to move the most verbose output to >> classresolve=trace and keep the rest of classresolve output on the >> debug level. >> >> The fact that the flag was called "TraceClassResolution" is in my >> mind a hint that if it produces large amounts of output then perhaps >> that output should be logged on the "trace" log level. > > +1 for this approach. > > I quite agree with Mikael that we should be a bit careful what we log > at info level. > > Thanks, > Bengt > >> >> /Mikael >> >>> >>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>> modified to check for the new output. >>> >>> Thanks, >>> Max >>> >>> > From rachel.protacio at oracle.com Thu Mar 3 20:35:52 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 3 Mar 2016 15:35:52 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging Message-ID: <56D8A028.5090201@oracle.com> Hello! Coming close to the end of the logging conversions for now! Here's one for TraceSafepointCleanupTime, which is turning into -Xlog:safepointcleanup=info. As it has been a product option, it is aliased in this change. To reiterate the conclusion from the TraceStartupTime conversion, I ask that as long as there are no objections to the correctness of the code, we allow this implementation for now, and I will then file a follow-up bug for possible improvements to the switch statement and TraceTime function signature situation. Since this is the only other "TraceTime" conversion, TraceTime implementation changes will be more succinctly addressable after this SafepointCleanupTime change than before it. Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ Sample old output: $ java -XX:+TraceSafepointCleanupTime -version java version "9-internal" Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-03-02-133604.rprotaci.8150083) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) [deflating idle monitors, 0.0000088 secs] [updating inline caches, 0.0000007 secs] [compilation policy safepoint handler, 0.0000009 secs] [mark nmethods, 0.0000164 secs] [purging class loader data graph, 0.0000002 secs] Sample new output: $ java -Xlog:safepointcleanup -version java version "9-internal" Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-03-02-133610.rprotaci.8149991) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) [0.348s][info][safepointcleanup] deflating idle monitors, 0.0000059 secs [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 secs [0.348s][info][safepointcleanup] compilation policy safepoint handler, 0.0000006 secs [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs [0.348s][info][safepointcleanup] purging class loader data graph, 0.0000001 secs Tested using JPRT and RBT hotspot and non-colo tests. Thanks! Rachel From harold.seigel at oracle.com Thu Mar 3 21:29:39 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 3 Mar 2016 16:29:39 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D8A028.5090201@oracle.com> References: <56D8A028.5090201@oracle.com> Message-ID: <56D8ACC3.2080201@oracle.com> Hi Rachel, The changes look good. Harold On 3/3/2016 3:35 PM, Rachel Protacio wrote: > Hello! > > Coming close to the end of the logging conversions for now! Here's one > for TraceSafepointCleanupTime, which is turning into > -Xlog:safepointcleanup=info. As it has been a product option, it is > aliased in this change. > > To reiterate the conclusion from the TraceStartupTime conversion, I > ask that as long as there are no objections to the correctness of the > code, we allow this implementation for now, and I will then file a > follow-up bug for possible improvements to the switch statement and > TraceTime function signature situation. Since this is the only other > "TraceTime" conversion, TraceTime implementation changes will be more > succinctly addressable after this SafepointCleanupTime change than > before it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ > > Sample old output: > > $ java -XX:+TraceSafepointCleanupTime -version > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-03-02-133604.rprotaci.8150083) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) > [deflating idle monitors, 0.0000088 secs] > [updating inline caches, 0.0000007 secs] > [compilation policy safepoint handler, 0.0000009 secs] > [mark nmethods, 0.0000164 secs] > [purging class loader data graph, 0.0000002 secs] > > Sample new output: > > $ java -Xlog:safepointcleanup -version > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-03-02-133610.rprotaci.8149991) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) > [0.348s][info][safepointcleanup] deflating idle monitors, 0.0000059 > secs > [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 > secs > [0.348s][info][safepointcleanup] compilation policy safepoint > handler, 0.0000006 secs > [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs > [0.348s][info][safepointcleanup] purging class loader data graph, > 0.0000001 secs > > > Tested using JPRT and RBT hotspot and non-colo tests. > > Thanks! > Rachel > > From rachel.protacio at oracle.com Thu Mar 3 21:30:32 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 3 Mar 2016 16:30:32 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D8ACC3.2080201@oracle.com> References: <56D8A028.5090201@oracle.com> <56D8ACC3.2080201@oracle.com> Message-ID: <56D8ACF8.6010502@oracle.com> Thanks, Harold! Rachel On 3/3/2016 4:29 PM, harold seigel wrote: > Hi Rachel, > > The changes look good. > > Harold > > On 3/3/2016 3:35 PM, Rachel Protacio wrote: >> Hello! >> >> Coming close to the end of the logging conversions for now! Here's >> one for TraceSafepointCleanupTime, which is turning into >> -Xlog:safepointcleanup=info. As it has been a product option, it is >> aliased in this change. >> >> To reiterate the conclusion from the TraceStartupTime conversion, I >> ask that as long as there are no objections to the correctness of the >> code, we allow this implementation for now, and I will then file a >> follow-up bug for possible improvements to the switch statement and >> TraceTime function signature situation. Since this is the only other >> "TraceTime" conversion, TraceTime implementation changes will be more >> succinctly addressable after this SafepointCleanupTime change than >> before it. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >> >> Sample old output: >> >> $ java -XX:+TraceSafepointCleanupTime -version >> java version "9-internal" >> Java(TM) SE Runtime Environment (fastdebug build >> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >> [deflating idle monitors, 0.0000088 secs] >> [updating inline caches, 0.0000007 secs] >> [compilation policy safepoint handler, 0.0000009 secs] >> [mark nmethods, 0.0000164 secs] >> [purging class loader data graph, 0.0000002 secs] >> >> Sample new output: >> >> $ java -Xlog:safepointcleanup -version >> java version "9-internal" >> Java(TM) SE Runtime Environment (fastdebug build >> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >> [0.348s][info][safepointcleanup] deflating idle monitors, >> 0.0000059 secs >> [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 >> secs >> [0.348s][info][safepointcleanup] compilation policy safepoint >> handler, 0.0000006 secs >> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >> [0.348s][info][safepointcleanup] purging class loader data graph, >> 0.0000001 secs >> >> >> Tested using JPRT and RBT hotspot and non-colo tests. >> >> Thanks! >> Rachel >> >> > From max.ockner at oracle.com Thu Mar 3 21:41:30 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 03 Mar 2016 16:41:30 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D8ACF8.6010502@oracle.com> References: <56D8A028.5090201@oracle.com> <56D8ACC3.2080201@oracle.com> <56D8ACF8.6010502@oracle.com> Message-ID: <56D8AF8A.4080806@oracle.com> Looks good to me. Max On 3/3/2016 4:30 PM, Rachel Protacio wrote: > Thanks, Harold! > Rachel > > On 3/3/2016 4:29 PM, harold seigel wrote: >> Hi Rachel, >> >> The changes look good. >> >> Harold >> >> On 3/3/2016 3:35 PM, Rachel Protacio wrote: >>> Hello! >>> >>> Coming close to the end of the logging conversions for now! Here's >>> one for TraceSafepointCleanupTime, which is turning into >>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>> aliased in this change. >>> >>> To reiterate the conclusion from the TraceStartupTime conversion, I >>> ask that as long as there are no objections to the correctness of >>> the code, we allow this implementation for now, and I will then file >>> a follow-up bug for possible improvements to the switch statement >>> and TraceTime function signature situation. Since this is the only >>> other "TraceTime" conversion, TraceTime implementation changes will >>> be more succinctly addressable after this SafepointCleanupTime >>> change than before it. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>> >>> Sample old output: >>> >>> $ java -XX:+TraceSafepointCleanupTime -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>> [deflating idle monitors, 0.0000088 secs] >>> [updating inline caches, 0.0000007 secs] >>> [compilation policy safepoint handler, 0.0000009 secs] >>> [mark nmethods, 0.0000164 secs] >>> [purging class loader data graph, 0.0000002 secs] >>> >>> Sample new output: >>> >>> $ java -Xlog:safepointcleanup -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>> [0.348s][info][safepointcleanup] deflating idle monitors, >>> 0.0000059 secs >>> [0.348s][info][safepointcleanup] updating inline caches, >>> 0.0000009 secs >>> [0.348s][info][safepointcleanup] compilation policy safepoint >>> handler, 0.0000006 secs >>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>> [0.348s][info][safepointcleanup] purging class loader data graph, >>> 0.0000001 secs >>> >>> >>> Tested using JPRT and RBT hotspot and non-colo tests. >>> >>> Thanks! >>> Rachel >>> >>> >> > From david.holmes at oracle.com Fri Mar 4 02:54:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Mar 2016 12:54:46 +1000 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D807B9.3000709@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> Message-ID: <56D8F8F6.2030403@oracle.com> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: > > Hi Max and Mikael, > > On 2016-03-03 10:40, Mikael Gerdin wrote: >> Hi Max, >> >> On 2016-03-01 23:30, Max Ockner wrote: >>> Hello, >>> >>> Please review this small fix which attempts to shorten the output from >>> -Xlog:classresolve=info to an acceptable length. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>> >>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>> lines of output. This is unacceptably verbose for info level logging and >>> most of the output is not useful. >>> >>> "java -Xlog:classresolve=info -version" used to produce: >>> - 3,683 total lines of output. >>> - 3,121 total lines of output from >>> ConstantPool::trace_class_resolution(). >>> - 1,329 unique lines of output. >>> - 767 unique lines of output from >>> ConstantPool::trace_class_resolution(). >>> - 562 total lines of output from all other sources, all unique. >>> >>> The code in ConstantPool which called >>> ConstantPool::trace_class_resolution() was doing approximately this: >>> >>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>> else { resolve the class } >>> >>> So if logging was turned on, the class would not be resolved properly, >>> but it would produce a log entry saying that the class was being >>> resolved. As a result, the constant pool entry would still contain a >>> Symbol* the next time this piece of code was reached, and it would >>> produce yet another classresolve log entry. In some cases, this was >>> producing many consecutive identical log entries, taking up full pages >>> at worst, and averaging a little over 4 duplicates per message. Not >>> cool. >>> >>> The above duplication issue has been fixed, and the >>> ConstantPool::trace_class_resolution output has been moved to the debug >>> leve. There are still 562 unique lines of output for "java >>> -Xlog:classresolve=info -version". There are now 767 additional unique >>> lines of output when for the "java -Xlog:classresolve=debug -version" . >>> This is better than before but still quite a lot. It seems like all of >>> the info level output is equally important(or unimportant), as you can >>> see in the sample below: >>> >>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>> (super) >>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>> (interface) >>> [0.026s][info][classresolve] java.lang.Class >>> java.lang.reflect.GenericDeclaration (interface) >>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>> (interface) >>> [0.026s][info][classresolve] java.lang.Class >>> java.lang.reflect.AnnotatedElement (interface) >>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>> (super) >>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>> (interface) >>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable (super) >>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>> (super) >>> >>> How do you feel about this? Possible solutions include setting all >>> output to debug level, or removing some of the logging messages. >> >> As I stated in the bug my personal opinion is that "info" level >> logging should be fairly limited in order to make "-Xlog:all" a useful >> flag to get a reasonable amount of output about what is happening in a >> JVM. >> >> One approach could be to move the most verbose output to >> classresolve=trace and keep the rest of classresolve output on the >> debug level. >> >> The fact that the flag was called "TraceClassResolution" is in my mind >> a hint that if it produces large amounts of output then perhaps that >> output should be logged on the "trace" log level. > > +1 for this approach. As I wrote in the bug report there are philosophically quite different ways to view the the three logging levels - and this has been discussed before. I view "info", "debug" and "trace" as three levels of logging applicable to any chosen tag. Others view them as some global indicator of priority/importance such that some "less important" tags will never use "info" because their output is not considered worthy - only in this world is "-Xlog:all" considered useful. If I say -Xlog:foo I expect to see some logging for foo. David ----- > I quite agree with Mikael that we should be a bit careful what we log at > info level. > > Thanks, > Bengt > >> >> /Mikael >> >>> >>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>> modified to check for the new output. >>> >>> Thanks, >>> Max >>> >>> > From goetz.lindenmaier at sap.com Fri Mar 4 08:37:30 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Mar 2016 08:37:30 +0000 Subject: RFR(S): 8149557: Resource mark breaks printing to string stream In-Reply-To: <56D51A90.7030508@oracle.com> References: <26852801ffaa4671a95ee2e1b0077e57@DEWDFE13DE09.global.corp.sap> <56CA5C7C.5040606@oracle.com> <56D51A90.7030508@oracle.com> Message-ID: <9eb5886ef95d4b58a56ae99da710d789@DEWDFE13DE09.global.corp.sap> > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, March 01, 2016 5:29 AM > To: Lindenmaier, Goetz ; 'Thomas St?fe' > > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string stream > > Hi Goetz, > > On 29/02/2016 11:09 PM, Lindenmaier, Goetz wrote: > > Hi David, Thomas, > > > > you are right, I need to check for NULL. I had the linux > > case in mind. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.02/ > > I can't help but feel there is a bug in the Resource-area memory > management code here. The problem as I understand it is that we have: > > void Symbol::print_symbol_on(outputStream* st) const { > ResourceMark rm; > st = st ? st : tty; > st->print("%s", as_quoted_ascii()); > } > > where we need the ResourceMark for the string returned by > as_quoted_ascii. But if st is itself a resource-area object and needs to > re-size in st->print then it does that in the context of the new > ResourceMark, which fails the assert: "stringStream is re-allocated with > a different ResourceMark." That seems to be the bug to me - a > resource-area object that needs resizing should be able to do it in the > context of an outer ResourceMark. :( > > So the workaround is to use a separate ResourceMark to call > as_quoted_ascii and then copy the result to a malloc'd string, which is > used for the st->print (which may realloc in the context of the existing > outer ResourceMark) and is then free()'d. Yuck. :( Yes, this exactly describes the situation. I wouldn't call it a bug in the Resource-area memory management, but an unpleasant implementation detail of stringStream, that makes it behave differently from its related classes. > > Reluctantly Reviewed. Thanks! Would you mind sponsoring? Best regards, Goetz. > > Thanks, > David > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Montag, 22. Februar 2016 01:55 > >> To: Lindenmaier, Goetz ; 'Thomas St?fe' > >> > >> Cc: hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string > stream > >> > >> On 19/02/2016 11:05 PM, Lindenmaier, Goetz wrote: > >>> Hi Thomas, > >>> > >>> thanks for looking at this. > >>> > >>>> you should check the return value of os::strdup(). > >>> strdup returns null on oom, %s should be ?null?, and > >> > >> What are you assuming takes care of %s to 'null' conversion? gcc printf > >> may do it but AFAIK it is undefined at the C library level. > >> > >> David > >> ----- > >> > >>> free handles null properly, too. So I think this is fine. > >>> > >>> If I remove the RM, I might break callers. E.g. > >> TestLogTouchedMethods.java. > >>> Also, in that test, all logged method names will accumulate in memory. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>> Sent: Thursday, February 11, 2016 9:41 AM > >>> To: Lindenmaier, Goetz > >>> Cc: hotspot-runtime-dev at openjdk.java.net > >>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string > >> stream > >>> > >>> Hi Goetz, > >>> > >>> Thank you for fixing this. I see you are restless :-) > >>> > >>> you should check the return value of os::strdup(). The change looks fine > >> otherwise, though I wonder whether we could just omit the > ResourceMark > >> and using the one of the caller. At least it is inconsistent, because > >> Symbol::print_utf8_on() does not have a ResourceMark either. > >>> > >>> Kind regards, Thomas > >>> > >>> > >>> > >>> On Thu, Feb 11, 2016 at 9:24 AM, Lindenmaier, Goetz > >> > > wrote: > >>> Hi > >>> > >>> Please review this change. I please need a sponsor. > >>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.01/ > >>> > >>> If a stringStream is passed to Symbol::print_symbol_on(), > >>> assertion "stringStream is re-allocated with a different ResourceMark." > can > >> fire in stringStream::write(const char* s, size_t len). > >>> This can be verified by running TestLogTouchedMethods.java after > adding > >> the patch below to the VM. > >>> > >>> My fix copies the string to locally managed memory before popping the > >> ResoreceMark. > >>> A better solution would be to guarantee enough space on the stream > >>> before doing the resource mark, but outputStream has no such > >>> method as 'ensureCapacity' or the like. > >>> Alternatively the ResourceMark could be skipped altogether. > >>> But then the aux memory used remains on the ResourceArea too long. > >>> Also, various ResourceMarks have to be added in other places. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> --- a/src/share/vm/runtime/java.cpp Wed Jan 13 11:33:21 2016 +0100 > >>> +++ b/src/share/vm/runtime/java.cpp Wed Feb 10 08:56:14 2016 > +0100 > >>> @@ -340,7 +340,10 @@ > >>> } > >>> > >>> if (LogTouchedMethods && PrintTouchedMethodsAtExit) { > >>> - Method::print_touched_methods(tty); > >>> + ResourceMark rm; > >>> + stringStream st(16); > >>> + Method::print_touched_methods(&st); > >>> + tty->print("%s", st.as_string()); > >>> } > >>> > >>> if (PrintBiasedLockingStatistics) { > >>> From david.holmes at oracle.com Fri Mar 4 08:54:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Mar 2016 18:54:58 +1000 Subject: RFR(S): 8149557: Resource mark breaks printing to string stream In-Reply-To: <9eb5886ef95d4b58a56ae99da710d789@DEWDFE13DE09.global.corp.sap> References: <26852801ffaa4671a95ee2e1b0077e57@DEWDFE13DE09.global.corp.sap> <56CA5C7C.5040606@oracle.com> <56D51A90.7030508@oracle.com> <9eb5886ef95d4b58a56ae99da710d789@DEWDFE13DE09.global.corp.sap> Message-ID: <56D94D62.1020204@oracle.com> Hi Goetz, I can sponsor, unless someone else grabs it first - my weekend has already started so I won't get to it for a couple of days. :) David On 4/03/2016 6:37 PM, Lindenmaier, Goetz wrote: > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, March 01, 2016 5:29 AM >> To: Lindenmaier, Goetz ; 'Thomas St?fe' >> >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string stream >> >> Hi Goetz, >> >> On 29/02/2016 11:09 PM, Lindenmaier, Goetz wrote: >>> Hi David, Thomas, >>> >>> you are right, I need to check for NULL. I had the linux >>> case in mind. >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.02/ >> >> I can't help but feel there is a bug in the Resource-area memory >> management code here. The problem as I understand it is that we have: >> >> void Symbol::print_symbol_on(outputStream* st) const { >> ResourceMark rm; >> st = st ? st : tty; >> st->print("%s", as_quoted_ascii()); >> } >> >> where we need the ResourceMark for the string returned by >> as_quoted_ascii. But if st is itself a resource-area object and needs to >> re-size in st->print then it does that in the context of the new >> ResourceMark, which fails the assert: "stringStream is re-allocated with >> a different ResourceMark." That seems to be the bug to me - a >> resource-area object that needs resizing should be able to do it in the >> context of an outer ResourceMark. :( >> >> So the workaround is to use a separate ResourceMark to call >> as_quoted_ascii and then copy the result to a malloc'd string, which is >> used for the st->print (which may realloc in the context of the existing >> outer ResourceMark) and is then free()'d. Yuck. :( > Yes, this exactly describes the situation. I wouldn't call it a bug in the Resource-area memory > management, but an unpleasant implementation detail of stringStream, that > makes it behave differently from its related classes. > >> >> Reluctantly Reviewed. > Thanks! > > Would you mind sponsoring? > > Best regards, > Goetz. > > >> >> Thanks, >> David >> >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Montag, 22. Februar 2016 01:55 >>>> To: Lindenmaier, Goetz ; 'Thomas St?fe' >>>> >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string >> stream >>>> >>>> On 19/02/2016 11:05 PM, Lindenmaier, Goetz wrote: >>>>> Hi Thomas, >>>>> >>>>> thanks for looking at this. >>>>> >>>>>> you should check the return value of os::strdup(). >>>>> strdup returns null on oom, %s should be ?null?, and >>>> >>>> What are you assuming takes care of %s to 'null' conversion? gcc printf >>>> may do it but AFAIK it is undefined at the C library level. >>>> >>>> David >>>> ----- >>>> >>>>> free handles null properly, too. So I think this is fine. >>>>> >>>>> If I remove the RM, I might break callers. E.g. >>>> TestLogTouchedMethods.java. >>>>> Also, in that test, all logged method names will accumulate in memory. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>>> Sent: Thursday, February 11, 2016 9:41 AM >>>>> To: Lindenmaier, Goetz >>>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string >>>> stream >>>>> >>>>> Hi Goetz, >>>>> >>>>> Thank you for fixing this. I see you are restless :-) >>>>> >>>>> you should check the return value of os::strdup(). The change looks fine >>>> otherwise, though I wonder whether we could just omit the >> ResourceMark >>>> and using the one of the caller. At least it is inconsistent, because >>>> Symbol::print_utf8_on() does not have a ResourceMark either. >>>>> >>>>> Kind regards, Thomas >>>>> >>>>> >>>>> >>>>> On Thu, Feb 11, 2016 at 9:24 AM, Lindenmaier, Goetz >>>> > >> wrote: >>>>> Hi >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.01/ >>>>> >>>>> If a stringStream is passed to Symbol::print_symbol_on(), >>>>> assertion "stringStream is re-allocated with a different ResourceMark." >> can >>>> fire in stringStream::write(const char* s, size_t len). >>>>> This can be verified by running TestLogTouchedMethods.java after >> adding >>>> the patch below to the VM. >>>>> >>>>> My fix copies the string to locally managed memory before popping the >>>> ResoreceMark. >>>>> A better solution would be to guarantee enough space on the stream >>>>> before doing the resource mark, but outputStream has no such >>>>> method as 'ensureCapacity' or the like. >>>>> Alternatively the ResourceMark could be skipped altogether. >>>>> But then the aux memory used remains on the ResourceArea too long. >>>>> Also, various ResourceMarks have to be added in other places. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> --- a/src/share/vm/runtime/java.cpp Wed Jan 13 11:33:21 2016 +0100 >>>>> +++ b/src/share/vm/runtime/java.cpp Wed Feb 10 08:56:14 2016 >> +0100 >>>>> @@ -340,7 +340,10 @@ >>>>> } >>>>> >>>>> if (LogTouchedMethods && PrintTouchedMethodsAtExit) { >>>>> - Method::print_touched_methods(tty); >>>>> + ResourceMark rm; >>>>> + stringStream st(16); >>>>> + Method::print_touched_methods(&st); >>>>> + tty->print("%s", st.as_string()); >>>>> } >>>>> >>>>> if (PrintBiasedLockingStatistics) { >>>>> From bengt.rutisson at oracle.com Fri Mar 4 09:47:41 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 4 Mar 2016 10:47:41 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D8F8F6.2030403@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> Message-ID: <56D959BD.1050601@oracle.com> On 2016-03-04 03:54, David Holmes wrote: > On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >> >> Hi Max and Mikael, >> >> On 2016-03-03 10:40, Mikael Gerdin wrote: >>> Hi Max, >>> >>> On 2016-03-01 23:30, Max Ockner wrote: >>>> Hello, >>>> >>>> Please review this small fix which attempts to shorten the output from >>>> -Xlog:classresolve=info to an acceptable length. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>> >>>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>>> lines of output. This is unacceptably verbose for info level >>>> logging and >>>> most of the output is not useful. >>>> >>>> "java -Xlog:classresolve=info -version" used to produce: >>>> - 3,683 total lines of output. >>>> - 3,121 total lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 1,329 unique lines of output. >>>> - 767 unique lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 562 total lines of output from all other sources, all >>>> unique. >>>> >>>> The code in ConstantPool which called >>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>> >>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>> else { resolve the class } >>>> >>>> So if logging was turned on, the class would not be resolved properly, >>>> but it would produce a log entry saying that the class was being >>>> resolved. As a result, the constant pool entry would still contain a >>>> Symbol* the next time this piece of code was reached, and it would >>>> produce yet another classresolve log entry. In some cases, this was >>>> producing many consecutive identical log entries, taking up full pages >>>> at worst, and averaging a little over 4 duplicates per message. Not >>>> cool. >>>> >>>> The above duplication issue has been fixed, and the >>>> ConstantPool::trace_class_resolution output has been moved to the >>>> debug >>>> leve. There are still 562 unique lines of output for "java >>>> -Xlog:classresolve=info -version". There are now 767 additional unique >>>> lines of output when for the "java -Xlog:classresolve=debug >>>> -version" . >>>> This is better than before but still quite a lot. It seems like >>>> all of >>>> the info level output is equally important(or unimportant), as you can >>>> see in the sample below: >>>> >>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>> (super) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.GenericDeclaration (interface) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.AnnotatedElement (interface) >>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>>> (interface) >>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>> (super) >>>> >>>> How do you feel about this? Possible solutions include setting all >>>> output to debug level, or removing some of the logging messages. >>> >>> As I stated in the bug my personal opinion is that "info" level >>> logging should be fairly limited in order to make "-Xlog:all" a useful >>> flag to get a reasonable amount of output about what is happening in a >>> JVM. >>> >>> One approach could be to move the most verbose output to >>> classresolve=trace and keep the rest of classresolve output on the >>> debug level. >>> >>> The fact that the flag was called "TraceClassResolution" is in my mind >>> a hint that if it produces large amounts of output then perhaps that >>> output should be logged on the "trace" log level. >> >> +1 for this approach. > > As I wrote in the bug report there are philosophically quite different > ways to view the the three logging levels - and this has been > discussed before. I view "info", "debug" and "trace" as three levels > of logging applicable to any chosen tag. Others view them as some > global indicator of priority/importance such that some "less > important" tags will never use "info" because their output is not > considered worthy - only in this world is "-Xlog:all" considered useful. > > If I say -Xlog:foo I expect to see some logging for foo. But even if you look at it as that the levels only are applicable for a particular tag, why would you want "info" on that tag to produce extreme amounts of data? I would expect -Xlog:foo to give me reasonable high level info about foo. If I want more details I would use -Xlog:foo=debug. And if "info" for each individual tag logs a sensible amount of data, then -Xlog:all will work pretty well for most cases. Bengt > > David > ----- > > >> I quite agree with Mikael that we should be a bit careful what we log at >> info level. >> >> Thanks, >> Bengt >> >>> >>> /Mikael >>> >>>> >>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>> modified to check for the new output. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> From david.holmes at oracle.com Fri Mar 4 10:25:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Mar 2016 20:25:15 +1000 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D959BD.1050601@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> Message-ID: <56D9628B.3040306@oracle.com> On 4/03/2016 7:47 PM, Bengt Rutisson wrote: > > > On 2016-03-04 03:54, David Holmes wrote: >> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>> >>> Hi Max and Mikael, >>> >>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>> Hi Max, >>>> >>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix which attempts to shorten the output from >>>>> -Xlog:classresolve=info to an acceptable length. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>> >>>>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>>>> lines of output. This is unacceptably verbose for info level >>>>> logging and >>>>> most of the output is not useful. >>>>> >>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>> - 3,683 total lines of output. >>>>> - 3,121 total lines of output from >>>>> ConstantPool::trace_class_resolution(). >>>>> - 1,329 unique lines of output. >>>>> - 767 unique lines of output from >>>>> ConstantPool::trace_class_resolution(). >>>>> - 562 total lines of output from all other sources, all >>>>> unique. >>>>> >>>>> The code in ConstantPool which called >>>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>>> >>>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>>> else { resolve the class } >>>>> >>>>> So if logging was turned on, the class would not be resolved properly, >>>>> but it would produce a log entry saying that the class was being >>>>> resolved. As a result, the constant pool entry would still contain a >>>>> Symbol* the next time this piece of code was reached, and it would >>>>> produce yet another classresolve log entry. In some cases, this was >>>>> producing many consecutive identical log entries, taking up full pages >>>>> at worst, and averaging a little over 4 duplicates per message. Not >>>>> cool. >>>>> >>>>> The above duplication issue has been fixed, and the >>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>> debug >>>>> leve. There are still 562 unique lines of output for "java >>>>> -Xlog:classresolve=info -version". There are now 767 additional unique >>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>> -version" . >>>>> This is better than before but still quite a lot. It seems like >>>>> all of >>>>> the info level output is equally important(or unimportant), as you can >>>>> see in the sample below: >>>>> >>>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>>> (super) >>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>> (interface) >>>>> [0.026s][info][classresolve] java.lang.Class >>>>> java.lang.reflect.GenericDeclaration (interface) >>>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>>> (interface) >>>>> [0.026s][info][classresolve] java.lang.Class >>>>> java.lang.reflect.AnnotatedElement (interface) >>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>>>> (interface) >>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>> (super) >>>>> >>>>> How do you feel about this? Possible solutions include setting all >>>>> output to debug level, or removing some of the logging messages. >>>> >>>> As I stated in the bug my personal opinion is that "info" level >>>> logging should be fairly limited in order to make "-Xlog:all" a useful >>>> flag to get a reasonable amount of output about what is happening in a >>>> JVM. >>>> >>>> One approach could be to move the most verbose output to >>>> classresolve=trace and keep the rest of classresolve output on the >>>> debug level. >>>> >>>> The fact that the flag was called "TraceClassResolution" is in my mind >>>> a hint that if it produces large amounts of output then perhaps that >>>> output should be logged on the "trace" log level. >>> >>> +1 for this approach. >> >> As I wrote in the bug report there are philosophically quite different >> ways to view the the three logging levels - and this has been >> discussed before. I view "info", "debug" and "trace" as three levels >> of logging applicable to any chosen tag. Others view them as some >> global indicator of priority/importance such that some "less >> important" tags will never use "info" because their output is not >> considered worthy - only in this world is "-Xlog:all" considered useful. >> >> If I say -Xlog:foo I expect to see some logging for foo. > > But even if you look at it as that the levels only are applicable for a > particular tag, why would you want "info" on that tag to produce extreme > amounts of data? I would expect -Xlog:foo to give me reasonable high > level info about foo. If I want more details I would use -Xlog:foo=debug. It all depends on what you are logging. If it is a high frequency event then you will get a lot of data even at info levels. David ----- > And if "info" for each individual tag logs a sensible amount of data, > then -Xlog:all will work pretty well for most cases. > > Bengt > >> >> David >> ----- >> >> >>> I quite agree with Mikael that we should be a bit careful what we log at >>> info level. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> /Mikael >>>> >>>>> >>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>> modified to check for the new output. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>> > From dmitry.dmitriev at oracle.com Fri Mar 4 11:38:06 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 4 Mar 2016 14:38:06 +0300 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D8A028.5090201@oracle.com> References: <56D8A028.5090201@oracle.com> Message-ID: <56D9739E.1020909@oracle.com> Hi Rachel, Overall looks good. Few test comments: 1) Import of WeakReference seems unneeded. 2) For "-Xlog:safepointcleanup=off" test case you have "output.shouldNotContain("[safepointcleanup]");". Is it make sense to add "output.shouldContain("[safepointcleanup]")" for case when log is enabled? 3) I think you should add test case for aliased option. Thank you, Dmitry On 03.03.2016 23:35, Rachel Protacio wrote: > Hello! > > Coming close to the end of the logging conversions for now! Here's one > for TraceSafepointCleanupTime, which is turning into > -Xlog:safepointcleanup=info. As it has been a product option, it is > aliased in this change. > > To reiterate the conclusion from the TraceStartupTime conversion, I > ask that as long as there are no objections to the correctness of the > code, we allow this implementation for now, and I will then file a > follow-up bug for possible improvements to the switch statement and > TraceTime function signature situation. Since this is the only other > "TraceTime" conversion, TraceTime implementation changes will be more > succinctly addressable after this SafepointCleanupTime change than > before it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ > > Sample old output: > > $ java -XX:+TraceSafepointCleanupTime -version > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-03-02-133604.rprotaci.8150083) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) > [deflating idle monitors, 0.0000088 secs] > [updating inline caches, 0.0000007 secs] > [compilation policy safepoint handler, 0.0000009 secs] > [mark nmethods, 0.0000164 secs] > [purging class loader data graph, 0.0000002 secs] > > Sample new output: > > $ java -Xlog:safepointcleanup -version > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-03-02-133610.rprotaci.8149991) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) > [0.348s][info][safepointcleanup] deflating idle monitors, 0.0000059 > secs > [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 > secs > [0.348s][info][safepointcleanup] compilation policy safepoint > handler, 0.0000006 secs > [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs > [0.348s][info][safepointcleanup] purging class loader data graph, > 0.0000001 secs > > > Tested using JPRT and RBT hotspot and non-colo tests. > > Thanks! > Rachel > > From bengt.rutisson at oracle.com Fri Mar 4 12:02:46 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 4 Mar 2016 13:02:46 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D9628B.3040306@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> <56D9628B.3040306@oracle.com> Message-ID: <56D97966.2060007@oracle.com> On 2016-03-04 11:25, David Holmes wrote: > On 4/03/2016 7:47 PM, Bengt Rutisson wrote: >> >> >> On 2016-03-04 03:54, David Holmes wrote: >>> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>>> >>>> Hi Max and Mikael, >>>> >>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>> Hi Max, >>>>> >>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this small fix which attempts to shorten the output >>>>>> from >>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>> >>>>>> Summary: java '-Xlog:classresolve=info -version' used to produce >>>>>> 3,683 >>>>>> lines of output. This is unacceptably verbose for info level >>>>>> logging and >>>>>> most of the output is not useful. >>>>>> >>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>> - 3,683 total lines of output. >>>>>> - 3,121 total lines of output from >>>>>> ConstantPool::trace_class_resolution(). >>>>>> - 1,329 unique lines of output. >>>>>> - 767 unique lines of output from >>>>>> ConstantPool::trace_class_resolution(). >>>>>> - 562 total lines of output from all other sources, all >>>>>> unique. >>>>>> >>>>>> The code in ConstantPool which called >>>>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>>>> >>>>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>>>> else { resolve the class } >>>>>> >>>>>> So if logging was turned on, the class would not be resolved >>>>>> properly, >>>>>> but it would produce a log entry saying that the class was being >>>>>> resolved. As a result, the constant pool entry would still contain a >>>>>> Symbol* the next time this piece of code was reached, and it would >>>>>> produce yet another classresolve log entry. In some cases, this was >>>>>> producing many consecutive identical log entries, taking up full >>>>>> pages >>>>>> at worst, and averaging a little over 4 duplicates per message. Not >>>>>> cool. >>>>>> >>>>>> The above duplication issue has been fixed, and the >>>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>>> debug >>>>>> leve. There are still 562 unique lines of output for "java >>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>> unique >>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>> -version" . >>>>>> This is better than before but still quite a lot. It seems like >>>>>> all of >>>>>> the info level output is equally important(or unimportant), as >>>>>> you can >>>>>> see in the sample below: >>>>>> >>>>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>>>> (super) >>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>> (super) >>>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>>> (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>>>> (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>> java.io.Serializable >>>>>> (interface) >>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>>> (super) >>>>>> >>>>>> How do you feel about this? Possible solutions include setting all >>>>>> output to debug level, or removing some of the logging messages. >>>>> >>>>> As I stated in the bug my personal opinion is that "info" level >>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>> useful >>>>> flag to get a reasonable amount of output about what is happening >>>>> in a >>>>> JVM. >>>>> >>>>> One approach could be to move the most verbose output to >>>>> classresolve=trace and keep the rest of classresolve output on the >>>>> debug level. >>>>> >>>>> The fact that the flag was called "TraceClassResolution" is in my >>>>> mind >>>>> a hint that if it produces large amounts of output then perhaps that >>>>> output should be logged on the "trace" log level. >>>> >>>> +1 for this approach. >>> >>> As I wrote in the bug report there are philosophically quite different >>> ways to view the the three logging levels - and this has been >>> discussed before. I view "info", "debug" and "trace" as three levels >>> of logging applicable to any chosen tag. Others view them as some >>> global indicator of priority/importance such that some "less >>> important" tags will never use "info" because their output is not >>> considered worthy - only in this world is "-Xlog:all" considered >>> useful. >>> >>> If I say -Xlog:foo I expect to see some logging for foo. >> >> But even if you look at it as that the levels only are applicable for a >> particular tag, why would you want "info" on that tag to produce extreme >> amounts of data? I would expect -Xlog:foo to give me reasonable high >> level info about foo. If I want more details I would use >> -Xlog:foo=debug. > > It all depends on what you are logging. If it is a high frequency > event then you will get a lot of data even at info levels. But that's my point. If it is a high frequency event you probably don't want to log every event at the info level. That will be useless information. What you probably want to do is aggregate and log useful information less frequently. Then if someone needs to dig into the detail they would enable more logging at debug or trace level to see every individual event. Bengt > > David > ----- > >> And if "info" for each individual tag logs a sensible amount of data, >> then -Xlog:all will work pretty well for most cases. >> >> Bengt >> >>> >>> David >>> ----- >>> >>> >>>> I quite agree with Mikael that we should be a bit careful what we >>>> log at >>>> info level. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>>> modified to check for the new output. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>> >> From aleksey.shipilev at oracle.com Fri Mar 4 13:28:19 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 4 Mar 2016 16:28:19 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D74B4B.9090708@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> Message-ID: <56D98D73.4010302@oracle.com> On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: > On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>> with? This will avoid leaking StackTraceElement constructor into >>> standard library, *and* allows to make StackTraceElement fields final. >>> Taking stuff back from the standard library is hard, if not impossible, >>> so we better expose as little as possible. >> >> We measured that it's faster to allocate the StackTraceElement array >> in Java and it seems cleaner to the Java guys. It came from similar >> code we've been prototyping for StackFrameInfo. > > OK, it's not perfectly clean from implementation standpoint, but this > RFE might not be the best opportunity to polish that. At least make > StackTraceElement constructor private (better), or package-private > (acceptable), and then we are good to go. Okay, here's a little exploration: http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java The difference between allocating in Java code, and allocating on VM side is marginal on my machine, but I think we are down to native memset performance when allocating on VM side. Therefore, I'd probably stay with Java allocation which codegen we absolutely control. Aside: see the last experiment, avoiding StringTable::intern (shows in profiles a lot!) trims down construction costs down even further. I'd think that is a worthwhile improvement to consider. Cheers, -Aleksey From max.ockner at oracle.com Fri Mar 4 17:37:05 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 04 Mar 2016 12:37:05 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D97966.2060007@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> <56D9628B.3040306@oracle.com> <56D97966.2060007@oracle.com> Message-ID: <56D9C7C1.6030601@oracle.com> We have tried to preserve some of the output exactly (or very close to) the way it was. Some of the corresponding tags produce a ton of output. In the case of classresolve, you can not shrink the output anymore without changing its meaning, since there is no redundant info. I can't think of a good way to split the output across multiple levels since all of the output seems equally verbose and equally useful. It originally seemed like the output from ConstantPool might be the most verbose, and would therefore deserve to live at the Debug level, but it only seemed that way because of a subtle flaw in the existing logging which exploded the output by a factor of 4. So I don't think it would be appropriate to split the output for classresolve over several levels. Would you rather see ~1300 unique logging messages for classresolve on the Info level or on the Debug level? As a side thought, I wonder if Xlog: should default to the most course level which produces output for the specified tag. That way, setting the classresolve output to Debug level would be OK. Logging "-Xlog:all" could avoid printing 1300 lines for the "classresolve" tag, and "-Xlog:classresolve" would display the output for the classresolve tag even though it is debug level. Just a thought. Thanks, Max On 3/4/2016 7:02 AM, Bengt Rutisson wrote: > > > On 2016-03-04 11:25, David Holmes wrote: >> On 4/03/2016 7:47 PM, Bengt Rutisson wrote: >>> >>> >>> On 2016-03-04 03:54, David Holmes wrote: >>>> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi Max and Mikael, >>>>> >>>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix which attempts to shorten the >>>>>>> output from >>>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>>> >>>>>>> Summary: java '-Xlog:classresolve=info -version' used to produce >>>>>>> 3,683 >>>>>>> lines of output. This is unacceptably verbose for info level >>>>>>> logging and >>>>>>> most of the output is not useful. >>>>>>> >>>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>>> - 3,683 total lines of output. >>>>>>> - 3,121 total lines of output from >>>>>>> ConstantPool::trace_class_resolution(). >>>>>>> - 1,329 unique lines of output. >>>>>>> - 767 unique lines of output from >>>>>>> ConstantPool::trace_class_resolution(). >>>>>>> - 562 total lines of output from all other sources, all >>>>>>> unique. >>>>>>> >>>>>>> The code in ConstantPool which called >>>>>>> ConstantPool::trace_class_resolution() was doing approximately >>>>>>> this: >>>>>>> >>>>>>> if (log_is_enabled(Info,classresolve)){ >>>>>>> trace_class_resolution(...)} >>>>>>> else { resolve the class } >>>>>>> >>>>>>> So if logging was turned on, the class would not be resolved >>>>>>> properly, >>>>>>> but it would produce a log entry saying that the class was being >>>>>>> resolved. As a result, the constant pool entry would still >>>>>>> contain a >>>>>>> Symbol* the next time this piece of code was reached, and it would >>>>>>> produce yet another classresolve log entry. In some cases, this >>>>>>> was >>>>>>> producing many consecutive identical log entries, taking up full >>>>>>> pages >>>>>>> at worst, and averaging a little over 4 duplicates per message. Not >>>>>>> cool. >>>>>>> >>>>>>> The above duplication issue has been fixed, and the >>>>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>>>> debug >>>>>>> leve. There are still 562 unique lines of output for "java >>>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>>> unique >>>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>>> -version" . >>>>>>> This is better than before but still quite a lot. It seems like >>>>>>> all of >>>>>>> the info level output is equally important(or unimportant), as >>>>>>> you can >>>>>>> see in the sample below: >>>>>>> >>>>>>> [0.026s][info][classresolve] java.lang.reflect.Type >>>>>>> java.lang.Object >>>>>>> (super) >>>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>>> (super) >>>>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>>>> (interface) >>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>>>>> (interface) >>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>>>> (super) >>>>>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>>>>> (super) >>>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>>> (super) >>>>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>>>> (super) >>>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>>> java.io.Serializable >>>>>>> (interface) >>>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>>> (super) >>>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>>>> (super) >>>>>>> >>>>>>> How do you feel about this? Possible solutions include setting all >>>>>>> output to debug level, or removing some of the logging messages. >>>>>> >>>>>> As I stated in the bug my personal opinion is that "info" level >>>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>>> useful >>>>>> flag to get a reasonable amount of output about what is happening >>>>>> in a >>>>>> JVM. >>>>>> >>>>>> One approach could be to move the most verbose output to >>>>>> classresolve=trace and keep the rest of classresolve output on the >>>>>> debug level. >>>>>> >>>>>> The fact that the flag was called "TraceClassResolution" is in my >>>>>> mind >>>>>> a hint that if it produces large amounts of output then perhaps that >>>>>> output should be logged on the "trace" log level. >>>>> >>>>> +1 for this approach. >>>> >>>> As I wrote in the bug report there are philosophically quite different >>>> ways to view the the three logging levels - and this has been >>>> discussed before. I view "info", "debug" and "trace" as three levels >>>> of logging applicable to any chosen tag. Others view them as some >>>> global indicator of priority/importance such that some "less >>>> important" tags will never use "info" because their output is not >>>> considered worthy - only in this world is "-Xlog:all" considered >>>> useful. >>>> >>>> If I say -Xlog:foo I expect to see some logging for foo. >>> >>> But even if you look at it as that the levels only are applicable for a >>> particular tag, why would you want "info" on that tag to produce >>> extreme >>> amounts of data? I would expect -Xlog:foo to give me reasonable high >>> level info about foo. If I want more details I would use >>> -Xlog:foo=debug. >> >> It all depends on what you are logging. If it is a high frequency >> event then you will get a lot of data even at info levels. > > But that's my point. If it is a high frequency event you probably > don't want to log every event at the info level. That will be useless > information. What you probably want to do is aggregate and log useful > information less frequently. Then if someone needs to dig into the > detail they would enable more logging at debug or trace level to see > every individual event. > > Bengt > >> >> David >> ----- >> >>> And if "info" for each individual tag logs a sensible amount of data, >>> then -Xlog:all will work pretty well for most cases. >>> >>> Bengt >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> I quite agree with Mikael that we should be a bit careful what we >>>>> log at >>>>> info level. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>>>> modified to check for the new output. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>> >>> > From john.r.rose at oracle.com Fri Mar 4 18:42:39 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Mar 2016 10:42:39 -0800 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D98D73.4010302@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> Message-ID: <08051172-BCC1-4C60-A8DE-11407BE3D07F@oracle.com> Doing more on the Java side means it will be easier generate strings lazily, only if the exception actually prints or presents STEs. All we need to store eagerly per frame is a MemberName and a BCI. ? John > On Mar 4, 2016, at 5:28 AM, Aleksey Shipilev wrote: > >> On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: >>> On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not impossible, >>>> so we better expose as little as possible. >>> >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. It came from similar >>> code we've been prototyping for StackFrameInfo. >> >> OK, it's not perfectly clean from implementation standpoint, but this >> RFE might not be the best opportunity to polish that. At least make >> StackTraceElement constructor private (better), or package-private >> (acceptable), and then we are good to go. > > Okay, here's a little exploration: > http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java > > The difference between allocating in Java code, and allocating on VM > side is marginal on my machine, but I think we are down to native memset > performance when allocating on VM side. Therefore, I'd probably stay > with Java allocation which codegen we absolutely control. > > Aside: see the last experiment, avoiding StringTable::intern (shows in > profiles a lot!) trims down construction costs down even further. I'd > think that is a worthwhile improvement to consider. > > Cheers, > -Aleksey > > From rachel.protacio at oracle.com Fri Mar 4 20:15:13 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 4 Mar 2016 15:15:13 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D8AF8A.4080806@oracle.com> References: <56D8A028.5090201@oracle.com> <56D8ACC3.2080201@oracle.com> <56D8ACF8.6010502@oracle.com> <56D8AF8A.4080806@oracle.com> Message-ID: <56D9ECD1.3060507@oracle.com> Thanks, Max! Rachel On 3/3/2016 4:41 PM, Max Ockner wrote: > Looks good to me. > > Max > > On 3/3/2016 4:30 PM, Rachel Protacio wrote: >> Thanks, Harold! >> Rachel >> >> On 3/3/2016 4:29 PM, harold seigel wrote: >>> Hi Rachel, >>> >>> The changes look good. >>> >>> Harold >>> >>> On 3/3/2016 3:35 PM, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Coming close to the end of the logging conversions for now! Here's >>>> one for TraceSafepointCleanupTime, which is turning into >>>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>>> aliased in this change. >>>> >>>> To reiterate the conclusion from the TraceStartupTime conversion, I >>>> ask that as long as there are no objections to the correctness of >>>> the code, we allow this implementation for now, and I will then >>>> file a follow-up bug for possible improvements to the switch >>>> statement and TraceTime function signature situation. Since this is >>>> the only other "TraceTime" conversion, TraceTime implementation >>>> changes will be more succinctly addressable after this >>>> SafepointCleanupTime change than before it. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>>> >>>> Sample old output: >>>> >>>> $ java -XX:+TraceSafepointCleanupTime -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>>> [deflating idle monitors, 0.0000088 secs] >>>> [updating inline caches, 0.0000007 secs] >>>> [compilation policy safepoint handler, 0.0000009 secs] >>>> [mark nmethods, 0.0000164 secs] >>>> [purging class loader data graph, 0.0000002 secs] >>>> >>>> Sample new output: >>>> >>>> $ java -Xlog:safepointcleanup -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>>> [0.348s][info][safepointcleanup] deflating idle monitors, >>>> 0.0000059 secs >>>> [0.348s][info][safepointcleanup] updating inline caches, >>>> 0.0000009 secs >>>> [0.348s][info][safepointcleanup] compilation policy safepoint >>>> handler, 0.0000006 secs >>>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>>> [0.348s][info][safepointcleanup] purging class loader data graph, >>>> 0.0000001 secs >>>> >>>> >>>> Tested using JPRT and RBT hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> > From rachel.protacio at oracle.com Fri Mar 4 20:22:13 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 4 Mar 2016 15:22:13 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D9739E.1020909@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> Message-ID: <56D9EE75.5020109@oracle.com> Hi Dmitry, Thanks for the review! I've fixed the test as requested :) New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ Rachel On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: > Hi Rachel, > > Overall looks good. Few test comments: > 1) Import of WeakReference seems unneeded. > 2) For "-Xlog:safepointcleanup=off" test case you have > "output.shouldNotContain("[safepointcleanup]");". Is it make sense to > add "output.shouldContain("[safepointcleanup]")" for case when log is > enabled? > 3) I think you should add test case for aliased option. > > Thank you, > Dmitry > > On 03.03.2016 23:35, Rachel Protacio wrote: >> Hello! >> >> Coming close to the end of the logging conversions for now! Here's >> one for TraceSafepointCleanupTime, which is turning into >> -Xlog:safepointcleanup=info. As it has been a product option, it is >> aliased in this change. >> >> To reiterate the conclusion from the TraceStartupTime conversion, I >> ask that as long as there are no objections to the correctness of the >> code, we allow this implementation for now, and I will then file a >> follow-up bug for possible improvements to the switch statement and >> TraceTime function signature situation. Since this is the only other >> "TraceTime" conversion, TraceTime implementation changes will be more >> succinctly addressable after this SafepointCleanupTime change than >> before it. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >> >> Sample old output: >> >> $ java -XX:+TraceSafepointCleanupTime -version >> java version "9-internal" >> Java(TM) SE Runtime Environment (fastdebug build >> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >> [deflating idle monitors, 0.0000088 secs] >> [updating inline caches, 0.0000007 secs] >> [compilation policy safepoint handler, 0.0000009 secs] >> [mark nmethods, 0.0000164 secs] >> [purging class loader data graph, 0.0000002 secs] >> >> Sample new output: >> >> $ java -Xlog:safepointcleanup -version >> java version "9-internal" >> Java(TM) SE Runtime Environment (fastdebug build >> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >> [0.348s][info][safepointcleanup] deflating idle monitors, >> 0.0000059 secs >> [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 >> secs >> [0.348s][info][safepointcleanup] compilation policy safepoint >> handler, 0.0000006 secs >> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >> [0.348s][info][safepointcleanup] purging class loader data graph, >> 0.0000001 secs >> >> >> Tested using JPRT and RBT hotspot and non-colo tests. >> >> Thanks! >> Rachel >> >> > From dmitry.dmitriev at oracle.com Fri Mar 4 20:36:02 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 4 Mar 2016 23:36:02 +0300 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D9EE75.5020109@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> Message-ID: <56D9F1B2.9020309@oracle.com> Rachel, looks good to me! Thanks, Dmitry On 04.03.2016 23:22, Rachel Protacio wrote: > Hi Dmitry, > > Thanks for the review! I've fixed the test as requested :) > > New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ > > Rachel > > On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >> Hi Rachel, >> >> Overall looks good. Few test comments: >> 1) Import of WeakReference seems unneeded. >> 2) For "-Xlog:safepointcleanup=off" test case you have >> "output.shouldNotContain("[safepointcleanup]");". Is it make sense to >> add "output.shouldContain("[safepointcleanup]")" for case when log is >> enabled? >> 3) I think you should add test case for aliased option. >> >> Thank you, >> Dmitry >> >> On 03.03.2016 23:35, Rachel Protacio wrote: >>> Hello! >>> >>> Coming close to the end of the logging conversions for now! Here's >>> one for TraceSafepointCleanupTime, which is turning into >>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>> aliased in this change. >>> >>> To reiterate the conclusion from the TraceStartupTime conversion, I >>> ask that as long as there are no objections to the correctness of >>> the code, we allow this implementation for now, and I will then file >>> a follow-up bug for possible improvements to the switch statement >>> and TraceTime function signature situation. Since this is the only >>> other "TraceTime" conversion, TraceTime implementation changes will >>> be more succinctly addressable after this SafepointCleanupTime >>> change than before it. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>> >>> Sample old output: >>> >>> $ java -XX:+TraceSafepointCleanupTime -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>> [deflating idle monitors, 0.0000088 secs] >>> [updating inline caches, 0.0000007 secs] >>> [compilation policy safepoint handler, 0.0000009 secs] >>> [mark nmethods, 0.0000164 secs] >>> [purging class loader data graph, 0.0000002 secs] >>> >>> Sample new output: >>> >>> $ java -Xlog:safepointcleanup -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>> [0.348s][info][safepointcleanup] deflating idle monitors, >>> 0.0000059 secs >>> [0.348s][info][safepointcleanup] updating inline caches, >>> 0.0000009 secs >>> [0.348s][info][safepointcleanup] compilation policy safepoint >>> handler, 0.0000006 secs >>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>> [0.348s][info][safepointcleanup] purging class loader data graph, >>> 0.0000001 secs >>> >>> >>> Tested using JPRT and RBT hotspot and non-colo tests. >>> >>> Thanks! >>> Rachel >>> >>> >> > From rachel.protacio at oracle.com Fri Mar 4 21:42:45 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 4 Mar 2016 16:42:45 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging Message-ID: <56DA0155.7090507@oracle.com> Hello, Please review this conversion of -XX:+VerboseVerification to -Xlog:verboseverification=info. Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ Sample old output: Verifying class hello with new format Verifying method hello.()V StackMapTable: frame_count = 0 table = { } bci: @0 flags: { flagThisUninit } locals: { uninitializedThis } stack: { } offset = 0, opcode = aload_0 bci: @1 flags: { flagThisUninit } locals: { uninitializedThis } stack: { uninitializedThis } offset = 1, opcode = invokespecial bci: @4 flags: { } locals: { 'hello' } stack: { } offset = 4, opcode = return Verifying method hello.main([Ljava/lang/String;)V Sample new output: [0.696s][info][verboseverification] Verifying class VerboseVerificationTest$InternalClass with new format [0.696s][info][verboseverification] Verifying method VerboseVerificationTest$InternalClass.()V [0.696s][info][verboseverification] StackMapTable: frame_count = 0 [0.696s][info][verboseverification] table = { [0.696s][info][verboseverification] } [0.696s][info][verboseverification] bci: @0 [0.696s][info][verboseverification] flags: { flagThisUninit } [0.696s][info][verboseverification] locals: { uninitializedThis } [0.696s][info][verboseverification] stack: { } [0.696s][info][verboseverification] offset = 0, opcode = aload_0 [0.696s][info][verboseverification] bci: @1 [0.696s][info][verboseverification] flags: { flagThisUninit } [0.696s][info][verboseverification] locals: { uninitializedThis } [0.696s][info][verboseverification] stack: { uninitializedThis } [0.696s][info][verboseverification] offset = 1, opcode = invokespecial [0.696s][info][verboseverification] bci: @4 [0.696s][info][verboseverification] flags: { } [0.696s][info][verboseverification] locals: { 'VerboseVerificationTest$InternalClass' } [0.696s][info][verboseverification] stack: { } [0.696s][info][verboseverification] offset = 4, opcode = return [0.696s][info][verboseverification] Verifying method VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and non-colo tests. Thank you, Rachel From rachel.protacio at oracle.com Fri Mar 4 21:45:41 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 4 Mar 2016 16:45:41 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D9F1B2.9020309@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> <56D9F1B2.9020309@oracle.com> Message-ID: <56DA0205.1040700@oracle.com> Thank you, Dmitry! Rachel On 3/4/2016 3:36 PM, Dmitry Dmitriev wrote: > Rachel, looks good to me! > > Thanks, > Dmitry > > On 04.03.2016 23:22, Rachel Protacio wrote: >> Hi Dmitry, >> >> Thanks for the review! I've fixed the test as requested :) >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ >> >> Rachel >> >> On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >>> Hi Rachel, >>> >>> Overall looks good. Few test comments: >>> 1) Import of WeakReference seems unneeded. >>> 2) For "-Xlog:safepointcleanup=off" test case you have >>> "output.shouldNotContain("[safepointcleanup]");". Is it make sense >>> to add "output.shouldContain("[safepointcleanup]")" for case when >>> log is enabled? >>> 3) I think you should add test case for aliased option. >>> >>> Thank you, >>> Dmitry >>> >>> On 03.03.2016 23:35, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Coming close to the end of the logging conversions for now! Here's >>>> one for TraceSafepointCleanupTime, which is turning into >>>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>>> aliased in this change. >>>> >>>> To reiterate the conclusion from the TraceStartupTime conversion, I >>>> ask that as long as there are no objections to the correctness of >>>> the code, we allow this implementation for now, and I will then >>>> file a follow-up bug for possible improvements to the switch >>>> statement and TraceTime function signature situation. Since this is >>>> the only other "TraceTime" conversion, TraceTime implementation >>>> changes will be more succinctly addressable after this >>>> SafepointCleanupTime change than before it. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>>> >>>> Sample old output: >>>> >>>> $ java -XX:+TraceSafepointCleanupTime -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>>> [deflating idle monitors, 0.0000088 secs] >>>> [updating inline caches, 0.0000007 secs] >>>> [compilation policy safepoint handler, 0.0000009 secs] >>>> [mark nmethods, 0.0000164 secs] >>>> [purging class loader data graph, 0.0000002 secs] >>>> >>>> Sample new output: >>>> >>>> $ java -Xlog:safepointcleanup -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>>> [0.348s][info][safepointcleanup] deflating idle monitors, >>>> 0.0000059 secs >>>> [0.348s][info][safepointcleanup] updating inline caches, >>>> 0.0000009 secs >>>> [0.348s][info][safepointcleanup] compilation policy safepoint >>>> handler, 0.0000006 secs >>>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>>> [0.348s][info][safepointcleanup] purging class loader data graph, >>>> 0.0000001 secs >>>> >>>> >>>> Tested using JPRT and RBT hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> > From mandy.chung at oracle.com Fri Mar 4 22:00:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Mar 2016 14:00:15 -0800 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <08051172-BCC1-4C60-A8DE-11407BE3D07F@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <08051172-BCC1-4C60-A8DE-11407BE3D07F@oracle.com> Message-ID: <0EFF60C2-B20E-4075-9355-3FD11A486AFD@oracle.com> > On Mar 4, 2016, at 10:42 AM, John Rose wrote: > > Doing more on the Java side means it will be easier generate strings lazily, only if the exception actually prints or presents STEs. > > All we need to store eagerly per frame is a MemberName and a BCI. This is what StackWalker stores in StackFrameInfo per frame. I wish we could convert Throwable backtrace with the stack walker API. Footprint of MemberName as well as GC pressure (as they are kept as weak references in VM) are the performance concern that we will have to look at it in a future release. Mandy > > ? John > >> On Mar 4, 2016, at 5:28 AM, Aleksey Shipilev wrote: >> >>> On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: >>>> On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >>>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>> Is there an underlying reason why we can't return the pre-filled >>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>>> with? This will avoid leaking StackTraceElement constructor into >>>>> standard library, *and* allows to make StackTraceElement fields final. >>>>> Taking stuff back from the standard library is hard, if not impossible, >>>>> so we better expose as little as possible. >>>> >>>> We measured that it's faster to allocate the StackTraceElement array >>>> in Java and it seems cleaner to the Java guys. It came from similar >>>> code we've been prototyping for StackFrameInfo. >>> >>> OK, it's not perfectly clean from implementation standpoint, but this >>> RFE might not be the best opportunity to polish that. At least make >>> StackTraceElement constructor private (better), or package-private >>> (acceptable), and then we are good to go. >> >> Okay, here's a little exploration: >> http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java >> >> The difference between allocating in Java code, and allocating on VM >> side is marginal on my machine, but I think we are down to native memset >> performance when allocating on VM side. Therefore, I'd probably stay >> with Java allocation which codegen we absolutely control. >> >> Aside: see the last experiment, avoiding StringTable::intern (shows in >> profiles a lot!) trims down construction costs down even further. I'd >> think that is a worthwhile improvement to consider. >> >> Cheers, >> -Aleksey >> >> From john.r.rose at oracle.com Fri Mar 4 22:49:06 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Mar 2016 14:49:06 -0800 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <0EFF60C2-B20E-4075-9355-3FD11A486AFD@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <08051172-BCC1-4C60-A8DE-11407BE3D07F@oracle.com> <0EFF60C2-B20E-4075-9355-3FD11A486AFD@oracle.com> Message-ID: <62FC4886-B2E6-44FC-BE75-64E916E68391@oracle.com> On Mar 4, 2016, at 2:00 PM, Mandy Chung wrote: > > Footprint of MemberName as well as GC pressure (as they are kept as weak references in VM) are the performance concern that we will have to look at it in a future release. I hope we can increase our investment on MemberName as an all-purpose handle from Java to JVM metadata (like java.lang.Class). Specifically, the weak-pointer logic can probably be tuned to reduce overheads, at the cost of increased coupling between MemberName and the JVM. But the coupling is reasonable; we need something like that, and jlr.Method is way too heavy. ? John From bengt.rutisson at oracle.com Sun Mar 6 21:09:34 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Sun, 6 Mar 2016 22:09:34 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D9C7C1.6030601@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> <56D9628B.3040306@oracle.com> <56D97966.2060007@oracle.com> <56D9C7C1.6030601@oracle.com> Message-ID: <56DC9C8E.70909@oracle.com> On 2016-03-04 18:37, Max Ockner wrote: > We have tried to preserve some of the output exactly (or very close > to) the way it was. Some of the corresponding tags produce a ton of > output. In the case of classresolve, you can not shrink the output > anymore without changing its meaning, since there is no redundant > info. I can't think of a good way to split the output across multiple > levels since all of the output seems equally verbose and equally > useful. It originally seemed like the output from ConstantPool might > be the most verbose, and would therefore deserve to live at the Debug > level, but it only seemed that way because of a subtle flaw in the > existing logging which exploded the output by a factor of 4. So I > don't think it would be appropriate to split the output for > classresolve over several levels. I don't know this logging in detail, but I think it makes sense to change the output if it makes the logging more useful. I don't see a need for us to preserve the exact same log output if another format would be better. So much is changing anyway with the new logging framework that this is a good opportunity to improve the logging. > > Would you rather see ~1300 unique logging messages for classresolve on > the Info level or on the Debug level? With that much logging my guess is that I would prefer it on trace level. > > As a side thought, I wonder if Xlog: should default to the most > course level which produces output for the specified tag. That sounds very strange to me. > > That way, setting the classresolve output to Debug level would be OK. > Logging "-Xlog:all" could avoid printing 1300 lines for the > "classresolve" tag, and "-Xlog:classresolve" would display the output > for the classresolve tag even though it is debug level. Just a thought. But if you put the 1300 lines at debug level (or trace) we already don't print them if you do -Xlog:all. Thanks, Bengt > > Thanks, > Max > > On 3/4/2016 7:02 AM, Bengt Rutisson wrote: >> >> >> On 2016-03-04 11:25, David Holmes wrote: >>> On 4/03/2016 7:47 PM, Bengt Rutisson wrote: >>>> >>>> >>>> On 2016-03-04 03:54, David Holmes wrote: >>>>> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Max and Mikael, >>>>>> >>>>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this small fix which attempts to shorten the >>>>>>>> output from >>>>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>>>> >>>>>>>> Summary: java '-Xlog:classresolve=info -version' used to >>>>>>>> produce 3,683 >>>>>>>> lines of output. This is unacceptably verbose for info level >>>>>>>> logging and >>>>>>>> most of the output is not useful. >>>>>>>> >>>>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>>>> - 3,683 total lines of output. >>>>>>>> - 3,121 total lines of output from >>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>> - 1,329 unique lines of output. >>>>>>>> - 767 unique lines of output from >>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>> - 562 total lines of output from all other sources, all >>>>>>>> unique. >>>>>>>> >>>>>>>> The code in ConstantPool which called >>>>>>>> ConstantPool::trace_class_resolution() was doing approximately >>>>>>>> this: >>>>>>>> >>>>>>>> if (log_is_enabled(Info,classresolve)){ >>>>>>>> trace_class_resolution(...)} >>>>>>>> else { resolve the class } >>>>>>>> >>>>>>>> So if logging was turned on, the class would not be resolved >>>>>>>> properly, >>>>>>>> but it would produce a log entry saying that the class was being >>>>>>>> resolved. As a result, the constant pool entry would still >>>>>>>> contain a >>>>>>>> Symbol* the next time this piece of code was reached, and it would >>>>>>>> produce yet another classresolve log entry. In some cases, >>>>>>>> this was >>>>>>>> producing many consecutive identical log entries, taking up >>>>>>>> full pages >>>>>>>> at worst, and averaging a little over 4 duplicates per message. >>>>>>>> Not >>>>>>>> cool. >>>>>>>> >>>>>>>> The above duplication issue has been fixed, and the >>>>>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>>>>> debug >>>>>>>> leve. There are still 562 unique lines of output for "java >>>>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>>>> unique >>>>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>>>> -version" . >>>>>>>> This is better than before but still quite a lot. It seems like >>>>>>>> all of >>>>>>>> the info level output is equally important(or unimportant), as >>>>>>>> you can >>>>>>>> see in the sample below: >>>>>>>> >>>>>>>> [0.026s][info][classresolve] java.lang.reflect.Type >>>>>>>> java.lang.Object >>>>>>>> (super) >>>>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>>>> (super) >>>>>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>>>>> (interface) >>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>> java.lang.reflect.Type >>>>>>>> (interface) >>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>>>>> (super) >>>>>>>> [0.027s][info][classresolve] java.lang.ClassLoader >>>>>>>> java.lang.Object >>>>>>>> (super) >>>>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>>>> (super) >>>>>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>>>>> (super) >>>>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>>>> java.io.Serializable >>>>>>>> (interface) >>>>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>>>> (super) >>>>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>>>>> (super) >>>>>>>> >>>>>>>> How do you feel about this? Possible solutions include setting all >>>>>>>> output to debug level, or removing some of the logging messages. >>>>>>> >>>>>>> As I stated in the bug my personal opinion is that "info" level >>>>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>>>> useful >>>>>>> flag to get a reasonable amount of output about what is >>>>>>> happening in a >>>>>>> JVM. >>>>>>> >>>>>>> One approach could be to move the most verbose output to >>>>>>> classresolve=trace and keep the rest of classresolve output on the >>>>>>> debug level. >>>>>>> >>>>>>> The fact that the flag was called "TraceClassResolution" is in >>>>>>> my mind >>>>>>> a hint that if it produces large amounts of output then perhaps >>>>>>> that >>>>>>> output should be logged on the "trace" log level. >>>>>> >>>>>> +1 for this approach. >>>>> >>>>> As I wrote in the bug report there are philosophically quite >>>>> different >>>>> ways to view the the three logging levels - and this has been >>>>> discussed before. I view "info", "debug" and "trace" as three levels >>>>> of logging applicable to any chosen tag. Others view them as some >>>>> global indicator of priority/importance such that some "less >>>>> important" tags will never use "info" because their output is not >>>>> considered worthy - only in this world is "-Xlog:all" considered >>>>> useful. >>>>> >>>>> If I say -Xlog:foo I expect to see some logging for foo. >>>> >>>> But even if you look at it as that the levels only are applicable >>>> for a >>>> particular tag, why would you want "info" on that tag to produce >>>> extreme >>>> amounts of data? I would expect -Xlog:foo to give me reasonable high >>>> level info about foo. If I want more details I would use >>>> -Xlog:foo=debug. >>> >>> It all depends on what you are logging. If it is a high frequency >>> event then you will get a lot of data even at info levels. >> >> But that's my point. If it is a high frequency event you probably >> don't want to log every event at the info level. That will be useless >> information. What you probably want to do is aggregate and log useful >> information less frequently. Then if someone needs to dig into the >> detail they would enable more logging at debug or trace level to see >> every individual event. >> >> Bengt >> >>> >>> David >>> ----- >>> >>>> And if "info" for each individual tag logs a sensible amount of data, >>>> then -Xlog:all will work pretty well for most cases. >>>> >>>> Bengt >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> I quite agree with Mikael that we should be a bit careful what we >>>>>> log at >>>>>> info level. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>>>>> modified to check for the new output. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>> >>>> >> > From david.holmes at oracle.com Mon Mar 7 00:10:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2016 10:10:26 +1000 Subject: RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times In-Reply-To: References: Message-ID: <56DCC6F2.9060605@oracle.com> On 3/03/2016 10:01 PM, Thomas St?fe wrote: > Hi all, > > I still need a second reviewer and a sponsor for this small Windows-only > fix. I'm applying the trivial change rule here and have sponsored it. Cheers, David > > bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 > Current webrev is: > http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/ > > Thank you! > > ..Thomas > > On Mon, Feb 29, 2016 at 6:14 PM, Thomas St?fe > wrote: > >> Hi all, >> >> please review and sponsor this small fix. >> >> It fixes an error in os::getTimesSecs() for windows which causes the >> numbers for kernel- and usertime to be off. This does not cause an error, >> because the sole user of this function, the TraceCpuTime class, uses this >> function to measure twice and calculate the deltas. >> >> I still think it is a good idea to fix this bug - with the fix, the >> returned values are based on the process start and will be the same for all >> platforms (the *nix platforms use times()). >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8150843 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/ >> >> Kind Regards, Thomas >> From david.holmes at oracle.com Mon Mar 7 00:22:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2016 10:22:16 +1000 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56DC9C8E.70909@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> <56D9628B.3040306@oracle.com> <56D97966.2060007@oracle.com> <56D9C7C1.6030601@oracle.com> <56DC9C8E.70909@oracle.com> Message-ID: <56DCC9B8.3020406@oracle.com> On 7/03/2016 7:09 AM, Bengt Rutisson wrote: > On 2016-03-04 18:37, Max Ockner wrote: >> We have tried to preserve some of the output exactly (or very close >> to) the way it was. Some of the corresponding tags produce a ton of >> output. In the case of classresolve, you can not shrink the output >> anymore without changing its meaning, since there is no redundant >> info. I can't think of a good way to split the output across multiple >> levels since all of the output seems equally verbose and equally >> useful. It originally seemed like the output from ConstantPool might >> be the most verbose, and would therefore deserve to live at the Debug >> level, but it only seemed that way because of a subtle flaw in the >> existing logging which exploded the output by a factor of 4. So I >> don't think it would be appropriate to split the output for >> classresolve over several levels. > > I don't know this logging in detail, but I think it makes sense to > change the output if it makes the logging more useful. I don't see a > need for us to preserve the exact same log output if another format > would be better. So much is changing anyway with the new logging > framework that this is a good opportunity to improve the logging. > >> >> Would you rather see ~1300 unique logging messages for classresolve on >> the Info level or on the Debug level? > > With that much logging my guess is that I would prefer it on trace level. But that leaves no further room for expansion with more detail. I may want to see the full 1300 messages when I enable -Xlog::classresolve, but not the 3900 messages that would be produced with the most verbose logging. >> >> As a side thought, I wonder if Xlog: should default to the most >> course level which produces output for the specified tag. > > That sounds very strange to me. It sounds good to me: turn on the first level of logging that exists for the given tag. But I'm unclear if this is readily detectable. >> >> That way, setting the classresolve output to Debug level would be OK. >> Logging "-Xlog:all" could avoid printing 1300 lines for the >> "classresolve" tag, and "-Xlog:classresolve" would display the output >> for the classresolve tag even though it is debug level. Just a thought. > > But if you put the 1300 lines at debug level (or trace) we already don't > print them if you do -Xlog:all. Yes but we would like to see them when we use -Xlog:classresolve - whether they are info or debug. If you force these to be debug or lower then we're asking for a way to make debug (or lower) become the default. But I still advocate using "info" for this. Cheers, David > Thanks, > Bengt > >> >> Thanks, >> Max >> >> On 3/4/2016 7:02 AM, Bengt Rutisson wrote: >>> >>> >>> On 2016-03-04 11:25, David Holmes wrote: >>>> On 4/03/2016 7:47 PM, Bengt Rutisson wrote: >>>>> >>>>> >>>>> On 2016-03-04 03:54, David Holmes wrote: >>>>>> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Max and Mikael, >>>>>>> >>>>>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review this small fix which attempts to shorten the >>>>>>>>> output from >>>>>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>>>>> >>>>>>>>> Summary: java '-Xlog:classresolve=info -version' used to >>>>>>>>> produce 3,683 >>>>>>>>> lines of output. This is unacceptably verbose for info level >>>>>>>>> logging and >>>>>>>>> most of the output is not useful. >>>>>>>>> >>>>>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>>>>> - 3,683 total lines of output. >>>>>>>>> - 3,121 total lines of output from >>>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>>> - 1,329 unique lines of output. >>>>>>>>> - 767 unique lines of output from >>>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>>> - 562 total lines of output from all other sources, all >>>>>>>>> unique. >>>>>>>>> >>>>>>>>> The code in ConstantPool which called >>>>>>>>> ConstantPool::trace_class_resolution() was doing approximately >>>>>>>>> this: >>>>>>>>> >>>>>>>>> if (log_is_enabled(Info,classresolve)){ >>>>>>>>> trace_class_resolution(...)} >>>>>>>>> else { resolve the class } >>>>>>>>> >>>>>>>>> So if logging was turned on, the class would not be resolved >>>>>>>>> properly, >>>>>>>>> but it would produce a log entry saying that the class was being >>>>>>>>> resolved. As a result, the constant pool entry would still >>>>>>>>> contain a >>>>>>>>> Symbol* the next time this piece of code was reached, and it would >>>>>>>>> produce yet another classresolve log entry. In some cases, >>>>>>>>> this was >>>>>>>>> producing many consecutive identical log entries, taking up >>>>>>>>> full pages >>>>>>>>> at worst, and averaging a little over 4 duplicates per message. >>>>>>>>> Not >>>>>>>>> cool. >>>>>>>>> >>>>>>>>> The above duplication issue has been fixed, and the >>>>>>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>>>>>> debug >>>>>>>>> leve. There are still 562 unique lines of output for "java >>>>>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>>>>> unique >>>>>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>>>>> -version" . >>>>>>>>> This is better than before but still quite a lot. It seems like >>>>>>>>> all of >>>>>>>>> the info level output is equally important(or unimportant), as >>>>>>>>> you can >>>>>>>>> see in the sample below: >>>>>>>>> >>>>>>>>> [0.026s][info][classresolve] java.lang.reflect.Type >>>>>>>>> java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>>>>>> (interface) >>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>> java.lang.reflect.Type >>>>>>>>> (interface) >>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.027s][info][classresolve] java.lang.ClassLoader >>>>>>>>> java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>>>>>> (super) >>>>>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>>>>> java.io.Serializable >>>>>>>>> (interface) >>>>>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>>>>> (super) >>>>>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>>>>>> (super) >>>>>>>>> >>>>>>>>> How do you feel about this? Possible solutions include setting all >>>>>>>>> output to debug level, or removing some of the logging messages. >>>>>>>> >>>>>>>> As I stated in the bug my personal opinion is that "info" level >>>>>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>>>>> useful >>>>>>>> flag to get a reasonable amount of output about what is >>>>>>>> happening in a >>>>>>>> JVM. >>>>>>>> >>>>>>>> One approach could be to move the most verbose output to >>>>>>>> classresolve=trace and keep the rest of classresolve output on the >>>>>>>> debug level. >>>>>>>> >>>>>>>> The fact that the flag was called "TraceClassResolution" is in >>>>>>>> my mind >>>>>>>> a hint that if it produces large amounts of output then perhaps >>>>>>>> that >>>>>>>> output should be logged on the "trace" log level. >>>>>>> >>>>>>> +1 for this approach. >>>>>> >>>>>> As I wrote in the bug report there are philosophically quite >>>>>> different >>>>>> ways to view the the three logging levels - and this has been >>>>>> discussed before. I view "info", "debug" and "trace" as three levels >>>>>> of logging applicable to any chosen tag. Others view them as some >>>>>> global indicator of priority/importance such that some "less >>>>>> important" tags will never use "info" because their output is not >>>>>> considered worthy - only in this world is "-Xlog:all" considered >>>>>> useful. >>>>>> >>>>>> If I say -Xlog:foo I expect to see some logging for foo. >>>>> >>>>> But even if you look at it as that the levels only are applicable >>>>> for a >>>>> particular tag, why would you want "info" on that tag to produce >>>>> extreme >>>>> amounts of data? I would expect -Xlog:foo to give me reasonable high >>>>> level info about foo. If I want more details I would use >>>>> -Xlog:foo=debug. >>>> >>>> It all depends on what you are logging. If it is a high frequency >>>> event then you will get a lot of data even at info levels. >>> >>> But that's my point. If it is a high frequency event you probably >>> don't want to log every event at the info level. That will be useless >>> information. What you probably want to do is aggregate and log useful >>> information less frequently. Then if someone needs to dig into the >>> detail they would enable more logging at debug or trace level to see >>> every individual event. >>> >>> Bengt >>> >>>> >>>> David >>>> ----- >>>> >>>>> And if "info" for each individual tag logs a sensible amount of data, >>>>> then -Xlog:all will work pretty well for most cases. >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> I quite agree with Mikael that we should be a bit careful what we >>>>>>> log at >>>>>>> info level. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>>>>>> modified to check for the new output. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From david.holmes at oracle.com Mon Mar 7 00:32:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2016 10:32:39 +1000 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56D9EE75.5020109@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> Message-ID: <56DCCC27.9030207@oracle.com> Looks good Rachel! Thanks, David On 5/03/2016 6:22 AM, Rachel Protacio wrote: > Hi Dmitry, > > Thanks for the review! I've fixed the test as requested :) > > New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ > > Rachel > > On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >> Hi Rachel, >> >> Overall looks good. Few test comments: >> 1) Import of WeakReference seems unneeded. >> 2) For "-Xlog:safepointcleanup=off" test case you have >> "output.shouldNotContain("[safepointcleanup]");". Is it make sense to >> add "output.shouldContain("[safepointcleanup]")" for case when log is >> enabled? >> 3) I think you should add test case for aliased option. >> >> Thank you, >> Dmitry >> >> On 03.03.2016 23:35, Rachel Protacio wrote: >>> Hello! >>> >>> Coming close to the end of the logging conversions for now! Here's >>> one for TraceSafepointCleanupTime, which is turning into >>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>> aliased in this change. >>> >>> To reiterate the conclusion from the TraceStartupTime conversion, I >>> ask that as long as there are no objections to the correctness of the >>> code, we allow this implementation for now, and I will then file a >>> follow-up bug for possible improvements to the switch statement and >>> TraceTime function signature situation. Since this is the only other >>> "TraceTime" conversion, TraceTime implementation changes will be more >>> succinctly addressable after this SafepointCleanupTime change than >>> before it. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>> >>> Sample old output: >>> >>> $ java -XX:+TraceSafepointCleanupTime -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>> [deflating idle monitors, 0.0000088 secs] >>> [updating inline caches, 0.0000007 secs] >>> [compilation policy safepoint handler, 0.0000009 secs] >>> [mark nmethods, 0.0000164 secs] >>> [purging class loader data graph, 0.0000002 secs] >>> >>> Sample new output: >>> >>> $ java -Xlog:safepointcleanup -version >>> java version "9-internal" >>> Java(TM) SE Runtime Environment (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>> [0.348s][info][safepointcleanup] deflating idle monitors, >>> 0.0000059 secs >>> [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 >>> secs >>> [0.348s][info][safepointcleanup] compilation policy safepoint >>> handler, 0.0000006 secs >>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>> [0.348s][info][safepointcleanup] purging class loader data graph, >>> 0.0000001 secs >>> >>> >>> Tested using JPRT and RBT hotspot and non-colo tests. >>> >>> Thanks! >>> Rachel >>> >>> >> > From david.holmes at oracle.com Mon Mar 7 01:02:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2016 11:02:01 +1000 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DA0155.7090507@oracle.com> References: <56DA0155.7090507@oracle.com> Message-ID: <56DCD309.1070505@oracle.com> Hi Rachel, A few comments ... On 5/03/2016 7:42 AM, Rachel Protacio wrote: > Hello, > > Please review this conversion of -XX:+VerboseVerification to > -Xlog:verboseverification=info. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ if (log_is_enabled(Info, classinit)){ 194 log_end_verification(LogHandle(classinit)::info_stream(), klassName, exception_name, THREAD); 195 } 196 if (log_is_enabled(Info, verboseverification)){ 197 ResourceMark rm; 198 log_end_verification(LogHandle(verboseverification)::info_stream(), klassName, exception_name, THREAD); 199 } No ResourceMark needed at #197 (for same reason it is not needed at #194). --- 603 if (was_recursively_verified()){ 604 log_info(verboseverification)("Recursive verification detected for: %s", _klass->external_name()); 605 log_info(classinit)("Recursive verification detected for: %s", 606 _klass->external_name()); 607 } When TraceclassInitialization was converted it was suggested that where we had: if (TraceClassInitialization || VerboseVerification) { // log something .... and we then got the output printed twice with classinit using UL, that these would be fixed up when VerboseVerification was converted: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016846.html "When VerboseVerification is converted to UL, the logging statements will be more compact." --- test/runtime/logging/ClassInitializationTest.java I think the "Ensure that VerboseVerification still triggers appropriate messages" subtest can be deleted now as we test -Xlog:verboseverification separately. It was only present to ensure the old VerboseVerification flag still functioned after the classinit change. --- Thanks, David ----- > Sample old output: > > Verifying class hello with new format > Verifying method hello.()V > StackMapTable: frame_count = 0 > table = { > } > bci: @0 > flags: { flagThisUninit } > locals: { uninitializedThis } > stack: { } > offset = 0, opcode = aload_0 > bci: @1 > flags: { flagThisUninit } > locals: { uninitializedThis } > stack: { uninitializedThis } > offset = 1, opcode = invokespecial > bci: @4 > flags: { } > locals: { 'hello' } > stack: { } > offset = 4, opcode = return > Verifying method hello.main([Ljava/lang/String;)V > > Sample new output: > > [0.696s][info][verboseverification] Verifying class > VerboseVerificationTest$InternalClass with new format > [0.696s][info][verboseverification] Verifying method > VerboseVerificationTest$InternalClass.()V > [0.696s][info][verboseverification] StackMapTable: frame_count = 0 > [0.696s][info][verboseverification] table = { > [0.696s][info][verboseverification] } > [0.696s][info][verboseverification] bci: @0 > [0.696s][info][verboseverification] flags: { flagThisUninit } > [0.696s][info][verboseverification] locals: { uninitializedThis } > [0.696s][info][verboseverification] stack: { } > [0.696s][info][verboseverification] offset = 0, opcode = aload_0 > [0.696s][info][verboseverification] bci: @1 > [0.696s][info][verboseverification] flags: { flagThisUninit } > [0.696s][info][verboseverification] locals: { uninitializedThis } > [0.696s][info][verboseverification] stack: { uninitializedThis } > [0.696s][info][verboseverification] offset = 1, opcode = invokespecial > [0.696s][info][verboseverification] bci: @4 > [0.696s][info][verboseverification] flags: { } > [0.696s][info][verboseverification] locals: { > 'VerboseVerificationTest$InternalClass' } > [0.696s][info][verboseverification] stack: { } > [0.696s][info][verboseverification] offset = 4, opcode = return > [0.696s][info][verboseverification] Verifying method > VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V > > Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and > non-colo tests. > > Thank you, > Rachel From goetz.lindenmaier at sap.com Mon Mar 7 07:50:14 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Mar 2016 07:50:14 +0000 Subject: RFR(S): 8149557: Resource mark breaks printing to string stream In-Reply-To: <56D94D62.1020204@oracle.com> References: <26852801ffaa4671a95ee2e1b0077e57@DEWDFE13DE09.global.corp.sap> <56CA5C7C.5040606@oracle.com> <56D51A90.7030508@oracle.com> <9eb5886ef95d4b58a56ae99da710d789@DEWDFE13DE09.global.corp.sap> <56D94D62.1020204@oracle.com> Message-ID: Hi David, thanks for sponsorig! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 4. M?rz 2016 09:55 > To: Lindenmaier, Goetz ; 'Thomas St?fe' > > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string stream > > Hi Goetz, > > I can sponsor, unless someone else grabs it first - my weekend has > already started so I won't get to it for a couple of days. :) > > David > > On 4/03/2016 6:37 PM, Lindenmaier, Goetz wrote: > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Tuesday, March 01, 2016 5:29 AM > >> To: Lindenmaier, Goetz ; 'Thomas St?fe' > >> > >> Cc: hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string > stream > >> > >> Hi Goetz, > >> > >> On 29/02/2016 11:09 PM, Lindenmaier, Goetz wrote: > >>> Hi David, Thomas, > >>> > >>> you are right, I need to check for NULL. I had the linux > >>> case in mind. > >>> New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8149557-ResMrk/webrev.02/ > >> > >> I can't help but feel there is a bug in the Resource-area memory > >> management code here. The problem as I understand it is that we have: > >> > >> void Symbol::print_symbol_on(outputStream* st) const { > >> ResourceMark rm; > >> st = st ? st : tty; > >> st->print("%s", as_quoted_ascii()); > >> } > >> > >> where we need the ResourceMark for the string returned by > >> as_quoted_ascii. But if st is itself a resource-area object and needs to > >> re-size in st->print then it does that in the context of the new > >> ResourceMark, which fails the assert: "stringStream is re-allocated with > >> a different ResourceMark." That seems to be the bug to me - a > >> resource-area object that needs resizing should be able to do it in the > >> context of an outer ResourceMark. :( > >> > >> So the workaround is to use a separate ResourceMark to call > >> as_quoted_ascii and then copy the result to a malloc'd string, which is > >> used for the st->print (which may realloc in the context of the existing > >> outer ResourceMark) and is then free()'d. Yuck. :( > > Yes, this exactly describes the situation. I wouldn't call it a bug in the > Resource-area memory > > management, but an unpleasant implementation detail of stringStream, > that > > makes it behave differently from its related classes. > > > >> > >> Reluctantly Reviewed. > > Thanks! > > > > Would you mind sponsoring? > > > > Best regards, > > Goetz. > > > > > >> > >> Thanks, > >> David > >> > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Montag, 22. Februar 2016 01:55 > >>>> To: Lindenmaier, Goetz ; 'Thomas St?fe' > >>>> > >>>> Cc: hotspot-runtime-dev at openjdk.java.net > >>>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string > >> stream > >>>> > >>>> On 19/02/2016 11:05 PM, Lindenmaier, Goetz wrote: > >>>>> Hi Thomas, > >>>>> > >>>>> thanks for looking at this. > >>>>> > >>>>>> you should check the return value of os::strdup(). > >>>>> strdup returns null on oom, %s should be ?null?, and > >>>> > >>>> What are you assuming takes care of %s to 'null' conversion? gcc printf > >>>> may do it but AFAIK it is undefined at the C library level. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> free handles null properly, too. So I think this is fine. > >>>>> > >>>>> If I remove the RM, I might break callers. E.g. > >>>> TestLogTouchedMethods.java. > >>>>> Also, in that test, all logged method names will accumulate in > memory. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>>>> Sent: Thursday, February 11, 2016 9:41 AM > >>>>> To: Lindenmaier, Goetz > >>>>> Cc: hotspot-runtime-dev at openjdk.java.net > >>>>> Subject: Re: RFR(S): 8149557: Resource mark breaks printing to string > >>>> stream > >>>>> > >>>>> Hi Goetz, > >>>>> > >>>>> Thank you for fixing this. I see you are restless :-) > >>>>> > >>>>> you should check the return value of os::strdup(). The change looks > fine > >>>> otherwise, though I wonder whether we could just omit the > >> ResourceMark > >>>> and using the one of the caller. At least it is inconsistent, because > >>>> Symbol::print_utf8_on() does not have a ResourceMark either. > >>>>> > >>>>> Kind regards, Thomas > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Feb 11, 2016 at 9:24 AM, Lindenmaier, Goetz > >>>> > > >> wrote: > >>>>> Hi > >>>>> > >>>>> Please review this change. I please need a sponsor. > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8149557- > ResMrk/webrev.01/ > >>>>> > >>>>> If a stringStream is passed to Symbol::print_symbol_on(), > >>>>> assertion "stringStream is re-allocated with a different > ResourceMark." > >> can > >>>> fire in stringStream::write(const char* s, size_t len). > >>>>> This can be verified by running TestLogTouchedMethods.java after > >> adding > >>>> the patch below to the VM. > >>>>> > >>>>> My fix copies the string to locally managed memory before popping > the > >>>> ResoreceMark. > >>>>> A better solution would be to guarantee enough space on the stream > >>>>> before doing the resource mark, but outputStream has no such > >>>>> method as 'ensureCapacity' or the like. > >>>>> Alternatively the ResourceMark could be skipped altogether. > >>>>> But then the aux memory used remains on the ResourceArea too > long. > >>>>> Also, various ResourceMarks have to be added in other places. > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> --- a/src/share/vm/runtime/java.cpp Wed Jan 13 11:33:21 2016 > +0100 > >>>>> +++ b/src/share/vm/runtime/java.cpp Wed Feb 10 08:56:14 2016 > >> +0100 > >>>>> @@ -340,7 +340,10 @@ > >>>>> } > >>>>> > >>>>> if (LogTouchedMethods && PrintTouchedMethodsAtExit) { > >>>>> - Method::print_touched_methods(tty); > >>>>> + ResourceMark rm; > >>>>> + stringStream st(16); > >>>>> + Method::print_touched_methods(&st); > >>>>> + tty->print("%s", st.as_string()); > >>>>> } > >>>>> > >>>>> if (PrintBiasedLockingStatistics) { > >>>>> From bengt.rutisson at oracle.com Mon Mar 7 08:26:28 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 7 Mar 2016 09:26:28 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56DCC9B8.3020406@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D8F8F6.2030403@oracle.com> <56D959BD.1050601@oracle.com> <56D9628B.3040306@oracle.com> <56D97966.2060007@oracle.com> <56D9C7C1.6030601@oracle.com> <56DC9C8E.70909@oracle.com> <56DCC9B8.3020406@oracle.com> Message-ID: <56DD3B34.7050101@oracle.com> Hi again, On 2016-03-07 01:22, David Holmes wrote: > On 7/03/2016 7:09 AM, Bengt Rutisson wrote: >> On 2016-03-04 18:37, Max Ockner wrote: >>> We have tried to preserve some of the output exactly (or very close >>> to) the way it was. Some of the corresponding tags produce a ton of >>> output. In the case of classresolve, you can not shrink the output >>> anymore without changing its meaning, since there is no redundant >>> info. I can't think of a good way to split the output across multiple >>> levels since all of the output seems equally verbose and equally >>> useful. It originally seemed like the output from ConstantPool might >>> be the most verbose, and would therefore deserve to live at the Debug >>> level, but it only seemed that way because of a subtle flaw in the >>> existing logging which exploded the output by a factor of 4. So I >>> don't think it would be appropriate to split the output for >>> classresolve over several levels. >> >> I don't know this logging in detail, but I think it makes sense to >> change the output if it makes the logging more useful. I don't see a >> need for us to preserve the exact same log output if another format >> would be better. So much is changing anyway with the new logging >> framework that this is a good opportunity to improve the logging. >> >>> >>> Would you rather see ~1300 unique logging messages for classresolve on >>> the Info level or on the Debug level? >> >> With that much logging my guess is that I would prefer it on trace >> level. > > But that leaves no further room for expansion with more detail. I may > want to see the full 1300 messages when I enable -Xlog::classresolve, > but not the 3900 messages that would be produced with the most verbose > logging. Again, I don't know enough about this particular logging to be sure how to best design it, but there is also the possibility to use more tags. I'm actually a bit surprised that there is a "classresolve" tag instead of two tags "class, resolve". I would think that it would be interesting to do -Xlog:class and get relevant information about all parts of class loding, resolving and unloading etc. I also didn't know about the 3900 messages, but if you really want to keep this design, what is the problem with having the 1300 messages at debug level and the 3900 messages at trace level? > >>> >>> As a side thought, I wonder if Xlog: should default to the most >>> course level which produces output for the specified tag. >> >> That sounds very strange to me. > > It sounds good to me: turn on the first level of logging that exists > for the given tag. But I'm unclear if this is readily detectable. I think this will be very confusing to the users. I would be very surprised to get different level logging for different tags with the same configuration. > >>> >>> That way, setting the classresolve output to Debug level would be OK. >>> Logging "-Xlog:all" could avoid printing 1300 lines for the >>> "classresolve" tag, and "-Xlog:classresolve" would display the output >>> for the classresolve tag even though it is debug level. Just a thought. >> >> But if you put the 1300 lines at debug level (or trace) we already don't >> print them if you do -Xlog:all. > > Yes but we would like to see them when we use -Xlog:classresolve - > whether they are info or debug. If you force these to be debug or > lower then we're asking for a way to make debug (or lower) become the > default. Why do you want so much logging when you do -Xlog:classresolve? The amount of logging really does not sound like anything you want as normal information but as something you want when you need to dig in to some details. Which is exactly when you want to use debug level logging. It seems very natural to me to do -Xlog:classresolve=debug to get these details. Or even better -Xlog:class+resolve=debug. Bengt > > But I still advocate using "info" for this. > > Cheers, > David > >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Max >>> >>> On 3/4/2016 7:02 AM, Bengt Rutisson wrote: >>>> >>>> >>>> On 2016-03-04 11:25, David Holmes wrote: >>>>> On 4/03/2016 7:47 PM, Bengt Rutisson wrote: >>>>>> >>>>>> >>>>>> On 2016-03-04 03:54, David Holmes wrote: >>>>>>> On 3/03/2016 7:45 PM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Max and Mikael, >>>>>>>> >>>>>>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review this small fix which attempts to shorten the >>>>>>>>>> output from >>>>>>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>>>>>> >>>>>>>>>> Summary: java '-Xlog:classresolve=info -version' used to >>>>>>>>>> produce 3,683 >>>>>>>>>> lines of output. This is unacceptably verbose for info level >>>>>>>>>> logging and >>>>>>>>>> most of the output is not useful. >>>>>>>>>> >>>>>>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>>>>>> - 3,683 total lines of output. >>>>>>>>>> - 3,121 total lines of output from >>>>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>>>> - 1,329 unique lines of output. >>>>>>>>>> - 767 unique lines of output from >>>>>>>>>> ConstantPool::trace_class_resolution(). >>>>>>>>>> - 562 total lines of output from all other sources, all >>>>>>>>>> unique. >>>>>>>>>> >>>>>>>>>> The code in ConstantPool which called >>>>>>>>>> ConstantPool::trace_class_resolution() was doing approximately >>>>>>>>>> this: >>>>>>>>>> >>>>>>>>>> if (log_is_enabled(Info,classresolve)){ >>>>>>>>>> trace_class_resolution(...)} >>>>>>>>>> else { resolve the class } >>>>>>>>>> >>>>>>>>>> So if logging was turned on, the class would not be resolved >>>>>>>>>> properly, >>>>>>>>>> but it would produce a log entry saying that the class was being >>>>>>>>>> resolved. As a result, the constant pool entry would still >>>>>>>>>> contain a >>>>>>>>>> Symbol* the next time this piece of code was reached, and it >>>>>>>>>> would >>>>>>>>>> produce yet another classresolve log entry. In some cases, >>>>>>>>>> this was >>>>>>>>>> producing many consecutive identical log entries, taking up >>>>>>>>>> full pages >>>>>>>>>> at worst, and averaging a little over 4 duplicates per message. >>>>>>>>>> Not >>>>>>>>>> cool. >>>>>>>>>> >>>>>>>>>> The above duplication issue has been fixed, and the >>>>>>>>>> ConstantPool::trace_class_resolution output has been moved to >>>>>>>>>> the >>>>>>>>>> debug >>>>>>>>>> leve. There are still 562 unique lines of output for "java >>>>>>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>>>>>> unique >>>>>>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>>>>>> -version" . >>>>>>>>>> This is better than before but still quite a lot. It seems like >>>>>>>>>> all of >>>>>>>>>> the info level output is equally important(or unimportant), as >>>>>>>>>> you can >>>>>>>>>> see in the sample below: >>>>>>>>>> >>>>>>>>>> [0.026s][info][classresolve] java.lang.reflect.Type >>>>>>>>>> java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>>> java.io.Serializable >>>>>>>>>> (interface) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>>> java.lang.reflect.Type >>>>>>>>>> (interface) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>>>>>> [0.026s][info][classresolve] java.lang.Cloneable >>>>>>>>>> java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.027s][info][classresolve] java.lang.ClassLoader >>>>>>>>>> java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>>>>>> java.lang.Object >>>>>>>>>> (super) >>>>>>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>>>>>> java.io.Serializable >>>>>>>>>> (interface) >>>>>>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>>>>>> (super) >>>>>>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath >>>>>>>>>> java.lang.Error >>>>>>>>>> (super) >>>>>>>>>> >>>>>>>>>> How do you feel about this? Possible solutions include >>>>>>>>>> setting all >>>>>>>>>> output to debug level, or removing some of the logging messages. >>>>>>>>> >>>>>>>>> As I stated in the bug my personal opinion is that "info" level >>>>>>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>>>>>> useful >>>>>>>>> flag to get a reasonable amount of output about what is >>>>>>>>> happening in a >>>>>>>>> JVM. >>>>>>>>> >>>>>>>>> One approach could be to move the most verbose output to >>>>>>>>> classresolve=trace and keep the rest of classresolve output on >>>>>>>>> the >>>>>>>>> debug level. >>>>>>>>> >>>>>>>>> The fact that the flag was called "TraceClassResolution" is in >>>>>>>>> my mind >>>>>>>>> a hint that if it produces large amounts of output then perhaps >>>>>>>>> that >>>>>>>>> output should be logged on the "trace" log level. >>>>>>>> >>>>>>>> +1 for this approach. >>>>>>> >>>>>>> As I wrote in the bug report there are philosophically quite >>>>>>> different >>>>>>> ways to view the the three logging levels - and this has been >>>>>>> discussed before. I view "info", "debug" and "trace" as three >>>>>>> levels >>>>>>> of logging applicable to any chosen tag. Others view them as some >>>>>>> global indicator of priority/importance such that some "less >>>>>>> important" tags will never use "info" because their output is not >>>>>>> considered worthy - only in this world is "-Xlog:all" considered >>>>>>> useful. >>>>>>> >>>>>>> If I say -Xlog:foo I expect to see some logging for foo. >>>>>> >>>>>> But even if you look at it as that the levels only are applicable >>>>>> for a >>>>>> particular tag, why would you want "info" on that tag to produce >>>>>> extreme >>>>>> amounts of data? I would expect -Xlog:foo to give me reasonable high >>>>>> level info about foo. If I want more details I would use >>>>>> -Xlog:foo=debug. >>>>> >>>>> It all depends on what you are logging. If it is a high frequency >>>>> event then you will get a lot of data even at info levels. >>>> >>>> But that's my point. If it is a high frequency event you probably >>>> don't want to log every event at the info level. That will be useless >>>> information. What you probably want to do is aggregate and log useful >>>> information less frequently. Then if someone needs to dig into the >>>> detail they would enable more logging at debug or trace level to see >>>> every individual event. >>>> >>>> Bengt >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> And if "info" for each individual tag logs a sensible amount of >>>>>> data, >>>>>> then -Xlog:all will work pretty well for most cases. >>>>>> >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> I quite agree with Mikael that we should be a bit careful what we >>>>>>>> log at >>>>>>>> info level. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has >>>>>>>>>> been >>>>>>>>>> modified to check for the new output. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> From dmitry.samersoff at oracle.com Mon Mar 7 10:07:52 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 7 Mar 2016 13:07:52 +0300 Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: <2fecd625-4723-4fbe-b148-36f7bb654df6@default> References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> <2fecd625-4723-4fbe-b148-36f7bb654df6@default> Message-ID: <56DD52F8.8070208@oracle.com> Cheleswer, Looks good for me. -Dmitry On 2016-03-03 19:28, Cheleswer Sahu wrote: > Hi, > > Please review the new code changes for this bug. I have removed " fstat()" call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link > Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ > > > Regards, > Cheleswer > > -----Original Message----- > From: Dean Long > Sent: Wednesday, February 24, 2016 7:44 AM > To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient > > On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: >> On 2/23/16 5:56 AM, Thomas St?fe wrote: >>> Hi Cheleswer, >>> >>> >>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>> >>> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> Please review the code changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>> >>>> >>>> >>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>> >>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>> >>>> >>>> >>>> Bug Brief: >>>> >>>> While investigating bug >>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>> it has been observed that "check_addr0() " function is not written >>>> efficiently. >>>> >>>> This function is trying to read each "prmap_t" entry in >>>> "/proc/self/map" >>>> file one by one which is time taking and can cause in long pauses. >>>> >>>> >>>> >>>> Solution proposed: >>>> >>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one >>>> by one, read the entries in chunks. There can be many entries in "map" >>>> file, >>>> so I have decided to read these >>>> >>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>> a lot of read calls and results in smaller pause times. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Cheleswer >>>> >>> >>> We saw cases, especially on Solaris, where the content of a file in the >>> proc file system changed under us while we were reading it. So this >>> should >>> be kept in mind. The original code seems also broken in that regard, >>> because it assumes the ::read() call to read the full size of a prmap_t >>> entry, but it may theoretically read an incomplete entry. >>> >>> As for your coding, you first estimate the size of the mapping file and >>> then use this to determine how many entries to read; but when >>> reading, this >>> information may already be stale. I think it would be more robust and >>> also >>> simpler to just try to read as many entries as possible - in chunks, to >>> make reading faster - until you get EOF. >>> >>> Kind Regards, Thomas >> >> I'm really sure that we've been down this road before. In particular, >> Dmitry Samersoff has worked on this issue (or one very much like it) >> before, but he is on vacation until the end of the month. >> > > There was a similar issue with Linux /proc/self/maps, and whether it was > safe to read the file with buffered stdio or not. See 8009062 and 7017193. > > dl > >> Dan >> >> >>> >>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>> >>> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> Please review the code changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>> >>>> >>>> >>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>> >>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>> >>>> >>>> >>>> Bug Brief: >>>> >>>> While investigating bug >>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>> it has been observed that "check_addr0() " function is not written >>>> efficiently. >>>> >>>> This function is trying to read each "prmap_t" entry in >>>> "/proc/self/map" >>>> file one by one which is time taking and can cause in long pauses. >>>> >>>> >>>> >>>> Solution proposed: >>>> >>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by >>>> one, read the entries in chunks. There can be many entries in "map" >>>> file, >>>> so I have decided to read these >>>> >>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>> a lot >>>> of read calls and results in smaller pause times. >>>> >>>> >>>> >>>> >>>> >>>> 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 kevin.walls at oracle.com Mon Mar 7 10:36:18 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 7 Mar 2016 10:36:18 +0000 Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: <56DD52F8.8070208@oracle.com> References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> <2fecd625-4723-4fbe-b148-36f7bb654df6@default> <56DD52F8.8070208@oracle.com> Message-ID: <56DD59A2.1030804@oracle.com> Hi Cheleswer, Looks good. (While we've discussed it offline I haven't actually offered a public review). Just one more thing, and this concerns the original code not the change: 1880 st->print("Warning: Address: 0x%x, Size: %dK, ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname); We pass 3 params when we only print two items? The "p->pr_mapname", we pass again on the next line where we do have the the "%s" in the format string, so this one is unnecessary. 8-) Thanks Kevin On 07/03/2016 10:07, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me. > > -Dmitry > > > On 2016-03-03 19:28, Cheleswer Sahu wrote: >> Hi, >> >> Please review the new code changes for this bug. I have removed " fstat()" call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link >> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ >> >> >> Regards, >> Cheleswer >> >> -----Original Message----- >> From: Dean Long >> Sent: Wednesday, February 24, 2016 7:44 AM >> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient >> >> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: >>> On 2/23/16 5:56 AM, Thomas St?fe wrote: >>>> Hi Cheleswer, >>>> >>>> >>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Please review the code changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>> >>>>> >>>>> >>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>> >>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>> >>>>> >>>>> >>>>> Bug Brief: >>>>> >>>>> While investigating bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>> it has been observed that "check_addr0() " function is not written >>>>> efficiently. >>>>> >>>>> This function is trying to read each "prmap_t" entry in >>>>> "/proc/self/map" >>>>> file one by one which is time taking and can cause in long pauses. >>>>> >>>>> >>>>> >>>>> Solution proposed: >>>>> >>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one >>>>> by one, read the entries in chunks. There can be many entries in "map" >>>>> file, >>>>> so I have decided to read these >>>>> >>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>> a lot of read calls and results in smaller pause times. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Cheleswer >>>>> >>>> We saw cases, especially on Solaris, where the content of a file in the >>>> proc file system changed under us while we were reading it. So this >>>> should >>>> be kept in mind. The original code seems also broken in that regard, >>>> because it assumes the ::read() call to read the full size of a prmap_t >>>> entry, but it may theoretically read an incomplete entry. >>>> >>>> As for your coding, you first estimate the size of the mapping file and >>>> then use this to determine how many entries to read; but when >>>> reading, this >>>> information may already be stale. I think it would be more robust and >>>> also >>>> simpler to just try to read as many entries as possible - in chunks, to >>>> make reading faster - until you get EOF. >>>> >>>> Kind Regards, Thomas >>> I'm really sure that we've been down this road before. In particular, >>> Dmitry Samersoff has worked on this issue (or one very much like it) >>> before, but he is on vacation until the end of the month. >>> >> There was a similar issue with Linux /proc/self/maps, and whether it was >> safe to read the file with buffered stdio or not. See 8009062 and 7017193. >> >> dl >> >>> Dan >>> >>> >>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Please review the code changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>> >>>>> >>>>> >>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>> >>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>> >>>>> >>>>> >>>>> Bug Brief: >>>>> >>>>> While investigating bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>> it has been observed that "check_addr0() " function is not written >>>>> efficiently. >>>>> >>>>> This function is trying to read each "prmap_t" entry in >>>>> "/proc/self/map" >>>>> file one by one which is time taking and can cause in long pauses. >>>>> >>>>> >>>>> >>>>> Solution proposed: >>>>> >>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by >>>>> one, read the entries in chunks. There can be many entries in "map" >>>>> file, >>>>> so I have decided to read these >>>>> >>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>> a lot >>>>> of read calls and results in smaller pause times. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Cheleswer >>>>> > From david.holmes at oracle.com Mon Mar 7 11:23:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2016 21:23:30 +1000 Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: <56DD59A2.1030804@oracle.com> References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> <2fecd625-4723-4fbe-b148-36f7bb654df6@default> <56DD52F8.8070208@oracle.com> <56DD59A2.1030804@oracle.com> Message-ID: <56DD64B2.4010901@oracle.com> On 7/03/2016 8:36 PM, Kevin Walls wrote: > > Hi Cheleswer, > > Looks good. (While we've discussed it offline I haven't actually > offered a public review). > > Just one more thing, and this concerns the original code not the change: > > 1880 st->print("Warning: Address: 0x%x, Size: %dK, > ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname); Also %x is the wrong format specifier: typedef struct prmap { uintptr_t pr_vaddr; /* virtual address of mapping */ David ----- > We pass 3 params when we only print two items? The "p->pr_mapname", we > pass again on the next line where we do have the the "%s" in the format > string, so this one is unnecessary. 8-) > > Thanks > Kevin > > > > On 07/03/2016 10:07, Dmitry Samersoff wrote: >> Cheleswer, >> >> Looks good for me. >> >> -Dmitry >> >> >> On 2016-03-03 19:28, Cheleswer Sahu wrote: >>> Hi, >>> >>> Please review the new code changes for this bug. I have removed " >>> fstat()" call which seems not safe to read the "/proc/map/self" file >>> and have made some other changes too. Please find the latest code in >>> below link >>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ >>> >>> >>> Regards, >>> Cheleswer >>> >>> -----Original Message----- >>> From: Dean Long >>> Sent: Wednesday, February 24, 2016 7:44 AM >>> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu >>> Cc: serviceability-dev at openjdk.java.net; >>> hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient >>> >>> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: >>>> On 2/23/16 5:56 AM, Thomas St?fe wrote: >>>>> Hi Cheleswer, >>>>> >>>>> >>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Please review the code changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>>> >>>>>> >>>>>> >>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>>> >>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>>> >>>>>> >>>>>> >>>>>> Bug Brief: >>>>>> >>>>>> While investigating bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>>> it has been observed that "check_addr0() " function is not written >>>>>> efficiently. >>>>>> >>>>>> This function is trying to read each "prmap_t" entry in >>>>>> "/proc/self/map" >>>>>> file one by one which is time taking and can cause in long pauses. >>>>>> >>>>>> >>>>>> >>>>>> Solution proposed: >>>>>> >>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one >>>>>> by one, read the entries in chunks. There can be many entries in >>>>>> "map" >>>>>> file, >>>>>> so I have decided to read these >>>>>> >>>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>>> a lot of read calls and results in smaller pause times. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Cheleswer >>>>>> >>>>> We saw cases, especially on Solaris, where the content of a file in >>>>> the >>>>> proc file system changed under us while we were reading it. So this >>>>> should >>>>> be kept in mind. The original code seems also broken in that regard, >>>>> because it assumes the ::read() call to read the full size of a >>>>> prmap_t >>>>> entry, but it may theoretically read an incomplete entry. >>>>> >>>>> As for your coding, you first estimate the size of the mapping file >>>>> and >>>>> then use this to determine how many entries to read; but when >>>>> reading, this >>>>> information may already be stale. I think it would be more robust and >>>>> also >>>>> simpler to just try to read as many entries as possible - in >>>>> chunks, to >>>>> make reading faster - until you get EOF. >>>>> >>>>> Kind Regards, Thomas >>>> I'm really sure that we've been down this road before. In particular, >>>> Dmitry Samersoff has worked on this issue (or one very much like it) >>>> before, but he is on vacation until the end of the month. >>>> >>> There was a similar issue with Linux /proc/self/maps, and whether it was >>> safe to read the file with buffered stdio or not. See 8009062 and >>> 7017193. >>> >>> dl >>> >>>> Dan >>>> >>>> >>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Please review the code changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>>> >>>>>> >>>>>> >>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>>> >>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>>> >>>>>> >>>>>> >>>>>> Bug Brief: >>>>>> >>>>>> While investigating bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>>> it has been observed that "check_addr0() " function is not written >>>>>> efficiently. >>>>>> >>>>>> This function is trying to read each "prmap_t" entry in >>>>>> "/proc/self/map" >>>>>> file one by one which is time taking and can cause in long pauses. >>>>>> >>>>>> >>>>>> >>>>>> Solution proposed: >>>>>> >>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file >>>>>> one by >>>>>> one, read the entries in chunks. There can be many entries in "map" >>>>>> file, >>>>>> so I have decided to read these >>>>>> >>>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>>> a lot >>>>>> of read calls and results in smaller pause times. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Cheleswer >>>>>> >> > From rachel.protacio at oracle.com Mon Mar 7 14:56:09 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 09:56:09 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56DCCC27.9030207@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> <56DCCC27.9030207@oracle.com> Message-ID: <56DD9689.5010201@oracle.com> Thanks, David! Rachel On 3/6/2016 7:32 PM, David Holmes wrote: > Looks good Rachel! > > Thanks, > David > > On 5/03/2016 6:22 AM, Rachel Protacio wrote: >> Hi Dmitry, >> >> Thanks for the review! I've fixed the test as requested :) >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ >> >> Rachel >> >> On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >>> Hi Rachel, >>> >>> Overall looks good. Few test comments: >>> 1) Import of WeakReference seems unneeded. >>> 2) For "-Xlog:safepointcleanup=off" test case you have >>> "output.shouldNotContain("[safepointcleanup]");". Is it make sense to >>> add "output.shouldContain("[safepointcleanup]")" for case when log is >>> enabled? >>> 3) I think you should add test case for aliased option. >>> >>> Thank you, >>> Dmitry >>> >>> On 03.03.2016 23:35, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Coming close to the end of the logging conversions for now! Here's >>>> one for TraceSafepointCleanupTime, which is turning into >>>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>>> aliased in this change. >>>> >>>> To reiterate the conclusion from the TraceStartupTime conversion, I >>>> ask that as long as there are no objections to the correctness of the >>>> code, we allow this implementation for now, and I will then file a >>>> follow-up bug for possible improvements to the switch statement and >>>> TraceTime function signature situation. Since this is the only other >>>> "TraceTime" conversion, TraceTime implementation changes will be more >>>> succinctly addressable after this SafepointCleanupTime change than >>>> before it. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>>> >>>> Sample old output: >>>> >>>> $ java -XX:+TraceSafepointCleanupTime -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>>> [deflating idle monitors, 0.0000088 secs] >>>> [updating inline caches, 0.0000007 secs] >>>> [compilation policy safepoint handler, 0.0000009 secs] >>>> [mark nmethods, 0.0000164 secs] >>>> [purging class loader data graph, 0.0000002 secs] >>>> >>>> Sample new output: >>>> >>>> $ java -Xlog:safepointcleanup -version >>>> java version "9-internal" >>>> Java(TM) SE Runtime Environment (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>>> [0.348s][info][safepointcleanup] deflating idle monitors, >>>> 0.0000059 secs >>>> [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 >>>> secs >>>> [0.348s][info][safepointcleanup] compilation policy safepoint >>>> handler, 0.0000006 secs >>>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>>> [0.348s][info][safepointcleanup] purging class loader data graph, >>>> 0.0000001 secs >>>> >>>> >>>> Tested using JPRT and RBT hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> From harold.seigel at oracle.com Mon Mar 7 16:58:37 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 7 Mar 2016 11:58:37 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DA0155.7090507@oracle.com> References: <56DA0155.7090507@oracle.com> Message-ID: <56DDB33D.20506@oracle.com> Hi Rachel, The changes look good. Are the ResourceMarks needed at lines 661 and 703 in verifier.cpp? If they are needed you can change them to ResourceMark rm(THREAD); Thanks, Harold On 3/4/2016 4:42 PM, Rachel Protacio wrote: > Hello, > > Please review this conversion of -XX:+VerboseVerification to > -Xlog:verboseverification=info. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ > > Sample old output: > > Verifying class hello with new format > Verifying method hello.()V > StackMapTable: frame_count = 0 > table = { > } > bci: @0 > flags: { flagThisUninit } > locals: { uninitializedThis } > stack: { } > offset = 0, opcode = aload_0 > bci: @1 > flags: { flagThisUninit } > locals: { uninitializedThis } > stack: { uninitializedThis } > offset = 1, opcode = invokespecial > bci: @4 > flags: { } > locals: { 'hello' } > stack: { } > offset = 4, opcode = return > Verifying method hello.main([Ljava/lang/String;)V > > Sample new output: > > [0.696s][info][verboseverification] Verifying class > VerboseVerificationTest$InternalClass with new format > [0.696s][info][verboseverification] Verifying method > VerboseVerificationTest$InternalClass.()V > [0.696s][info][verboseverification] StackMapTable: frame_count = 0 > [0.696s][info][verboseverification] table = { > [0.696s][info][verboseverification] } > [0.696s][info][verboseverification] bci: @0 > [0.696s][info][verboseverification] flags: { flagThisUninit } > [0.696s][info][verboseverification] locals: { uninitializedThis } > [0.696s][info][verboseverification] stack: { } > [0.696s][info][verboseverification] offset = 0, opcode = aload_0 > [0.696s][info][verboseverification] bci: @1 > [0.696s][info][verboseverification] flags: { flagThisUninit } > [0.696s][info][verboseverification] locals: { uninitializedThis } > [0.696s][info][verboseverification] stack: { uninitializedThis } > [0.696s][info][verboseverification] offset = 1, opcode = > invokespecial > [0.696s][info][verboseverification] bci: @4 > [0.696s][info][verboseverification] flags: { } > [0.696s][info][verboseverification] locals: { > 'VerboseVerificationTest$InternalClass' } > [0.696s][info][verboseverification] stack: { } > [0.696s][info][verboseverification] offset = 4, opcode = return > [0.696s][info][verboseverification] Verifying method > VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V > > Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and > non-colo tests. > > Thank you, > Rachel From rachel.protacio at oracle.com Mon Mar 7 19:07:20 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 14:07:20 -0500 Subject: RFR (XS): 8150085: Delete TraceClearedExceptions flag instead of conversion to Unified Logging Message-ID: <56DDD168.4030702@oracle.com> Hello, Please review this very small change, deleting -XX:+TraceClearedExceptions (as part of our UL updates). A compatibility request has been approved with regard to this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.01/ Passes JPRT and RBT hotspot and non-colo tests. Thanks! Rachel From rachel.protacio at oracle.com Mon Mar 7 20:18:26 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 15:18:26 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DCD309.1070505@oracle.com> References: <56DA0155.7090507@oracle.com> <56DCD309.1070505@oracle.com> Message-ID: <56DDE212.4070405@oracle.com> Hi, Thanks for the review, David! New webrev: http://cr.openjdk.java.net/~rprotacio/8150083.02/ Changes: - removed unnecessary ResourceMark - added "THREAD" as argument to existing ResourceMarks - removed -XX:+VerboseVerification legacy test in ClassInitializationTest.java Responses inline. On 3/6/2016 8:02 PM, David Holmes wrote: > Hi Rachel, > > A few comments ... > > On 5/03/2016 7:42 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this conversion of -XX:+VerboseVerification to >> -Xlog:verboseverification=info. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ > > if (log_is_enabled(Info, classinit)){ > 194 log_end_verification(LogHandle(classinit)::info_stream(), > klassName, exception_name, THREAD); > 195 } > 196 if (log_is_enabled(Info, verboseverification)){ > 197 ResourceMark rm; > 198 > log_end_verification(LogHandle(verboseverification)::info_stream(), > klassName, exception_name, THREAD); > 199 } > > No ResourceMark needed at #197 (for same reason it is not needed at > #194). Oh I see. I've removed it. > > --- > > 603 if (was_recursively_verified()){ > 604 log_info(verboseverification)("Recursive verification > detected for: %s", _klass->external_name()); > > > > 605 log_info(classinit)("Recursive verification detected for: %s", > 606 _klass->external_name()); > 607 } > > When TraceclassInitialization was converted it was suggested that > where we had: > > if (TraceClassInitialization || VerboseVerification) { > // log something .... > > and we then got the output printed twice with classinit using UL, that > these would be fixed up when VerboseVerification was converted: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016846.html > > > "When VerboseVerification is converted to UL, the logging statements > will be more compact." Thanks for bringing that up. So actually since that discussion, the precedent has been set with classpath and classloader (?) that rather than force a UL combination to log lines that were previously coming from if (TraceClassInitialization || VerboseVerification) { would have to be logged as, e.g. log_info(classinit, verboseverification)() which would have to be specified on the command line as one of (a) -Xlog:classinit+verboseverification (b) -Xlog:classinit* (c) -Xlog:verboseverification* which is unfairly complicated to the user. So since there's a precedent to have two separate printings and it is simpler for the user, the plan is to leave the code as it is in the webrev. But if you have a specific objection and preferred approach, I'm happy to consider it. > > --- > > test/runtime/logging/ClassInitializationTest.java > > I think the "Ensure that VerboseVerification still triggers > appropriate messages" subtest can be deleted now as we test > -Xlog:verboseverification separately. It was only present to ensure > the old VerboseVerification flag still functioned after the classinit > change. > Good point. Thank you, Rachel > --- > > Thanks, > David > ----- > > >> Sample old output: >> >> Verifying class hello with new format >> Verifying method hello.()V >> StackMapTable: frame_count = 0 >> table = { >> } >> bci: @0 >> flags: { flagThisUninit } >> locals: { uninitializedThis } >> stack: { } >> offset = 0, opcode = aload_0 >> bci: @1 >> flags: { flagThisUninit } >> locals: { uninitializedThis } >> stack: { uninitializedThis } >> offset = 1, opcode = invokespecial >> bci: @4 >> flags: { } >> locals: { 'hello' } >> stack: { } >> offset = 4, opcode = return >> Verifying method hello.main([Ljava/lang/String;)V >> >> Sample new output: >> >> [0.696s][info][verboseverification] Verifying class >> VerboseVerificationTest$InternalClass with new format >> [0.696s][info][verboseverification] Verifying method >> VerboseVerificationTest$InternalClass.()V >> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >> [0.696s][info][verboseverification] table = { >> [0.696s][info][verboseverification] } >> [0.696s][info][verboseverification] bci: @0 >> [0.696s][info][verboseverification] flags: { flagThisUninit } >> [0.696s][info][verboseverification] locals: { uninitializedThis } >> [0.696s][info][verboseverification] stack: { } >> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >> [0.696s][info][verboseverification] bci: @1 >> [0.696s][info][verboseverification] flags: { flagThisUninit } >> [0.696s][info][verboseverification] locals: { uninitializedThis } >> [0.696s][info][verboseverification] stack: { uninitializedThis } >> [0.696s][info][verboseverification] offset = 1, opcode = >> invokespecial >> [0.696s][info][verboseverification] bci: @4 >> [0.696s][info][verboseverification] flags: { } >> [0.696s][info][verboseverification] locals: { >> 'VerboseVerificationTest$InternalClass' } >> [0.696s][info][verboseverification] stack: { } >> [0.696s][info][verboseverification] offset = 4, opcode = return >> [0.696s][info][verboseverification] Verifying method >> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >> >> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and >> non-colo tests. >> >> Thank you, >> Rachel From rachel.protacio at oracle.com Mon Mar 7 20:19:57 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 15:19:57 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DDB33D.20506@oracle.com> References: <56DA0155.7090507@oracle.com> <56DDB33D.20506@oracle.com> Message-ID: <56DDE26D.4030608@oracle.com> Hi, Harold, Thanks for noticing. I have fixed as requested, in the webrev I just sent :) Rachel On 3/7/2016 11:58 AM, harold seigel wrote: > Hi Rachel, > > The changes look good. Are the ResourceMarks needed at lines 661 and > 703 in verifier.cpp? > > If they are needed you can change them to ResourceMark rm(THREAD); > > Thanks, Harold > > On 3/4/2016 4:42 PM, Rachel Protacio wrote: >> Hello, >> >> Please review this conversion of -XX:+VerboseVerification to >> -Xlog:verboseverification=info. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ >> >> Sample old output: >> >> Verifying class hello with new format >> Verifying method hello.()V >> StackMapTable: frame_count = 0 >> table = { >> } >> bci: @0 >> flags: { flagThisUninit } >> locals: { uninitializedThis } >> stack: { } >> offset = 0, opcode = aload_0 >> bci: @1 >> flags: { flagThisUninit } >> locals: { uninitializedThis } >> stack: { uninitializedThis } >> offset = 1, opcode = invokespecial >> bci: @4 >> flags: { } >> locals: { 'hello' } >> stack: { } >> offset = 4, opcode = return >> Verifying method hello.main([Ljava/lang/String;)V >> >> Sample new output: >> >> [0.696s][info][verboseverification] Verifying class >> VerboseVerificationTest$InternalClass with new format >> [0.696s][info][verboseverification] Verifying method >> VerboseVerificationTest$InternalClass.()V >> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >> [0.696s][info][verboseverification] table = { >> [0.696s][info][verboseverification] } >> [0.696s][info][verboseverification] bci: @0 >> [0.696s][info][verboseverification] flags: { flagThisUninit } >> [0.696s][info][verboseverification] locals: { uninitializedThis } >> [0.696s][info][verboseverification] stack: { } >> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >> [0.696s][info][verboseverification] bci: @1 >> [0.696s][info][verboseverification] flags: { flagThisUninit } >> [0.696s][info][verboseverification] locals: { uninitializedThis } >> [0.696s][info][verboseverification] stack: { uninitializedThis } >> [0.696s][info][verboseverification] offset = 1, opcode = >> invokespecial >> [0.696s][info][verboseverification] bci: @4 >> [0.696s][info][verboseverification] flags: { } >> [0.696s][info][verboseverification] locals: { >> 'VerboseVerificationTest$InternalClass' } >> [0.696s][info][verboseverification] stack: { } >> [0.696s][info][verboseverification] offset = 4, opcode = return >> [0.696s][info][verboseverification] Verifying method >> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >> >> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot >> and non-colo tests. >> >> Thank you, >> Rachel > From harold.seigel at oracle.com Mon Mar 7 21:16:31 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 7 Mar 2016 16:16:31 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DDE26D.4030608@oracle.com> References: <56DA0155.7090507@oracle.com> <56DDB33D.20506@oracle.com> <56DDE26D.4030608@oracle.com> Message-ID: <56DDEFAF.409@oracle.com> The latest webrev looks good. Thanks, Harold On 3/7/2016 3:19 PM, Rachel Protacio wrote: > Hi, Harold, > > Thanks for noticing. I have fixed as requested, in the webrev I just > sent :) > > Rachel > > On 3/7/2016 11:58 AM, harold seigel wrote: >> Hi Rachel, >> >> The changes look good. Are the ResourceMarks needed at lines 661 and >> 703 in verifier.cpp? >> >> If they are needed you can change them to ResourceMark rm(THREAD); >> >> Thanks, Harold >> >> On 3/4/2016 4:42 PM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this conversion of -XX:+VerboseVerification to >>> -Xlog:verboseverification=info. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ >>> >>> Sample old output: >>> >>> Verifying class hello with new format >>> Verifying method hello.()V >>> StackMapTable: frame_count = 0 >>> table = { >>> } >>> bci: @0 >>> flags: { flagThisUninit } >>> locals: { uninitializedThis } >>> stack: { } >>> offset = 0, opcode = aload_0 >>> bci: @1 >>> flags: { flagThisUninit } >>> locals: { uninitializedThis } >>> stack: { uninitializedThis } >>> offset = 1, opcode = invokespecial >>> bci: @4 >>> flags: { } >>> locals: { 'hello' } >>> stack: { } >>> offset = 4, opcode = return >>> Verifying method hello.main([Ljava/lang/String;)V >>> >>> Sample new output: >>> >>> [0.696s][info][verboseverification] Verifying class >>> VerboseVerificationTest$InternalClass with new format >>> [0.696s][info][verboseverification] Verifying method >>> VerboseVerificationTest$InternalClass.()V >>> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >>> [0.696s][info][verboseverification] table = { >>> [0.696s][info][verboseverification] } >>> [0.696s][info][verboseverification] bci: @0 >>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>> [0.696s][info][verboseverification] stack: { } >>> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >>> [0.696s][info][verboseverification] bci: @1 >>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>> [0.696s][info][verboseverification] stack: { uninitializedThis } >>> [0.696s][info][verboseverification] offset = 1, opcode = >>> invokespecial >>> [0.696s][info][verboseverification] bci: @4 >>> [0.696s][info][verboseverification] flags: { } >>> [0.696s][info][verboseverification] locals: { >>> 'VerboseVerificationTest$InternalClass' } >>> [0.696s][info][verboseverification] stack: { } >>> [0.696s][info][verboseverification] offset = 4, opcode = return >>> [0.696s][info][verboseverification] Verifying method >>> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >>> >>> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot >>> and non-colo tests. >>> >>> Thank you, >>> Rachel >> > From david.holmes at oracle.com Mon Mar 7 21:17:04 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Mar 2016 07:17:04 +1000 Subject: RFR (XS): 8150085: Delete TraceClearedExceptions flag instead of conversion to Unified Logging In-Reply-To: <56DDD168.4030702@oracle.com> References: <56DDD168.4030702@oracle.com> Message-ID: <56DDEFD0.4000203@oracle.com> Hi Rachel, Can we put this under -Xlog:exceptions=debug(?) instead of deleting it. The fact an exception gets explicitly cleared may be useful if trying to track down an exception issue. Thanks, David On 8/03/2016 5:07 AM, Rachel Protacio wrote: > Hello, > > Please review this very small change, deleting > -XX:+TraceClearedExceptions (as part of our UL updates). A compatibility > request has been approved with regard to this change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.01/ > > Passes JPRT and RBT hotspot and non-colo tests. > > Thanks! > Rachel From rachel.protacio at oracle.com Mon Mar 7 21:18:07 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 16:18:07 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DDEFAF.409@oracle.com> References: <56DA0155.7090507@oracle.com> <56DDB33D.20506@oracle.com> <56DDE26D.4030608@oracle.com> <56DDEFAF.409@oracle.com> Message-ID: <56DDF00F.7080004@oracle.com> Thank you, Harold! Rachel On 3/7/2016 4:16 PM, harold seigel wrote: > The latest webrev looks good. > > Thanks, Harold > > On 3/7/2016 3:19 PM, Rachel Protacio wrote: >> Hi, Harold, >> >> Thanks for noticing. I have fixed as requested, in the webrev I just >> sent :) >> >> Rachel >> >> On 3/7/2016 11:58 AM, harold seigel wrote: >>> Hi Rachel, >>> >>> The changes look good. Are the ResourceMarks needed at lines 661 >>> and 703 in verifier.cpp? >>> >>> If they are needed you can change them to ResourceMark rm(THREAD); >>> >>> Thanks, Harold >>> >>> On 3/4/2016 4:42 PM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this conversion of -XX:+VerboseVerification to >>>> -Xlog:verboseverification=info. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ >>>> >>>> Sample old output: >>>> >>>> Verifying class hello with new format >>>> Verifying method hello.()V >>>> StackMapTable: frame_count = 0 >>>> table = { >>>> } >>>> bci: @0 >>>> flags: { flagThisUninit } >>>> locals: { uninitializedThis } >>>> stack: { } >>>> offset = 0, opcode = aload_0 >>>> bci: @1 >>>> flags: { flagThisUninit } >>>> locals: { uninitializedThis } >>>> stack: { uninitializedThis } >>>> offset = 1, opcode = invokespecial >>>> bci: @4 >>>> flags: { } >>>> locals: { 'hello' } >>>> stack: { } >>>> offset = 4, opcode = return >>>> Verifying method hello.main([Ljava/lang/String;)V >>>> >>>> Sample new output: >>>> >>>> [0.696s][info][verboseverification] Verifying class >>>> VerboseVerificationTest$InternalClass with new format >>>> [0.696s][info][verboseverification] Verifying method >>>> VerboseVerificationTest$InternalClass.()V >>>> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >>>> [0.696s][info][verboseverification] table = { >>>> [0.696s][info][verboseverification] } >>>> [0.696s][info][verboseverification] bci: @0 >>>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>>> [0.696s][info][verboseverification] stack: { } >>>> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >>>> [0.696s][info][verboseverification] bci: @1 >>>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>>> [0.696s][info][verboseverification] stack: { uninitializedThis } >>>> [0.696s][info][verboseverification] offset = 1, opcode = >>>> invokespecial >>>> [0.696s][info][verboseverification] bci: @4 >>>> [0.696s][info][verboseverification] flags: { } >>>> [0.696s][info][verboseverification] locals: { >>>> 'VerboseVerificationTest$InternalClass' } >>>> [0.696s][info][verboseverification] stack: { } >>>> [0.696s][info][verboseverification] offset = 4, opcode = return >>>> [0.696s][info][verboseverification] Verifying method >>>> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >>>> >>>> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot >>>> and non-colo tests. >>>> >>>> Thank you, >>>> Rachel >>> >> > From david.holmes at oracle.com Mon Mar 7 21:27:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Mar 2016 07:27:36 +1000 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DDE212.4070405@oracle.com> References: <56DA0155.7090507@oracle.com> <56DCD309.1070505@oracle.com> <56DDE212.4070405@oracle.com> Message-ID: <56DDF248.1010309@oracle.com> Hi Rachel, On 8/03/2016 6:18 AM, Rachel Protacio wrote: > Hi, > > Thanks for the review, David! > > New webrev: http://cr.openjdk.java.net/~rprotacio/8150083.02/ > Changes: > - removed unnecessary ResourceMark > - added "THREAD" as argument to existing ResourceMarks > - removed -XX:+VerboseVerification legacy test in > ClassInitializationTest.java All good. The duplication situation is not completely clean but I don't see any general way to handle it given the need to extract different streams depending on the log tag that is active. Thanks, David > Responses inline. > > On 3/6/2016 8:02 PM, David Holmes wrote: >> Hi Rachel, >> >> A few comments ... >> >> On 5/03/2016 7:42 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this conversion of -XX:+VerboseVerification to >>> -Xlog:verboseverification=info. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ >> >> if (log_is_enabled(Info, classinit)){ >> 194 log_end_verification(LogHandle(classinit)::info_stream(), >> klassName, exception_name, THREAD); >> 195 } >> 196 if (log_is_enabled(Info, verboseverification)){ >> 197 ResourceMark rm; >> 198 >> log_end_verification(LogHandle(verboseverification)::info_stream(), >> klassName, exception_name, THREAD); >> 199 } >> >> No ResourceMark needed at #197 (for same reason it is not needed at >> #194). > Oh I see. I've removed it. >> >> --- >> >> 603 if (was_recursively_verified()){ >> 604 log_info(verboseverification)("Recursive verification >> detected for: %s", _klass->external_name()); >> >> >> >> 605 log_info(classinit)("Recursive verification detected for: %s", >> 606 _klass->external_name()); >> 607 } >> >> When TraceclassInitialization was converted it was suggested that >> where we had: >> >> if (TraceClassInitialization || VerboseVerification) { >> // log something .... >> >> and we then got the output printed twice with classinit using UL, that >> these would be fixed up when VerboseVerification was converted: >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016846.html >> >> >> "When VerboseVerification is converted to UL, the logging statements >> will be more compact." > Thanks for bringing that up. So actually since that discussion, the > precedent has been set with classpath and classloader (?) that rather > than force a UL combination to log lines that were previously coming from > if (TraceClassInitialization || VerboseVerification) { > would have to be logged as, e.g. > log_info(classinit, verboseverification)() > which would have to be specified on the command line as one of > (a) -Xlog:classinit+verboseverification > (b) -Xlog:classinit* > (c) -Xlog:verboseverification* > which is unfairly complicated to the user. So since there's a precedent > to have two separate printings and it is simpler for the user, the plan > is to leave the code as it is in the webrev. But if you have a specific > objection and preferred approach, I'm happy to consider it. >> >> --- >> >> test/runtime/logging/ClassInitializationTest.java >> >> I think the "Ensure that VerboseVerification still triggers >> appropriate messages" subtest can be deleted now as we test >> -Xlog:verboseverification separately. It was only present to ensure >> the old VerboseVerification flag still functioned after the classinit >> change. >> > Good point. > Thank you, > Rachel >> --- >> >> Thanks, >> David >> ----- >> >> >>> Sample old output: >>> >>> Verifying class hello with new format >>> Verifying method hello.()V >>> StackMapTable: frame_count = 0 >>> table = { >>> } >>> bci: @0 >>> flags: { flagThisUninit } >>> locals: { uninitializedThis } >>> stack: { } >>> offset = 0, opcode = aload_0 >>> bci: @1 >>> flags: { flagThisUninit } >>> locals: { uninitializedThis } >>> stack: { uninitializedThis } >>> offset = 1, opcode = invokespecial >>> bci: @4 >>> flags: { } >>> locals: { 'hello' } >>> stack: { } >>> offset = 4, opcode = return >>> Verifying method hello.main([Ljava/lang/String;)V >>> >>> Sample new output: >>> >>> [0.696s][info][verboseverification] Verifying class >>> VerboseVerificationTest$InternalClass with new format >>> [0.696s][info][verboseverification] Verifying method >>> VerboseVerificationTest$InternalClass.()V >>> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >>> [0.696s][info][verboseverification] table = { >>> [0.696s][info][verboseverification] } >>> [0.696s][info][verboseverification] bci: @0 >>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>> [0.696s][info][verboseverification] stack: { } >>> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >>> [0.696s][info][verboseverification] bci: @1 >>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>> [0.696s][info][verboseverification] stack: { uninitializedThis } >>> [0.696s][info][verboseverification] offset = 1, opcode = >>> invokespecial >>> [0.696s][info][verboseverification] bci: @4 >>> [0.696s][info][verboseverification] flags: { } >>> [0.696s][info][verboseverification] locals: { >>> 'VerboseVerificationTest$InternalClass' } >>> [0.696s][info][verboseverification] stack: { } >>> [0.696s][info][verboseverification] offset = 4, opcode = return >>> [0.696s][info][verboseverification] Verifying method >>> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >>> >>> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and >>> non-colo tests. >>> >>> Thank you, >>> Rachel > From rachel.protacio at oracle.com Mon Mar 7 21:49:57 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 7 Mar 2016 16:49:57 -0500 Subject: RFR: 8150083: Convert VerboseVerification to Unified Logging In-Reply-To: <56DDF248.1010309@oracle.com> References: <56DA0155.7090507@oracle.com> <56DCD309.1070505@oracle.com> <56DDE212.4070405@oracle.com> <56DDF248.1010309@oracle.com> Message-ID: <56DDF785.2080903@oracle.com> Hi, On 3/7/2016 4:27 PM, David Holmes wrote: > Hi Rachel, > > On 8/03/2016 6:18 AM, Rachel Protacio wrote: >> Hi, >> >> Thanks for the review, David! >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8150083.02/ >> Changes: >> - removed unnecessary ResourceMark >> - added "THREAD" as argument to existing ResourceMarks >> - removed -XX:+VerboseVerification legacy test in >> ClassInitializationTest.java > > All good. The duplication situation is not completely clean but I > don't see any general way to handle it given the need to extract > different streams depending on the log tag that is active. > Thank you, David. Will commit. Rachel > Thanks, > David > >> Responses inline. >> >> On 3/6/2016 8:02 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> A few comments ... >>> >>> On 5/03/2016 7:42 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this conversion of -XX:+VerboseVerification to >>>> -Xlog:verboseverification=info. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150083 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150083.01/ >>> >>> if (log_is_enabled(Info, classinit)){ >>> 194 log_end_verification(LogHandle(classinit)::info_stream(), >>> klassName, exception_name, THREAD); >>> 195 } >>> 196 if (log_is_enabled(Info, verboseverification)){ >>> 197 ResourceMark rm; >>> 198 >>> log_end_verification(LogHandle(verboseverification)::info_stream(), >>> klassName, exception_name, THREAD); >>> 199 } >>> >>> No ResourceMark needed at #197 (for same reason it is not needed at >>> #194). >> Oh I see. I've removed it. >>> >>> --- >>> >>> 603 if (was_recursively_verified()){ >>> 604 log_info(verboseverification)("Recursive verification >>> detected for: %s", _klass->external_name()); >>> >>> >>> >>> 605 log_info(classinit)("Recursive verification detected for: %s", >>> 606 _klass->external_name()); >>> 607 } >>> >>> When TraceclassInitialization was converted it was suggested that >>> where we had: >>> >>> if (TraceClassInitialization || VerboseVerification) { >>> // log something .... >>> >>> and we then got the output printed twice with classinit using UL, that >>> these would be fixed up when VerboseVerification was converted: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-November/016846.html >>> >>> >>> >>> "When VerboseVerification is converted to UL, the logging statements >>> will be more compact." >> Thanks for bringing that up. So actually since that discussion, the >> precedent has been set with classpath and classloader (?) that rather >> than force a UL combination to log lines that were previously coming >> from >> if (TraceClassInitialization || VerboseVerification) { >> would have to be logged as, e.g. >> log_info(classinit, verboseverification)() >> which would have to be specified on the command line as one of >> (a) -Xlog:classinit+verboseverification >> (b) -Xlog:classinit* >> (c) -Xlog:verboseverification* >> which is unfairly complicated to the user. So since there's a precedent >> to have two separate printings and it is simpler for the user, the plan >> is to leave the code as it is in the webrev. But if you have a specific >> objection and preferred approach, I'm happy to consider it. >>> >>> --- >>> >>> test/runtime/logging/ClassInitializationTest.java >>> >>> I think the "Ensure that VerboseVerification still triggers >>> appropriate messages" subtest can be deleted now as we test >>> -Xlog:verboseverification separately. It was only present to ensure >>> the old VerboseVerification flag still functioned after the classinit >>> change. >>> >> Good point. >> Thank you, >> Rachel >>> --- >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> Sample old output: >>>> >>>> Verifying class hello with new format >>>> Verifying method hello.()V >>>> StackMapTable: frame_count = 0 >>>> table = { >>>> } >>>> bci: @0 >>>> flags: { flagThisUninit } >>>> locals: { uninitializedThis } >>>> stack: { } >>>> offset = 0, opcode = aload_0 >>>> bci: @1 >>>> flags: { flagThisUninit } >>>> locals: { uninitializedThis } >>>> stack: { uninitializedThis } >>>> offset = 1, opcode = invokespecial >>>> bci: @4 >>>> flags: { } >>>> locals: { 'hello' } >>>> stack: { } >>>> offset = 4, opcode = return >>>> Verifying method hello.main([Ljava/lang/String;)V >>>> >>>> Sample new output: >>>> >>>> [0.696s][info][verboseverification] Verifying class >>>> VerboseVerificationTest$InternalClass with new format >>>> [0.696s][info][verboseverification] Verifying method >>>> VerboseVerificationTest$InternalClass.()V >>>> [0.696s][info][verboseverification] StackMapTable: frame_count = 0 >>>> [0.696s][info][verboseverification] table = { >>>> [0.696s][info][verboseverification] } >>>> [0.696s][info][verboseverification] bci: @0 >>>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>>> [0.696s][info][verboseverification] stack: { } >>>> [0.696s][info][verboseverification] offset = 0, opcode = aload_0 >>>> [0.696s][info][verboseverification] bci: @1 >>>> [0.696s][info][verboseverification] flags: { flagThisUninit } >>>> [0.696s][info][verboseverification] locals: { uninitializedThis } >>>> [0.696s][info][verboseverification] stack: { uninitializedThis } >>>> [0.696s][info][verboseverification] offset = 1, opcode = >>>> invokespecial >>>> [0.696s][info][verboseverification] bci: @4 >>>> [0.696s][info][verboseverification] flags: { } >>>> [0.696s][info][verboseverification] locals: { >>>> 'VerboseVerificationTest$InternalClass' } >>>> [0.696s][info][verboseverification] stack: { } >>>> [0.696s][info][verboseverification] offset = 4, opcode = return >>>> [0.696s][info][verboseverification] Verifying method >>>> VerboseVerificationTest$InternalClass.main([Ljava/lang/String;)V >>>> >>>> Tested with JPRT; jck vm, lang, and api/java_lang; and RBT hotspot and >>>> non-colo tests. >>>> >>>> Thank you, >>>> Rachel >> From coleen.phillimore at oracle.com Mon Mar 7 22:34:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 7 Mar 2016 17:34:53 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <62FC4886-B2E6-44FC-BE75-64E916E68391@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <08051172-BCC1-4C60-A8DE-11407BE3D07F@oracle.com> <0EFF60C2-B20E-4075-9355-3FD11A486AFD@oracle.com> <62FC4886-B2E6-44FC-BE75-64E916E68391@oracle.com> Message-ID: <56DE020D.3000500@oracle.com> Hi John, As Mandy said, we investigated using StackWalk API with MemberName for Throwable and the performance was *abysmal* and this performance impact would affect all applications, not just those explicitly using the StackWalk API. The good news is that keeping our internal representation for Throwable.backtrace allows us to clean up the StackWalk API to use only MemberName and bci. On 3/4/16 5:49 PM, John Rose wrote: > On Mar 4, 2016, at 2:00 PM, Mandy Chung wrote: >> Footprint of MemberName as well as GC pressure (as they are kept as weak references in VM) are the performance concern that we will have to look at it in a future release. > I hope we can increase our investment on MemberName as an all-purpose handle from Java to JVM metadata (like java.lang.Class). > Specifically, the weak-pointer logic can probably be tuned to reduce overheads, at the cost of increased coupling between MemberName and the JVM. I tried disabling the weak pointer logic for benchmarking and it was only a small portion of the overhead for throughput, but we didn't measure the cost to GC. Coleen > > But the coupling is reasonable; we need something like that, and jlr.Method is way too heavy. > > ? John From coleen.phillimore at oracle.com Mon Mar 7 22:55:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 7 Mar 2016 17:55:43 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D98D73.4010302@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> Message-ID: <56DE06EF.7040408@oracle.com> Hi Aleksey, This is an interesting experiment. On 3/4/16 8:28 AM, Aleksey Shipilev wrote: > On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: >> On 03/02/2016 10:57 PM, Coleen Phillimore wrote: >>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not impossible, >>>> so we better expose as little as possible. >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. It came from similar >>> code we've been prototyping for StackFrameInfo. >> OK, it's not perfectly clean from implementation standpoint, but this >> RFE might not be the best opportunity to polish that. At least make >> StackTraceElement constructor private (better), or package-private >> (acceptable), and then we are good to go. > Okay, here's a little exploration: > http://cr.openjdk.java.net/~shade/8150778/StackTraceBench.java > > The difference between allocating in Java code, and allocating on VM > side is marginal on my machine, but I think we are down to native memset > performance when allocating on VM side. Therefore, I'd probably stay > with Java allocation which codegen we absolutely control. Thanks for the experiment. We measured a greater performance difference. The theory is that through Java, allocation is a TLAB pointer update in most cases, vs going through all the C++ code to do allocation. The small difference for performance here isn't critical, but having the allocation in Java looks nicer to the Java programmers here. > Aside: see the last experiment, avoiding StringTable::intern (shows in > profiles a lot!) trims down construction costs down even further. I'd > think that is a worthwhile improvement to consider. Hm, this is an interesting experiment. I've been looking for a better way to store the name of the method rather than cpref. thanks, Coleen > > Cheers, > -Aleksey > > From coleen.phillimore at oracle.com Mon Mar 7 23:10:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 7 Mar 2016 18:10:32 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D89FDD.40804@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D89FDD.40804@oracle.com> Message-ID: <56DE0A68.1080104@oracle.com> On 3/3/16 3:34 PM, Max Ockner wrote: > Thanks for the additional feedback. > I have set all of the output to the debug level. > webrev: http://cr.openjdk.java.net/~mockner/8146551.04/ > > You can't really infer anything about the verbosity of a Trace* option > from the face that it starts with "Trace", though I agree that it > would make a lot more sense if that were the case... > > I chose to put all of the output on debug after accounting for 2 things; > (1) The output is extremely verbose, even for java -version. > Therefore, all output should be either debug or trace level. > (2) None of the output ever conditioned on Verbose or WizardMode. > Based on the conventions we have been following, the output shouldn't > be on trace level. > > ==> Debug level. Max, I agree. This looks really good. Why would someone turn on this logging? Well, if they are debugging class resolution, which is why the code is there in the first place. So ==> Debug level. I don't think we should use class+resolve rather than classresolve for this until there is some better documentation (in the JVM and online) about what the cross product of every word (or some non-words) means. It's too complicated and hard to use otherwise. Lastly, for the first round of conversions for the runtime flags, we're keeping most of the current output. Later, when more logging is added or when people working on other parts of runtime code use the logging there, they can convert that logging and pick the messages that are meaningful for that bit of code. We expect this to change over time. thanks, Coleen > > Thanks, > Max > > On 3/3/2016 4:45 AM, Bengt Rutisson wrote: >> >> Hi Max and Mikael, >> >> On 2016-03-03 10:40, Mikael Gerdin wrote: >>> Hi Max, >>> >>> On 2016-03-01 23:30, Max Ockner wrote: >>>> Hello, >>>> >>>> Please review this small fix which attempts to shorten the output from >>>> -Xlog:classresolve=info to an acceptable length. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>> >>>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>>> lines of output. This is unacceptably verbose for info level >>>> logging and >>>> most of the output is not useful. >>>> >>>> "java -Xlog:classresolve=info -version" used to produce: >>>> - 3,683 total lines of output. >>>> - 3,121 total lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 1,329 unique lines of output. >>>> - 767 unique lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 562 total lines of output from all other sources, all >>>> unique. >>>> >>>> The code in ConstantPool which called >>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>> >>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>> else { resolve the class } >>>> >>>> So if logging was turned on, the class would not be resolved properly, >>>> but it would produce a log entry saying that the class was being >>>> resolved. As a result, the constant pool entry would still contain a >>>> Symbol* the next time this piece of code was reached, and it would >>>> produce yet another classresolve log entry. In some cases, this was >>>> producing many consecutive identical log entries, taking up full pages >>>> at worst, and averaging a little over 4 duplicates per message. Not >>>> cool. >>>> >>>> The above duplication issue has been fixed, and the >>>> ConstantPool::trace_class_resolution output has been moved to the >>>> debug >>>> leve. There are still 562 unique lines of output for "java >>>> -Xlog:classresolve=info -version". There are now 767 additional unique >>>> lines of output when for the "java -Xlog:classresolve=debug >>>> -version" . >>>> This is better than before but still quite a lot. It seems like >>>> all of >>>> the info level output is equally important(or unimportant), as you can >>>> see in the sample below: >>>> >>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>> (super) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.GenericDeclaration (interface) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.AnnotatedElement (interface) >>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>>> (interface) >>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>> (super) >>>> >>>> How do you feel about this? Possible solutions include setting all >>>> output to debug level, or removing some of the logging messages. >>> >>> As I stated in the bug my personal opinion is that "info" level >>> logging should be fairly limited in order to make "-Xlog:all" a >>> useful flag to get a reasonable amount of output about what is >>> happening in a JVM. >>> >>> One approach could be to move the most verbose output to >>> classresolve=trace and keep the rest of classresolve output on the >>> debug level. >>> >>> The fact that the flag was called "TraceClassResolution" is in my >>> mind a hint that if it produces large amounts of output then perhaps >>> that output should be logged on the "trace" log level. >> >> +1 for this approach. >> >> I quite agree with Mikael that we should be a bit careful what we log >> at info level. >> >> Thanks, >> Bengt >> >>> >>> /Mikael >>> >>>> >>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>> modified to check for the new output. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> > From coleen.phillimore at oracle.com Mon Mar 7 23:20:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 7 Mar 2016 18:20:39 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56DD9689.5010201@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> <56DCCC27.9030207@oracle.com> <56DD9689.5010201@oracle.com> Message-ID: <56DE0CC7.4010701@oracle.com> Just to pile on. This looks great. Coleen On 3/7/16 9:56 AM, Rachel Protacio wrote: > Thanks, David! > Rachel > > On 3/6/2016 7:32 PM, David Holmes wrote: >> Looks good Rachel! >> >> Thanks, >> David >> >> On 5/03/2016 6:22 AM, Rachel Protacio wrote: >>> Hi Dmitry, >>> >>> Thanks for the review! I've fixed the test as requested :) >>> >>> New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ >>> >>> Rachel >>> >>> On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >>>> Hi Rachel, >>>> >>>> Overall looks good. Few test comments: >>>> 1) Import of WeakReference seems unneeded. >>>> 2) For "-Xlog:safepointcleanup=off" test case you have >>>> "output.shouldNotContain("[safepointcleanup]");". Is it make sense to >>>> add "output.shouldContain("[safepointcleanup]")" for case when log is >>>> enabled? >>>> 3) I think you should add test case for aliased option. >>>> >>>> Thank you, >>>> Dmitry >>>> >>>> On 03.03.2016 23:35, Rachel Protacio wrote: >>>>> Hello! >>>>> >>>>> Coming close to the end of the logging conversions for now! Here's >>>>> one for TraceSafepointCleanupTime, which is turning into >>>>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>>>> aliased in this change. >>>>> >>>>> To reiterate the conclusion from the TraceStartupTime conversion, I >>>>> ask that as long as there are no objections to the correctness of the >>>>> code, we allow this implementation for now, and I will then file a >>>>> follow-up bug for possible improvements to the switch statement and >>>>> TraceTime function signature situation. Since this is the only other >>>>> "TraceTime" conversion, TraceTime implementation changes will be more >>>>> succinctly addressable after this SafepointCleanupTime change than >>>>> before it. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>>>> >>>>> Sample old output: >>>>> >>>>> $ java -XX:+TraceSafepointCleanupTime -version >>>>> java version "9-internal" >>>>> Java(TM) SE Runtime Environment (fastdebug build >>>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>>>> [deflating idle monitors, 0.0000088 secs] >>>>> [updating inline caches, 0.0000007 secs] >>>>> [compilation policy safepoint handler, 0.0000009 secs] >>>>> [mark nmethods, 0.0000164 secs] >>>>> [purging class loader data graph, 0.0000002 secs] >>>>> >>>>> Sample new output: >>>>> >>>>> $ java -Xlog:safepointcleanup -version >>>>> java version "9-internal" >>>>> Java(TM) SE Runtime Environment (fastdebug build >>>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>>>> [0.348s][info][safepointcleanup] deflating idle monitors, >>>>> 0.0000059 secs >>>>> [0.348s][info][safepointcleanup] updating inline caches, 0.0000009 >>>>> secs >>>>> [0.348s][info][safepointcleanup] compilation policy safepoint >>>>> handler, 0.0000006 secs >>>>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>>>> [0.348s][info][safepointcleanup] purging class loader data graph, >>>>> 0.0000001 secs >>>>> >>>>> >>>>> Tested using JPRT and RBT hotspot and non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>>>> >>>>> >>>> >>> > From max.ockner at oracle.com Tue Mar 8 13:33:21 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 08 Mar 2016 08:33:21 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. Message-ID: <56DED4A1.6070208@oracle.com> Hi, Please review this small Unified Logging change. TraceClassLoadingPreorder has been converted to UL at the Debug level. Debug level was chosen since there are 342 lines of output for java -version. bug: https://bugs.openjdk.java.net/browse/JDK-8149995 webrev: http://cr.openjdk.java.net/~mockner/8149995/ Tested with jtreg runtime tests. No existing tests reference TraceClassLoadingPreorder from hotspot/test or jdk/test. Thanks, Max From rachel.protacio at oracle.com Tue Mar 8 15:03:59 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 8 Mar 2016 10:03:59 -0500 Subject: RFR: 8149991: Convert TraceSafepointCleanupTime to Unified Logging In-Reply-To: <56DE0CC7.4010701@oracle.com> References: <56D8A028.5090201@oracle.com> <56D9739E.1020909@oracle.com> <56D9EE75.5020109@oracle.com> <56DCCC27.9030207@oracle.com> <56DD9689.5010201@oracle.com> <56DE0CC7.4010701@oracle.com> Message-ID: <56DEE9DF.6030203@oracle.com> Thanks! Rachel On 3/7/2016 6:20 PM, Coleen Phillimore wrote: > > Just to pile on. This looks great. > Coleen > > On 3/7/16 9:56 AM, Rachel Protacio wrote: >> Thanks, David! >> Rachel >> >> On 3/6/2016 7:32 PM, David Holmes wrote: >>> Looks good Rachel! >>> >>> Thanks, >>> David >>> >>> On 5/03/2016 6:22 AM, Rachel Protacio wrote: >>>> Hi Dmitry, >>>> >>>> Thanks for the review! I've fixed the test as requested :) >>>> >>>> New webrev: http://cr.openjdk.java.net/~rprotacio/8149991.02/ >>>> >>>> Rachel >>>> >>>> On 3/4/2016 6:38 AM, Dmitry Dmitriev wrote: >>>>> Hi Rachel, >>>>> >>>>> Overall looks good. Few test comments: >>>>> 1) Import of WeakReference seems unneeded. >>>>> 2) For "-Xlog:safepointcleanup=off" test case you have >>>>> "output.shouldNotContain("[safepointcleanup]");". Is it make sense to >>>>> add "output.shouldContain("[safepointcleanup]")" for case when log is >>>>> enabled? >>>>> 3) I think you should add test case for aliased option. >>>>> >>>>> Thank you, >>>>> Dmitry >>>>> >>>>> On 03.03.2016 23:35, Rachel Protacio wrote: >>>>>> Hello! >>>>>> >>>>>> Coming close to the end of the logging conversions for now! Here's >>>>>> one for TraceSafepointCleanupTime, which is turning into >>>>>> -Xlog:safepointcleanup=info. As it has been a product option, it is >>>>>> aliased in this change. >>>>>> >>>>>> To reiterate the conclusion from the TraceStartupTime conversion, I >>>>>> ask that as long as there are no objections to the correctness of >>>>>> the >>>>>> code, we allow this implementation for now, and I will then file a >>>>>> follow-up bug for possible improvements to the switch statement and >>>>>> TraceTime function signature situation. Since this is the only other >>>>>> "TraceTime" conversion, TraceTime implementation changes will be >>>>>> more >>>>>> succinctly addressable after this SafepointCleanupTime change than >>>>>> before it. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149991 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8149991.01/ >>>>>> >>>>>> Sample old output: >>>>>> >>>>>> $ java -XX:+TraceSafepointCleanupTime -version >>>>>> java version "9-internal" >>>>>> Java(TM) SE Runtime Environment (fastdebug build >>>>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083) >>>>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>>>> 9-internal+0-2016-03-02-133604.rprotaci.8150083, mixed mode) >>>>>> [deflating idle monitors, 0.0000088 secs] >>>>>> [updating inline caches, 0.0000007 secs] >>>>>> [compilation policy safepoint handler, 0.0000009 secs] >>>>>> [mark nmethods, 0.0000164 secs] >>>>>> [purging class loader data graph, 0.0000002 secs] >>>>>> >>>>>> Sample new output: >>>>>> >>>>>> $ java -Xlog:safepointcleanup -version >>>>>> java version "9-internal" >>>>>> Java(TM) SE Runtime Environment (fastdebug build >>>>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991) >>>>>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >>>>>> 9-internal+0-2016-03-02-133610.rprotaci.8149991, mixed mode) >>>>>> [0.348s][info][safepointcleanup] deflating idle monitors, >>>>>> 0.0000059 secs >>>>>> [0.348s][info][safepointcleanup] updating inline caches, >>>>>> 0.0000009 >>>>>> secs >>>>>> [0.348s][info][safepointcleanup] compilation policy safepoint >>>>>> handler, 0.0000006 secs >>>>>> [0.348s][info][safepointcleanup] mark nmethods, 0.0000191 secs >>>>>> [0.348s][info][safepointcleanup] purging class loader data graph, >>>>>> 0.0000001 secs >>>>>> >>>>>> >>>>>> Tested using JPRT and RBT hotspot and non-colo tests. >>>>>> >>>>>> Thanks! >>>>>> Rachel >>>>>> >>>>>> >>>>> >>>> >> > From coleen.phillimore at oracle.com Tue Mar 8 18:32:31 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 8 Mar 2016 13:32:31 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D7B9DB.30601@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56D7A1A5.6090808@oracle.com> <56D7AB5A.6010601@oracle.com> <56D7B9DB.30601@oracle.com> Message-ID: <56DF1ABF.7010301@oracle.com> David, Thanks - a comment in the middle. On 3/2/16 11:13 PM, David Holmes wrote: > On 3/03/2016 1:11 PM, Coleen Phillimore wrote: >> >> >> On 3/2/16 9:29 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 3/03/2016 10:03 AM, Coleen Phillimore wrote: >>>> Freshly tested changes with jck tests, with missing checks and other >>>> changes to use the depth field, as pointed out by Aleksey. I've kept >>>> the StackTraceElement[] allocation in Java to match the new API >>>> that was >>>> approved. >>> >>> I would have argued for returning a constructed array instead but if >>> that decision has already been made then it has already been made. >> >> I see Mandy's reply afterward, but it's really an opinion question and I >> don't think there's a strong technical or correctness reason to do it >> one way rather than the other. The preference is to write most code in >> Java and it is faster to allocate these in Java. But this isn't a >> critical path for performance, it just helps. > > I'm not sure how it can be faster to allocate in Java when the VM does > the allocation anyway ?? It is certainly easier to write the array > initialization code in the Java. The ugly part of doing it in Java is > that the VM has to poke the right length into the depth field. From an > API design perspective it is cleaner for the called function to > allocate exactly the size and type of array needed rather than having > to communicate that information out, and then add checks to make sure > a different sized (or typed) array is not passed in. > > Just my 2c. > >>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >>> >>> Overall this looks good - makes me wonder why we didn't do it this way >>> earlier ?? :) >>> >> >> No idea! >>> javaClasses.cpp: >>> >>> 2044 { >>> 2045 ResourceMark rm; >>> 2046 log_info(stacktrace)("%s, %d", >>> throwable->klass()->external_name(), chunk_count); >>> 2047 } >>> >>> There is already a ResourceMark earlier in the method. (Otherwise it >>> should be inside a "log is enabled" guard.) >> >> I was being more cautious here but the one above is fine to use. >>> >>> 2063 if (throwable.is_null() || stack_trace_array_h.is_null() || >>> 2064 !is_StackTraceElementArray(stack_trace_array_h)) { >>> 2065 THROW(vmSymbols::java_lang_NullPointerException()); >>> 2066 } >>> >>> Not sure the type check for the array is needed (we don't check the >>> throwable object really is a Throwable) - but if it is then throwing >>> NPE seems misleading. >>> >> I was being overly cautious even though the only caller is the code in >> the jdk in Throwable. I could just check for NULL and if it's an array, >> but then I decided to check the element type. Actually, there's an >> assert later for element type. I can take it out. You're right, we >> don't check if throwable is a Throwable. >> >> If I leave it in, what else should I throw? > > ClassCastException would be the closest thing to signify an incorrect > type. But as this is a private internal API that should never be > called incorrectly then asserts regarding the array type should be fine. I like the idea of an assert better myself. Nobody will expect Throwable. to throw this exception. And it's a private API. Thanks! Coleen > >>> test/runtime/Throwable/TestThrowable.java >>> >>> Does that reflection hack still work in a modular VM? >> >> Good thing Mandy answered that. > > :) Yeah I haven't caught up with Jigsaw yet. > > Cheers, > David > >> Thanks! >> Coleen >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>>> Summary: replace JVM_GetStackTraceDepth and >>>>>>> JVM_GetStackTraceElement, >>>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>>> StackTraceElement[] >>>>>>> >>>>>>> These improvements were found during the investigation for >>>>>>> replacing >>>>>>> Throwable with the StackWalkAPI. This change also adds >>>>>>> iterator for >>>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>>> >>>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>>> approved. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>>> Looks interesting! >>>>>> >>>>>> Is there an underlying reason why we can't return the pre-filled >>>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to >>>>>> begin >>>>>> with? This will avoid leaking StackTraceElement constructor into >>>>>> standard library, *and* allows to make StackTraceElement fields >>>>>> final. >>>>>> Taking stuff back from the standard library is hard, if not >>>>>> impossible, >>>>>> so we better expose as little as possible. >>>>> >>>>> We measured that it's faster to allocate the StackTraceElement array >>>>> in Java and it seems cleaner to the Java guys. >>>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>>> >>>>>> Other minor nits: >>>>>> >>>>>> * Initializing fields to their default values is a code smell in >>>>>> Java: >>>>>> private transient int depth = 0; >>>>> >>>>> ok, not sure what "code smell" means but it doesn't have to be >>>>> initialized like this. It's set in the native code. >>>>>> >>>>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>>>> don't >>>>>> see the null checks in native parts. >>>>> >>>>> Yes, it would SEGV. I'll add some checks for null and make sure it's >>>>> an array of StackTraceElement. >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> -Aleksey >>>>>> >>>>> >>>> >> From rachel.protacio at oracle.com Tue Mar 8 19:55:57 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 8 Mar 2016 14:55:57 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56DED4A1.6070208@oracle.com> References: <56DED4A1.6070208@oracle.com> Message-ID: <56DF2E4D.6020706@oracle.com> Hey, Max, Looks good. Just a few comments: In src/share/vm/classfile/classFileParser.cpp should this have a ResourceMark rm(THREAD) at 5688? I realize there is probably one farther up in the scope, but in case someone were to delete it later, it might make sense to have a more local one? Not sure what the standard is on this. Also I think you forgot to delete the option from runtime/globals.hpp. Thanks, Rachel On 3/8/2016 8:33 AM, Max Ockner wrote: > Hi, > > Please review this small Unified Logging change. > TraceClassLoadingPreorder has been converted to UL at the Debug level. > Debug level was chosen since there are 342 lines of output for java > -version. > > bug: https://bugs.openjdk.java.net/browse/JDK-8149995 > webrev: http://cr.openjdk.java.net/~mockner/8149995/ > > Tested with jtreg runtime tests. > No existing tests reference TraceClassLoadingPreorder from > hotspot/test or jdk/test. > > Thanks, > Max From coleen.phillimore at oracle.com Tue Mar 8 22:01:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 8 Mar 2016 17:01:17 -0500 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56D528FF.3030308@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> Message-ID: <56DF4BAD.1040109@oracle.com> This latest version seems okay (or at least better than the other workarounds). thanks, Coleen On 3/1/16 12:30 AM, David Holmes wrote: > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> Hi David, >> >> On Mon, Feb 29, 2016 at 4:44 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> On 27/02/2016 2:05 AM, Thomas St?fe wrote: >> >> Hi, >> >> please take a look at this proposed fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148425 >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >> >> This adds a replacement function os::strerror() as a drop-in for >> strerror(), which has a number of issues. >> >> strerror() is unsafe to use and may cause (and has caused) >> crashes in >> multithreaded scenarios. It is also not ideal for log files >> because of the >> implicit localization of the error messages. >> >> For details please see the discussion under the bug report. >> >> >> I just came across strerror_l, which is required to be thread-safe. >> Is that a possible alternative? (I'm not sure how locale's are >> obtained). >> >> >> Sorry, I think this API is glibc only. At least I cannot find this in >> our AIX headers, nor on Solaris. > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of POSIX.1-2008. But as per Dalibor's link not > necessarily available: > > "This function is missing on some platforms: glibc 2.3.6, Mac OS X > 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, > HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, mingw, MSVC > 9, Interix 3.5, BeOS. " > > Pity. > > >> Otherwise what you have seems okay - though I do dislike having to >> duplicate all that details already buried in the system >> headers/library. Not sure we need to the long text at the VM level - >> which would simplify things a bit. >> >> >> I agree, I dislike this too. Like everyone else in this thread. But I >> think this is a pragmatic solution. >> >> I am a bit stuck here - should we really get rid of the long text >> feature? There are some callsites of strerror() in the hotspot where >> arguably the long text is better suited: >> - in assert_status() (see debug.hpp) - this ends up in the header of >> error files, if this suddenly changes to a literalized errno, people may >> be upset > > I added assert_status purely to expand on what the failing status was > :) I'm happy to see EINVAL in that context rather than "invalid > argument" (or whatever) :) > >> - when failing to write a heap dump file - see services/heapDumper.cpp. >> Which ends as printout on the command line, I think. > > Maybe ... if it is an error the user can fix. > >> The safe option would be to provide both variants (short and long text). >> Or, provide the safe, short variant for all logging calls - when >> "EINVAL" is enough, and let users continue to use strerror() for those >> few cases where the long text is needed. >> >> What do you think? > > Trying to decide what makes me least unhappy. :) Given you've already > done the work I guess having long and short forms is okay. > > Thanks, > David > >> Thanks, Thomas >> >> Thanks, >> David >> >> >> Please note that I did not yet change any call sites, although >> all call >> sites in the os namespace should already use the new function. I >> wanted to >> see whether there would be any general objections. >> >> Kind Regards, Thomas >> >> From robbin.ehn at oracle.com Wed Mar 9 08:35:40 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 9 Mar 2016 09:35:40 +0100 Subject: RFR(xs): 8151265: Add a way to extend UL tags Message-ID: <56DFE05C.8030609@oracle.com> Hi, please review this small change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151265/ Webrev: http://cr.openjdk.java.net/~rehn/8151265/webrev/ This adds an extension hpp with macro for extension tags. Thanks! /Robbin From robbin.ehn at oracle.com Wed Mar 9 09:02:06 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 9 Mar 2016 10:02:06 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes Message-ID: <56DFE68E.3070506@oracle.com> Hi, please review this minor change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ Tested with a new internal vm test (included). Thanks! /Robbin From thomas.stuefe at gmail.com Wed Mar 9 11:13:35 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 Mar 2016 12:13:35 +0100 Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: <56DD64B2.4010901@oracle.com> References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> <2fecd625-4723-4fbe-b148-36f7bb654df6@default> <56DD52F8.8070208@oracle.com> <56DD59A2.1030804@oracle.com> <56DD64B2.4010901@oracle.com> Message-ID: Hi all, I see the change is already pushed, but I am not sure this works as intended: We iterate now over all fully read items: + p = (prmap_t *)mbuff; + for(int i = 0; i < nmap; i++){ + if (p->pr_vaddr == 0x0) { + .... + } + p = (prmap_t *)(mbuff + sizeof(prmap_t)); + } Where do we move the pointer forward? The way I see it, we only ever examine the first and the second item, then repeat examining the second item over and over again. Instead of + p = (prmap_t *)(mbuff + sizeof(prmap_t)); Should this not be p = ((prmap_t *)mbuff) + i; or just p++; ? Kind Regards, Thomas On Mon, Mar 7, 2016 at 12:23 PM, David Holmes wrote: > On 7/03/2016 8:36 PM, Kevin Walls wrote: > >> >> Hi Cheleswer, >> >> Looks good. (While we've discussed it offline I haven't actually >> offered a public review). >> >> Just one more thing, and this concerns the original code not the change: >> >> 1880 st->print("Warning: Address: 0x%x, Size: %dK, >> ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname); >> > > Also %x is the wrong format specifier: > > typedef struct prmap { > uintptr_t pr_vaddr; /* virtual address of mapping */ > > David > ----- > > > We pass 3 params when we only print two items? The "p->pr_mapname", we >> pass again on the next line where we do have the the "%s" in the format >> string, so this one is unnecessary. 8-) >> >> Thanks >> Kevin >> >> >> >> On 07/03/2016 10:07, Dmitry Samersoff wrote: >> >>> Cheleswer, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> >>> On 2016-03-03 19:28, Cheleswer Sahu wrote: >>> >>>> Hi, >>>> >>>> Please review the new code changes for this bug. I have removed " >>>> fstat()" call which seems not safe to read the "/proc/map/self" file >>>> and have made some other changes too. Please find the latest code in >>>> below link >>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ >>>> >>>> >>>> Regards, >>>> Cheleswer >>>> >>>> -----Original Message----- >>>> From: Dean Long >>>> Sent: Wednesday, February 24, 2016 7:44 AM >>>> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu >>>> Cc: serviceability-dev at openjdk.java.net; >>>> hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient >>>> >>>> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: >>>> >>>>> On 2/23/16 5:56 AM, Thomas St?fe wrote: >>>>> >>>>>> Hi Cheleswer, >>>>>> >>>>>> >>>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review the code changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>>>> >>>>>>> >>>>>>> >>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>>>> >>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug Brief: >>>>>>> >>>>>>> While investigating bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>>>> it has been observed that "check_addr0() " function is not written >>>>>>> efficiently. >>>>>>> >>>>>>> This function is trying to read each "prmap_t" entry in >>>>>>> "/proc/self/map" >>>>>>> file one by one which is time taking and can cause in long pauses. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution proposed: >>>>>>> >>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one >>>>>>> by one, read the entries in chunks. There can be many entries in >>>>>>> "map" >>>>>>> file, >>>>>>> so I have decided to read these >>>>>>> >>>>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>>>> a lot of read calls and results in smaller pause times. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Cheleswer >>>>>>> >>>>>>> We saw cases, especially on Solaris, where the content of a file in >>>>>> the >>>>>> proc file system changed under us while we were reading it. So this >>>>>> should >>>>>> be kept in mind. The original code seems also broken in that regard, >>>>>> because it assumes the ::read() call to read the full size of a >>>>>> prmap_t >>>>>> entry, but it may theoretically read an incomplete entry. >>>>>> >>>>>> As for your coding, you first estimate the size of the mapping file >>>>>> and >>>>>> then use this to determine how many entries to read; but when >>>>>> reading, this >>>>>> information may already be stale. I think it would be more robust and >>>>>> also >>>>>> simpler to just try to read as many entries as possible - in >>>>>> chunks, to >>>>>> make reading faster - until you get EOF. >>>>>> >>>>>> Kind Regards, Thomas >>>>>> >>>>> I'm really sure that we've been down this road before. In particular, >>>>> Dmitry Samersoff has worked on this issue (or one very much like it) >>>>> before, but he is on vacation until the end of the month. >>>>> >>>>> There was a similar issue with Linux /proc/self/maps, and whether it >>>> was >>>> safe to read the file with buffered stdio or not. See 8009062 and >>>> 7017193. >>>> >>>> dl >>>> >>>> Dan >>>>> >>>>> >>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review the code changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 . >>>>>>> >>>>>>> >>>>>>> >>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ >>>>>>> >>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug Brief: >>>>>>> >>>>>>> While investigating bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483 >>>>>>> it has been observed that "check_addr0() " function is not written >>>>>>> efficiently. >>>>>>> >>>>>>> This function is trying to read each "prmap_t" entry in >>>>>>> "/proc/self/map" >>>>>>> file one by one which is time taking and can cause in long pauses. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Solution proposed: >>>>>>> >>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file >>>>>>> one by >>>>>>> one, read the entries in chunks. There can be many entries in "map" >>>>>>> file, >>>>>>> so I have decided to read these >>>>>>> >>>>>>> in chunks of 100 "prmap_t" entries. Reading entries in chunks saves >>>>>>> a lot >>>>>>> of read calls and results in smaller pause times. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Cheleswer >>>>>>> >>>>>>> >>> >> From fairoz.matte at oracle.com Wed Mar 9 11:33:36 2016 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Wed, 9 Mar 2016 03:33:36 -0800 (PST) Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) Message-ID: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> Background: After the backport of https://bugs.openjdk.java.net/browse/JDK-8017462, The flag -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers to null in 8u. As there is no condition to handle such scenario in share/vm/memory/sharedHeap.cpp, which causes the crash. The similar condition is already implemented for following scenarios 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 Fix: Condition check is added in src/share/vm/runtime/arguments.cpp file to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" Thanks for the base patch from Jon. Due to this patch it makes some of the test cases absolute. They have been removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ Tests: JPRT: HYPERLINK "http://scaaa637.us.oracle.com/archive/2016/03/2016-03-09-082041.fmatte.jdk8u-dev/JobStatus.txt"http://scaaa637.us.oracle.com//archive/2016/03/2016-03-09-082041.fmatte.jdk8u-dev//JobStatus.txt JTREG - No issues found From cheleswer.sahu at oracle.com Wed Mar 9 12:19:31 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Wed, 9 Mar 2016 04:19:31 -0800 (PST) Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient In-Reply-To: References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default> <56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com> <2fecd625-4723-4fbe-b148-36f7bb654df6@default> <56DD52F8.8070208@oracle.com> <56DD59A2.1030804@oracle.com> <56DD64B2.4010901@oracle.com> Message-ID: <7f870af4-0d4a-4645-981b-97bae67abfaf@default> Hi Thomas, ? Thanks for identifying the issue. I will file a new bug for this and correct the issue. ? ? Regards, Cheleswer ? ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Wednesday, March 09, 2016 4:44 PM To: David Holmes Cc: Kevin Walls; Cheleswer Sahu; Daniel Daugherty; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient ? Hi all, ? I see the change is already pushed, but I am not sure this works as intended: ? We iterate now over all fully read items: + ? ? ?p = (prmap_t *)mbuff; + ? ? ?for(int i = 0; i < nmap; i++){ + ? ? ? ?if (p->pr_vaddr == 0x0) { + ? .... + ? ? ? ?} + ? ? ? ?p = (prmap_t *)(mbuff + sizeof(prmap_t)); + ? ? ?} ? Where do we move the pointer forward? The way I see it, we only ever examine the first and the second item, then repeat examining the second item over and over again. ? Instead of? ? + ? ? ? ?p = (prmap_t *)(mbuff + sizeof(prmap_t)); ? Should this not be ? p = ((prmap_t *)mbuff) + i; ? or just ? p++; ? ? ? Kind Regards, Thomas ? ? ? ? ? ? On Mon, Mar 7, 2016 at 12:23 PM, David Holmes wrote: On 7/03/2016 8:36 PM, Kevin Walls wrote: Hi Cheleswer, Looks good.? (While we've discussed it offline I haven't actually offered a public review). Just one more thing, and this concerns the original code not the change: 1880? ? ? ? ? ?st->print("Warning: Address: 0x%x, Size: %dK, ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname); Also %x is the wrong format specifier: typedef struct prmap { ? ? ? ? uintptr_t pr_vaddr;? ? ?/* virtual address of mapping */ David ----- ? We pass 3 params when we only print two items?? The "p->pr_mapname", we pass again on the next line where we do have the the "%s" in the format string, so this one is unnecessary. 8-) Thanks Kevin On 07/03/2016 10:07, Dmitry Samersoff wrote: Cheleswer, Looks good for me. -Dmitry On 2016-03-03 19:28, Cheleswer Sahu wrote: Hi, Please review the new code changes for this bug. I have removed? " fstat()"? call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/ Regards, Cheleswer -----Original Message----- From: Dean Long Sent: Wednesday, February 24, 2016 7:44 AM To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote: On 2/23/16 5:56 AM, Thomas St?fe wrote: Hi Cheleswer, On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu ? ?wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8146683 . Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 Bug Brief: While investigating? bug https://bugs.openjdk.java.net/browse/JDK-8144483 it has been observed that "check_addr0() " function? is not written efficiently. This function is trying to read each "prmap_t" entry in "/proc/self/map" file one by one which is time taking and can cause in long pauses. Solution proposed: Instead of reading each "prmap_t" entry in "/proc/self/map" file one by one, read the entries in chunks. There can be many entries in "map" file, so I have decided to read these in chunks of 100? "prmap_t" entries. Reading entries in chunks saves a lot of read calls and results in smaller pause times. Regards, Cheleswer We saw cases, especially on Solaris, where the content of a file in the proc file system changed under us while we were reading it. So this should be kept in mind. The original code seems also broken in that regard, because it assumes the ::read() call to read the full size of a prmap_t entry, but it may theoretically read an incomplete entry. As for your coding, you first estimate the size of the mapping file and then use this to determine how many entries to read; but when reading, this information may already be stale. I think it would be more robust and also simpler to just try to read as many entries as possible - in chunks, to make reading faster - until you get EOF. Kind Regards, Thomas I'm really sure that we've been down this road before. In particular, Dmitry Samersoff has worked on this issue (or one very much like it) before, but he is on vacation until the end of the month. There was a similar issue with Linux /proc/self/maps, and whether it was safe to read the file with buffered stdio or not.? See 8009062 and 7017193. dl Dan On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8146683 . Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 Bug Brief: While investigating? bug https://bugs.openjdk.java.net/browse/JDK-8144483 it has been observed that "check_addr0() " function? is not written efficiently. This function is trying to read each "prmap_t" entry in "/proc/self/map" file one by one which is time taking and can cause in long pauses. Solution proposed: Instead of reading each "prmap_t" entry in "/proc/self/map" file one by one, read the entries in chunks. There can be many entries in "map" file, so I have decided to read these in chunks of 100? "prmap_t" entries. Reading entries in chunks saves a lot of read calls and results in smaller pause times. Regards, Cheleswer ? ? ? From thomas.stuefe at gmail.com Wed Mar 9 16:58:45 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 Mar 2016 17:58:45 +0100 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56DF4BAD.1040109@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> Message-ID: Hi all, please take a look at this next version of the fix. http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ I am the first to admit that this is quite ugly :(, but it is a pragmatic solution. Some details: - I added os::strerror() as a drop-in replacement for ::strerror() - it returns the text as before, but does not localize and does not handle unknown error values; so it can be implemented using a simple static string table and is always safe to use. - I added os::errno_name() for those cases where one would want the literalized errno value (e.g. "EINVAL") instead of the full text. - I fixed all callsites in the hotspot which used ::strerror to use os::strerror, or, in some few cases (mostly my own coding for AIX), os::errno_name(). - To avoid including os.hpp in debug.hpp, I moved the implemntation of assert_status to debug.cpp Kind Regards, Thomas On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > This latest version seems okay (or at least better than the other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > >> Hi Thomas, >> >> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> On Mon, Feb 29, 2016 at 4:44 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> On 27/02/2016 2:05 AM, Thomas St?fe wrote: >>> >>> Hi, >>> >>> please take a look at this proposed fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148425 >>> Webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >>> >>> This adds a replacement function os::strerror() as a drop-in for >>> strerror(), which has a number of issues. >>> >>> strerror() is unsafe to use and may cause (and has caused) >>> crashes in >>> multithreaded scenarios. It is also not ideal for log files >>> because of the >>> implicit localization of the error messages. >>> >>> For details please see the discussion under the bug report. >>> >>> >>> I just came across strerror_l, which is required to be thread-safe. >>> Is that a possible alternative? (I'm not sure how locale's are >>> obtained). >>> >>> >>> Sorry, I think this API is glibc only. At least I cannot find this in >>> our AIX headers, nor on Solaris. >>> >> >> It is a POSIX API: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >> >> added in 2006 but part of POSIX.1-2008. But as per Dalibor's link not >> necessarily available: >> >> "This function is missing on some platforms: glibc 2.3.6, Mac OS X 10.5, >> FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX >> 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, mingw, MSVC 9, Interix 3.5, >> BeOS. " >> >> Pity. >> >> >> Otherwise what you have seems okay - though I do dislike having to >>> duplicate all that details already buried in the system >>> headers/library. Not sure we need to the long text at the VM level - >>> which would simplify things a bit. >>> >>> >>> I agree, I dislike this too. Like everyone else in this thread. But I >>> think this is a pragmatic solution. >>> >>> I am a bit stuck here - should we really get rid of the long text >>> feature? There are some callsites of strerror() in the hotspot where >>> arguably the long text is better suited: >>> - in assert_status() (see debug.hpp) - this ends up in the header of >>> error files, if this suddenly changes to a literalized errno, people may >>> be upset >>> >> >> I added assert_status purely to expand on what the failing status was :) >> I'm happy to see EINVAL in that context rather than "invalid argument" (or >> whatever) :) >> >> - when failing to write a heap dump file - see services/heapDumper.cpp. >>> Which ends as printout on the command line, I think. >>> >> >> Maybe ... if it is an error the user can fix. >> >> The safe option would be to provide both variants (short and long text). >>> Or, provide the safe, short variant for all logging calls - when >>> "EINVAL" is enough, and let users continue to use strerror() for those >>> few cases where the long text is needed. >>> >>> What do you think? >>> >> >> Trying to decide what makes me least unhappy. :) Given you've already >> done the work I guess having long and short forms is okay. >> >> Thanks, >> David >> >> Thanks, Thomas >>> >>> Thanks, >>> David >>> >>> >>> Please note that I did not yet change any call sites, although >>> all call >>> sites in the os namespace should already use the new function. I >>> wanted to >>> see whether there would be any general objections. >>> >>> Kind Regards, Thomas >>> >>> >>> > From max.ockner at oracle.com Wed Mar 9 17:10:26 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 09 Mar 2016 12:10:26 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56DF2E4D.6020706@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> Message-ID: <56E05902.6070406@oracle.com> Hello again! webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ - Added "ResourceMark rm(THREAD);" in classFileParser.cpp - Deleted TraceClassLoadingPreorder flag from globals.hpp Thanks, Max On 3/8/2016 2:55 PM, Rachel Protacio wrote: > Hey, Max, > > Looks good. Just a few comments: > > In src/share/vm/classfile/classFileParser.cpp should this have a > ResourceMark rm(THREAD) at 5688? I realize there is probably one > farther up in the scope, but in case someone were to delete it later, > it might make sense to have a more local one? Not sure what the > standard is on this. > > Also I think you forgot to delete the option from runtime/globals.hpp. > > Thanks, > Rachel > > > On 3/8/2016 8:33 AM, Max Ockner wrote: >> Hi, >> >> Please review this small Unified Logging change. >> TraceClassLoadingPreorder has been converted to UL at the Debug >> level. Debug level was chosen since there are 342 lines of output for >> java -version. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >> >> Tested with jtreg runtime tests. >> No existing tests reference TraceClassLoadingPreorder from >> hotspot/test or jdk/test. >> >> Thanks, >> Max > From gerard.ziemski at oracle.com Wed Mar 9 17:33:53 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 9 Mar 2016 11:33:53 -0600 Subject: RFR (M): 8142510: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> Message-ID: <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> hi all, Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) bug https://bugs.openjdk.java.net/browse/JDK-8142510 webrev http://cr.openjdk.java.net/~gziemski/8142510_rev0 tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation cheers From rachel.protacio at oracle.com Wed Mar 9 18:49:27 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 9 Mar 2016 13:49:27 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56D89FDD.40804@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D89FDD.40804@oracle.com> Message-ID: <56E07037.6080801@oracle.com> Looks good to me, Max. And I agree with your decision about the level. Rachel On 3/3/2016 3:34 PM, Max Ockner wrote: > Thanks for the additional feedback. > I have set all of the output to the debug level. > webrev: http://cr.openjdk.java.net/~mockner/8146551.04/ > > You can't really infer anything about the verbosity of a Trace* option > from the face that it starts with "Trace", though I agree that it > would make a lot more sense if that were the case... > > I chose to put all of the output on debug after accounting for 2 things; > (1) The output is extremely verbose, even for java -version. > Therefore, all output should be either debug or trace level. > (2) None of the output ever conditioned on Verbose or WizardMode. > Based on the conventions we have been following, the output shouldn't > be on trace level. > > ==> Debug level. > > Thanks, > Max > > On 3/3/2016 4:45 AM, Bengt Rutisson wrote: >> >> Hi Max and Mikael, >> >> On 2016-03-03 10:40, Mikael Gerdin wrote: >>> Hi Max, >>> >>> On 2016-03-01 23:30, Max Ockner wrote: >>>> Hello, >>>> >>>> Please review this small fix which attempts to shorten the output from >>>> -Xlog:classresolve=info to an acceptable length. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>> >>>> Summary: java '-Xlog:classresolve=info -version' used to produce 3,683 >>>> lines of output. This is unacceptably verbose for info level >>>> logging and >>>> most of the output is not useful. >>>> >>>> "java -Xlog:classresolve=info -version" used to produce: >>>> - 3,683 total lines of output. >>>> - 3,121 total lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 1,329 unique lines of output. >>>> - 767 unique lines of output from >>>> ConstantPool::trace_class_resolution(). >>>> - 562 total lines of output from all other sources, all >>>> unique. >>>> >>>> The code in ConstantPool which called >>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>> >>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>> else { resolve the class } >>>> >>>> So if logging was turned on, the class would not be resolved properly, >>>> but it would produce a log entry saying that the class was being >>>> resolved. As a result, the constant pool entry would still contain a >>>> Symbol* the next time this piece of code was reached, and it would >>>> produce yet another classresolve log entry. In some cases, this was >>>> producing many consecutive identical log entries, taking up full pages >>>> at worst, and averaging a little over 4 duplicates per message. Not >>>> cool. >>>> >>>> The above duplication issue has been fixed, and the >>>> ConstantPool::trace_class_resolution output has been moved to the >>>> debug >>>> leve. There are still 562 unique lines of output for "java >>>> -Xlog:classresolve=info -version". There are now 767 additional unique >>>> lines of output when for the "java -Xlog:classresolve=debug >>>> -version" . >>>> This is better than before but still quite a lot. It seems like >>>> all of >>>> the info level output is equally important(or unimportant), as you can >>>> see in the sample below: >>>> >>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>> (super) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.GenericDeclaration (interface) >>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>> (interface) >>>> [0.026s][info][classresolve] java.lang.Class >>>> java.lang.reflect.AnnotatedElement (interface) >>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ClassLoader java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.System java.lang.Object (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>> (super) >>>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>>> (interface) >>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>> (super) >>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>> (super) >>>> >>>> How do you feel about this? Possible solutions include setting all >>>> output to debug level, or removing some of the logging messages. >>> >>> As I stated in the bug my personal opinion is that "info" level >>> logging should be fairly limited in order to make "-Xlog:all" a >>> useful flag to get a reasonable amount of output about what is >>> happening in a JVM. >>> >>> One approach could be to move the most verbose output to >>> classresolve=trace and keep the rest of classresolve output on the >>> debug level. >>> >>> The fact that the flag was called "TraceClassResolution" is in my >>> mind a hint that if it produces large amounts of output then perhaps >>> that output should be logged on the "trace" log level. >> >> +1 for this approach. >> >> I quite agree with Mikael that we should be a bit careful what we log >> at info level. >> >> Thanks, >> Bengt >> >>> >>> /Mikael >>> >>>> >>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>> modified to check for the new output. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> > From harold.seigel at oracle.com Wed Mar 9 19:35:42 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 9 Mar 2016 14:35:42 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56D77F55.9010801@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> Message-ID: <56E07B0E.3010002@oracle.com> Hi Coleen, The JVM changes look good. Could you add a test or test case for the new 'stacktrace' logging tag? Thanks, Harold On 3/2/2016 7:03 PM, Coleen Phillimore wrote: > Freshly tested changes with jck tests, with missing checks and other > changes to use the depth field, as pointed out by Aleksey. I've kept > the StackTraceElement[] allocation in Java to match the new API that > was approved. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ > > Thanks, > Coleen > > On 3/2/16 2:57 PM, Coleen Phillimore wrote: >> >> >> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>> Hi Coleen, >>> >>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>> with JVM_GetStackTraceElements that gets all the elements in the >>>> StackTraceElement[] >>>> >>>> These improvements were found during the investigation for replacing >>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>> BacktraceBuilder to make changing format of backtrace easier. >>>> >>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>> platforms, and jck tests on linux x64. Compatibility request is >>>> approved. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>> Looks interesting! >>> >>> Is there an underlying reason why we can't return the pre-filled >>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>> with? This will avoid leaking StackTraceElement constructor into >>> standard library, *and* allows to make StackTraceElement fields final. >>> Taking stuff back from the standard library is hard, if not impossible, >>> so we better expose as little as possible. >> >> We measured that it's faster to allocate the StackTraceElement array >> in Java and it seems cleaner to the Java guys. >> It came from similar code we've been prototyping for StackFrameInfo. >>> >>> Other minor nits: >>> >>> * Initializing fields to their default values is a code smell in >>> Java: >>> private transient int depth = 0; >> >> ok, not sure what "code smell" means but it doesn't have to be >> initialized like this. It's set in the native code. >>> >>> * Passing a null array to getStackTraceElement probably SEGVs? I >>> don't >>> see the null checks in native parts. >> >> Yes, it would SEGV. I'll add some checks for null and make sure it's >> an array of StackTraceElement. >> >> Thanks, >> Coleen >>> >>> Thanks, >>> -Aleksey >>> >> > From max.ockner at oracle.com Wed Mar 9 20:47:32 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 09 Mar 2016 15:47:32 -0500 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. Message-ID: <56E08BE4.7000904@oracle.com> Hello again, Please review this change. TraceLoaderConstraints has been converted to Unified Logging and can be accessed using '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added to the logging alias table. There are 0 lines of output for java -version, and ~10 lines from LoaderConstraintsTest.java bug: https://bugs.openjdk.java.net/browse/JDK-8149996 webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ Testing: jtreg runtime. Added new test which triggers logging for loaderconstraints by forcing class unloading. No other references to TraceLoaderConstraints found in hotspot/test, jdk/test , or in the noncolo tests. Thanks, Max From coleen.phillimore at oracle.com Wed Mar 9 21:12:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 9 Mar 2016 16:12:19 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E07B0E.3010002@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56E07B0E.3010002@oracle.com> Message-ID: <56E091B3.8040305@oracle.com> Hi Harold, Thank you for the code review! I added a test for the stack trace logging. I also made some other minor changes that you pointed out. I also added a function to find the field offset from a char* which is used by "depth", but that can be used by other things in javaClasses.cpp that need to know field offsets without adding to vmSymbols.hpp. Also, I made the assertion changes discussed with David in this version. Reran some jck tests. open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_hotspot/ open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_jdk/ I didn't change jdk since 02. Thanks, Coleen On 3/9/16 2:35 PM, harold seigel wrote: > Hi Coleen, > > The JVM changes look good. Could you add a test or test case for the > new 'stacktrace' logging tag? > > Thanks, Harold > > On 3/2/2016 7:03 PM, Coleen Phillimore wrote: >> Freshly tested changes with jck tests, with missing checks and other >> changes to use the depth field, as pointed out by Aleksey. I've kept >> the StackTraceElement[] allocation in Java to match the new API that >> was approved. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >> >> Thanks, >> Coleen >> >> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>> >>> >>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>> Hi Coleen, >>>> >>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>> StackTraceElement[] >>>>> >>>>> These improvements were found during the investigation for replacing >>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>> >>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>> approved. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>> Looks interesting! >>>> >>>> Is there an underlying reason why we can't return the pre-filled >>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>> with? This will avoid leaking StackTraceElement constructor into >>>> standard library, *and* allows to make StackTraceElement fields final. >>>> Taking stuff back from the standard library is hard, if not >>>> impossible, >>>> so we better expose as little as possible. >>> >>> We measured that it's faster to allocate the StackTraceElement array >>> in Java and it seems cleaner to the Java guys. >>> It came from similar code we've been prototyping for StackFrameInfo. >>>> >>>> Other minor nits: >>>> >>>> * Initializing fields to their default values is a code smell in >>>> Java: >>>> private transient int depth = 0; >>> >>> ok, not sure what "code smell" means but it doesn't have to be >>> initialized like this. It's set in the native code. >>>> >>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>> don't >>>> see the null checks in native parts. >>> >>> Yes, it would SEGV. I'll add some checks for null and make sure >>> it's an array of StackTraceElement. >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> -Aleksey >>>> >>> >> > From coleen.phillimore at oracle.com Wed Mar 9 21:51:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 9 Mar 2016 16:51:59 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E091B3.8040305@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56E07B0E.3010002@oracle.com> <56E091B3.8040305@oracle.com> Message-ID: <56E09AFF.1000009@oracle.com> On 3/9/16 4:12 PM, Coleen Phillimore wrote: > > Hi Harold, > Thank you for the code review! > > I added a test for the stack trace logging. I also made some other > minor changes that you pointed out. I also added a function to find > the field offset from a char* which is used by "depth", but that can > be used by other things in javaClasses.cpp that need to know field > offsets without adding to vmSymbols.hpp. I reverted this last change because it used CATCH to exit if there's an exception, ie didn't properly handle errors. To pass a name to compute_offset() you need to add the string to vmSymbols.hpp for now. Also hg added the test. Thanks, Coleen > > Also, I made the assertion changes discussed with David in this > version. Reran some jck tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_jdk/ > > I didn't change jdk since 02. > > Thanks, > Coleen > > > On 3/9/16 2:35 PM, harold seigel wrote: >> Hi Coleen, >> >> The JVM changes look good. Could you add a test or test case for the >> new 'stacktrace' logging tag? >> >> Thanks, Harold >> >> On 3/2/2016 7:03 PM, Coleen Phillimore wrote: >>> Freshly tested changes with jck tests, with missing checks and other >>> changes to use the depth field, as pointed out by Aleksey. I've >>> kept the StackTraceElement[] allocation in Java to match the new API >>> that was approved. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >>> >>> Thanks, >>> Coleen >>> >>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>> Hi Coleen, >>>>> >>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>> Summary: replace JVM_GetStackTraceDepth and >>>>>> JVM_GetStackTraceElement, >>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>> StackTraceElement[] >>>>>> >>>>>> These improvements were found during the investigation for replacing >>>>>> Throwable with the StackWalkAPI. This change also adds iterator >>>>>> for >>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>> >>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>> approved. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>> Looks interesting! >>>>> >>>>> Is there an underlying reason why we can't return the pre-filled >>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to >>>>> begin >>>>> with? This will avoid leaking StackTraceElement constructor into >>>>> standard library, *and* allows to make StackTraceElement fields >>>>> final. >>>>> Taking stuff back from the standard library is hard, if not >>>>> impossible, >>>>> so we better expose as little as possible. >>>> >>>> We measured that it's faster to allocate the StackTraceElement >>>> array in Java and it seems cleaner to the Java guys. >>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>> >>>>> Other minor nits: >>>>> >>>>> * Initializing fields to their default values is a code smell in >>>>> Java: >>>>> private transient int depth = 0; >>>> >>>> ok, not sure what "code smell" means but it doesn't have to be >>>> initialized like this. It's set in the native code. >>>>> >>>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>>> don't >>>>> see the null checks in native parts. >>>> >>>> Yes, it would SEGV. I'll add some checks for null and make sure >>>> it's an array of StackTraceElement. >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Mar 9 22:03:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 9 Mar 2016 17:03:21 -0500 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E08BE4.7000904@oracle.com> References: <56E08BE4.7000904@oracle.com> Message-ID: <56E09DA9.4040504@oracle.com> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html Why did you take out the ResourceMarks at line 130, 160, 231 and 244, 297, 308 and 357? Unfortunately, we really need log_info_rm(tag)("String") call because all those places need a ResourceMark. Anytime we call name()->as_C_string() there needs to be a ResourceMark in the scope of the call. Coleen On 3/9/16 3:47 PM, Max Ockner wrote: > Hello again, > > Please review this change. TraceLoaderConstraints has been converted > to Unified Logging and can be accessed using > '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added > to the logging alias table. > > There are 0 lines of output for java -version, and ~10 lines from > LoaderConstraintsTest.java > > bug: https://bugs.openjdk.java.net/browse/JDK-8149996 > webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ > > Testing: jtreg runtime. Added new test which triggers logging for > loaderconstraints by forcing class unloading. No other references to > TraceLoaderConstraints found in hotspot/test, jdk/test , or in the > noncolo tests. > > Thanks, > Max From coleen.phillimore at oracle.com Wed Mar 9 23:58:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 9 Mar 2016 18:58:19 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E05902.6070406@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> Message-ID: <56E0B89B.5070603@oracle.com> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html We talked about this but I've changed my opinion. I think looking at this in the code, it might make more sense to make this log(classload, preorder) since anyone knowing about this option will know to specify both tags. I think it's used for CDS. Will this work for the aliasing table? If not, I think the tag is better classloadpreorder http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html The comment is wrong, it says classloaderpreorder, rather than classloadingpreorder. thanks, Coleen On 3/9/16 12:10 PM, Max Ockner wrote: > Hello again! > > webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ > - Added "ResourceMark rm(THREAD);" in classFileParser.cpp > - Deleted TraceClassLoadingPreorder flag from globals.hpp > > Thanks, > Max > > On 3/8/2016 2:55 PM, Rachel Protacio wrote: >> Hey, Max, >> >> Looks good. Just a few comments: >> >> In src/share/vm/classfile/classFileParser.cpp should this have a >> ResourceMark rm(THREAD) at 5688? I realize there is probably one >> farther up in the scope, but in case someone were to delete it later, >> it might make sense to have a more local one? Not sure what the >> standard is on this. >> >> Also I think you forgot to delete the option from runtime/globals.hpp. >> >> Thanks, >> Rachel >> >> >> On 3/8/2016 8:33 AM, Max Ockner wrote: >>> Hi, >>> >>> Please review this small Unified Logging change. >>> TraceClassLoadingPreorder has been converted to UL at the Debug >>> level. Debug level was chosen since there are 342 lines of output >>> for java -version. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>> >>> Tested with jtreg runtime tests. >>> No existing tests reference TraceClassLoadingPreorder from >>> hotspot/test or jdk/test. >>> >>> Thanks, >>> Max >> > From david.holmes at oracle.com Thu Mar 10 04:29:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Mar 2016 14:29:42 +1000 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E09DA9.4040504@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> Message-ID: <56E0F836.70301@oracle.com> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html > > > Why did you take out the ResourceMarks at line 130, 160, 231 and 244, > 297, 308 and 357? Yes these should all be of the form: if (log_is_enabled(...)) { ResourceMark rm; // log stuff } > Unfortunately, we really need log_info_rm(tag)("String") call because > all those places need a ResourceMark. > > Anytime we call name()->as_C_string() there needs to be a ResourceMark > in the scope of the call. Which means that a log_info_rm() call wouldn't help because we'd still be calling as_C_string in the caller. :( David > > Coleen > > On 3/9/16 3:47 PM, Max Ockner wrote: >> Hello again, >> >> Please review this change. TraceLoaderConstraints has been converted >> to Unified Logging and can be accessed using >> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added >> to the logging alias table. >> >> There are 0 lines of output for java -version, and ~10 lines from >> LoaderConstraintsTest.java >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >> >> Testing: jtreg runtime. Added new test which triggers logging for >> loaderconstraints by forcing class unloading. No other references to >> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >> noncolo tests. >> >> Thanks, >> Max > From david.holmes at oracle.com Thu Mar 10 04:53:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Mar 2016 14:53:39 +1000 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> Message-ID: <56E0FDD3.6020501@oracle.com> On 9/03/2016 9:33 PM, Fairoz Matte wrote: > Background: > > After the backport of https://bugs.openjdk.java.net/browse/JDK-8017462, The flag -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers to null in 8u. > > As there is no condition to handle such scenario in share/vm/memory/sharedHeap.cpp, which causes the crash. > > The similar condition is already implemented for following scenarios > > 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 > > 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 > > 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 > > > > Fix: > > Condition check is added in src/share/vm/runtime/arguments.cpp file to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" > > Thanks for the base patch from Jon. > > Due to this patch it makes some of the test cases absolute. They have been removed. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 > > Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ This existing code looks wrong: 1675 FLAG_SET_DEFAULT(ParallelGCThreads, 1676 Abstract_VM_Version::parallel_worker_threads()); 1677 if (ParallelGCThreads == 0) { 1678 FLAG_SET_DEFAULT(ParallelGCThreads, 1679 Abstract_VM_Version::parallel_worker_threads()); Line 1678 seems to do the same as 1675 - is Abstract_VM_Version::parallel_worker_threads() somehow expected to return a different value on the second call ?? That aside I'm confused by the fix as we have: ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, so it seems odd to report an error for setting a value that is already the default ?? Thanks, David From david.holmes at oracle.com Thu Mar 10 05:41:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Mar 2016 15:41:06 +1000 Subject: RFR(xs): 8151265: Add a way to extend UL tags In-Reply-To: <56DFE05C.8030609@oracle.com> References: <56DFE05C.8030609@oracle.com> Message-ID: <56E108F2.1030903@oracle.com> Hi Robbin, On 9/03/2016 6:35 PM, Robbin Ehn wrote: > Hi, please review this small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151265/ > Webrev: http://cr.openjdk.java.net/~rehn/8151265/webrev/ > > This adds an extension hpp with macro for extension tags. Looks okay to me. Thanks, David > Thanks! > > /Robbin From robbin.ehn at oracle.com Thu Mar 10 05:57:09 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 10 Mar 2016 06:57:09 +0100 Subject: RFR(xs): 8151265: Add a way to extend UL tags In-Reply-To: <56E108F2.1030903@oracle.com> References: <56DFE05C.8030609@oracle.com> <56E108F2.1030903@oracle.com> Message-ID: <56E10CB5.30405@oracle.com> Thanks David! /Robbin On 03/10/2016 06:41 AM, David Holmes wrote: > Hi Robbin, > > On 9/03/2016 6:35 PM, Robbin Ehn wrote: >> Hi, please review this small change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151265/ >> Webrev: http://cr.openjdk.java.net/~rehn/8151265/webrev/ >> >> This adds an extension hpp with macro for extension tags. > > Looks okay to me. > > Thanks, > David > >> Thanks! >> >> /Robbin From kim.barrett at oracle.com Thu Mar 10 08:26:47 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Mar 2016 03:26:47 -0500 Subject: RFR(xs): 8151265: Add a way to extend UL tags In-Reply-To: <56DFE05C.8030609@oracle.com> References: <56DFE05C.8030609@oracle.com> Message-ID: <192B8441-A4A5-441B-ADAF-D24655A32AF6@oracle.com> > On Mar 9, 2016, at 3:35 AM, Robbin Ehn wrote: > > Hi, please review this small change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151265/ > Webrev: http://cr.openjdk.java.net/~rehn/8151265/webrev/ > > This adds an extension hpp with macro for extension tags. > > Thanks! > > /Robbin Looks good. From fairoz.matte at oracle.com Thu Mar 10 08:35:00 2016 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 10 Mar 2016 00:35:00 -0800 (PST) Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E0FDD3.6020501@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> Message-ID: Hi David, That was existing code. The patch contains only 3 line change. FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); if (ParallelGCThreads == 0) { FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); + if (ParallelGCThreads == 0) { + vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); } + } Let me cross check and remove the unnecessary existing code. Thanks, Fairoz -----Original Message----- From: David Holmes Sent: Thursday, March 10, 2016 10:24 AM To: Fairoz Matte; hotspot-runtime-dev at openjdk.java.net Cc: Jon Masamitsu Subject: Re: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) On 9/03/2016 9:33 PM, Fairoz Matte wrote: > Background: > > After the backport of https://bugs.openjdk.java.net/browse/JDK-8017462, The flag -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers to null in 8u. > > As there is no condition to handle such scenario in share/vm/memory/sharedHeap.cpp, which causes the crash. > > The similar condition is already implemented for following scenarios > > 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 > > 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 > > 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 > > > > Fix: > > Condition check is added in src/share/vm/runtime/arguments.cpp file to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" > > Thanks for the base patch from Jon. > > Due to this patch it makes some of the test cases absolute. They have been removed. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 > > Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ This existing code looks wrong: 1675 FLAG_SET_DEFAULT(ParallelGCThreads, 1676 Abstract_VM_Version::parallel_worker_threads()); 1677 if (ParallelGCThreads == 0) { 1678 FLAG_SET_DEFAULT(ParallelGCThreads, 1679 Abstract_VM_Version::parallel_worker_threads()); Line 1678 seems to do the same as 1675 - is Abstract_VM_Version::parallel_worker_threads() somehow expected to return a different value on the second call ?? That aside I'm confused by the fix as we have: ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, so it seems odd to report an error for setting a value that is already the default ?? Thanks, David From robbin.ehn at oracle.com Thu Mar 10 09:38:10 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 10 Mar 2016 10:38:10 +0100 Subject: RFR(xs): 8151265: Add a way to extend UL tags In-Reply-To: <192B8441-A4A5-441B-ADAF-D24655A32AF6@oracle.com> References: <56DFE05C.8030609@oracle.com> <192B8441-A4A5-441B-ADAF-D24655A32AF6@oracle.com> Message-ID: <56E14082.1040600@oracle.com> Thanks Kim! /Robbin On 03/10/2016 09:26 AM, Kim Barrett wrote: >> On Mar 9, 2016, at 3:35 AM, Robbin Ehn wrote: >> >> Hi, please review this small change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151265/ >> Webrev: http://cr.openjdk.java.net/~rehn/8151265/webrev/ >> >> This adds an extension hpp with macro for extension tags. >> >> Thanks! >> >> /Robbin > > Looks good. > From david.holmes at oracle.com Thu Mar 10 10:19:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Mar 2016 20:19:28 +1000 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56DFE68E.3070506@oracle.com> References: <56DFE68E.3070506@oracle.com> Message-ID: <56E14A30.4000601@oracle.com> Hi Robbin, On 9/03/2016 7:02 PM, Robbin Ehn wrote: > > Hi, please review this minor change. A notification mechanism is not so minor - what are the programming rules for the callbacks? which threads might execute them? Are there any obvious deadlock/livelock potentials? Do we need to unregister a callback? At a minimum there should be some comments regarding the nature of the callback and what it can and can't do. > Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ > Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ Some minor nits: src/share/vm/logging/log.cpp Copyright needs 2016 added. --- src/share/vm/logging/logConfiguration.cpp + assert(cb != NULL, "Should not initialize register NULL as listener."); "initialize register" doesn't make grammatical sense - delete "initialize" + for (size_t i=0;i<_n_listener_callbacks;i++) { Style nits: spaces around operators and after ; --- src/share/vm/logging/logConfiguration.hpp + // After any configuration change this method should be called by in scope of LogConfigurationLock Delete 'by' - or may I suggest: // This should be called after any configuration change while still holding ConfigurationLock Thanks, David ----- > Tested with a new internal vm test (included). > > Thanks! > > /Robbin From robbin.ehn at oracle.com Thu Mar 10 10:38:58 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 10 Mar 2016 11:38:58 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E14A30.4000601@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> Message-ID: <56E14EC2.6010204@oracle.com> Thanks David for looking at this. On 03/10/2016 11:19 AM, David Holmes wrote: > Hi Robbin, > > On 9/03/2016 7:02 PM, Robbin Ehn wrote: >> >> Hi, please review this minor change. > > A notification mechanism is not so minor - what are the programming > rules for the callbacks? which threads might execute them? Are there any > obvious deadlock/livelock potentials? Do we need to unregister a callback? > > At a minimum there should be some comments regarding the nature of the > callback and what it can and can't do. Yes, I will document it better. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ > > Some minor nits: > > src/share/vm/logging/log.cpp > > Copyright needs 2016 added. > > --- > > src/share/vm/logging/logConfiguration.cpp > > + assert(cb != NULL, "Should not initialize register NULL as listener."); > > "initialize register" doesn't make grammatical sense - delete "initialize" > > + for (size_t i=0;i<_n_listener_callbacks;i++) { > > Style nits: spaces around operators and after ; > > --- > > src/share/vm/logging/logConfiguration.hpp > > + // After any configuration change this method should be called by in > scope of LogConfigurationLock > > Delete 'by' - or may I suggest: > > // This should be called after any configuration change while still > holding ConfigurationLock > Yes, thanks! /Robbin > Thanks, > David > ----- > >> Tested with a new internal vm test (included). >> >> Thanks! >> >> /Robbin From cheleswer.sahu at oracle.com Thu Mar 10 10:43:57 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 10 Mar 2016 02:43:57 -0800 (PST) Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly Message-ID: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ Bug Brief: In check_addr0(), pointer "p" is not updated correctly, because of this it was reading only first two entries from buffer. Regards, Cheleswer From dmitry.dmitriev at oracle.com Thu Mar 10 12:45:57 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 10 Mar 2016 15:45:57 +0300 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: Message-ID: <56E16C85.30102@oracle.com> Hi Cheleswer, Looks good, but I have questions/comments about other code in this function: 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". 2) Just interesting, do you really need to set memory to 0 by memset? Thanks, Dmitry On 10.03.2016 13:43, Cheleswer Sahu wrote: > > Hi, > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ > > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of > this it was reading only first two entries from buffer. > > Regards, > > Cheleswer > From thomas.stuefe at gmail.com Thu Mar 10 14:07:18 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Mar 2016 15:07:18 +0100 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <56E16C85.30102@oracle.com> References: <56E16C85.30102@oracle.com> Message-ID: Hi Cheleswer, thanks for fixing this. Some more issues: - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024); Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. (But I know this coding was there before) Beside those points, I think both points of Dmitry are valid. Also, I find Kind Regards, Thomas On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this > function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > >> >> Hi, >> >> Please review the code changes for >> https://bugs.openjdk.java.net/browse/JDK-8151509. >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ < >> http://cr.openjdk.java.net/%7Ecsahu/8151509/> >> >> Bug Brief: >> >> In check_addr0(), pointer ?p? is not updated correctly, because of this >> it was reading only first two entries from buffer. >> >> Regards, >> >> Cheleswer >> >> > From thomas.stuefe at gmail.com Thu Mar 10 14:09:04 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Mar 2016 15:09:04 +0100 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: <56E16C85.30102@oracle.com> Message-ID: (Sorry, pressed Send button too early) Just wanted to add that 1873 if( 0 != ret % sizeof(prmap_t)){ 1874 break; 1875 } may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. Kind Regards, Thomas On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: > Hi Cheleswer, > > thanks for fixing this. > > Some more issues: > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes > larger than necessary. > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. > Theoretical truncation for mappings larger than 4g*1024. > (But I know this coding was there before) > > Beside those points, I think both points of Dmitry are valid. > > Also, I find > > > Kind Regards, Thomas > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev < > dmitry.dmitriev at oracle.com> wrote: > >> Hi Cheleswer, >> >> Looks good, but I have questions/comments about other code in this >> function: >> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". >> 2) Just interesting, do you really need to set memory to 0 by memset? >> >> Thanks, >> Dmitry >> >> >> On 10.03.2016 13:43, Cheleswer Sahu wrote: >> >>> >>> Hi, >>> >>> Please review the code changes for >>> https://bugs.openjdk.java.net/browse/JDK-8151509. >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ < >>> http://cr.openjdk.java.net/%7Ecsahu/8151509/> >>> >>> Bug Brief: >>> >>> In check_addr0(), pointer ?p? is not updated correctly, because of this >>> it was reading only first two entries from buffer. >>> >>> Regards, >>> >>> Cheleswer >>> >>> >> > From max.ockner at oracle.com Thu Mar 10 14:54:11 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 10 Mar 2016 09:54:11 -0500 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56E07037.6080801@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D89FDD.40804@oracle.com> <56E07037.6080801@oracle.com> Message-ID: <56E18A93.3030707@oracle.com> Hello, Thanks to everyone for their ideas and help. If there are no more concerns, I would like to submit this. Thanks, Max On 3/9/2016 1:49 PM, Rachel Protacio wrote: > Looks good to me, Max. And I agree with your decision about the level. > > Rachel > > On 3/3/2016 3:34 PM, Max Ockner wrote: >> Thanks for the additional feedback. >> I have set all of the output to the debug level. >> webrev: http://cr.openjdk.java.net/~mockner/8146551.04/ >> >> You can't really infer anything about the verbosity of a Trace* >> option from the face that it starts with "Trace", though I agree that >> it would make a lot more sense if that were the case... >> >> I chose to put all of the output on debug after accounting for 2 things; >> (1) The output is extremely verbose, even for java -version. >> Therefore, all output should be either debug or trace level. >> (2) None of the output ever conditioned on Verbose or WizardMode. >> Based on the conventions we have been following, the output shouldn't >> be on trace level. >> >> ==> Debug level. >> >> Thanks, >> Max >> >> On 3/3/2016 4:45 AM, Bengt Rutisson wrote: >>> >>> Hi Max and Mikael, >>> >>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>> Hi Max, >>>> >>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix which attempts to shorten the output >>>>> from >>>>> -Xlog:classresolve=info to an acceptable length. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>> >>>>> Summary: java '-Xlog:classresolve=info -version' used to produce >>>>> 3,683 >>>>> lines of output. This is unacceptably verbose for info level >>>>> logging and >>>>> most of the output is not useful. >>>>> >>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>> - 3,683 total lines of output. >>>>> - 3,121 total lines of output from >>>>> ConstantPool::trace_class_resolution(). >>>>> - 1,329 unique lines of output. >>>>> - 767 unique lines of output from >>>>> ConstantPool::trace_class_resolution(). >>>>> - 562 total lines of output from all other sources, all >>>>> unique. >>>>> >>>>> The code in ConstantPool which called >>>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>>> >>>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>>> else { resolve the class } >>>>> >>>>> So if logging was turned on, the class would not be resolved >>>>> properly, >>>>> but it would produce a log entry saying that the class was being >>>>> resolved. As a result, the constant pool entry would still contain a >>>>> Symbol* the next time this piece of code was reached, and it would >>>>> produce yet another classresolve log entry. In some cases, this was >>>>> producing many consecutive identical log entries, taking up full >>>>> pages >>>>> at worst, and averaging a little over 4 duplicates per message. >>>>> Not cool. >>>>> >>>>> The above duplication issue has been fixed, and the >>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>> debug >>>>> leve. There are still 562 unique lines of output for "java >>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>> unique >>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>> -version" . >>>>> This is better than before but still quite a lot. It seems like >>>>> all of >>>>> the info level output is equally important(or unimportant), as you >>>>> can >>>>> see in the sample below: >>>>> >>>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>>> (super) >>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object (super) >>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>> (interface) >>>>> [0.026s][info][classresolve] java.lang.Class >>>>> java.lang.reflect.GenericDeclaration (interface) >>>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>>> (interface) >>>>> [0.026s][info][classresolve] java.lang.Class >>>>> java.lang.reflect.AnnotatedElement (interface) >>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.ClassLoader >>>>> java.lang.Object (super) >>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.Throwable java.io.Serializable >>>>> (interface) >>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>> (super) >>>>> [0.027s][info][classresolve] java.lang.ThreadDeath java.lang.Error >>>>> (super) >>>>> >>>>> How do you feel about this? Possible solutions include setting all >>>>> output to debug level, or removing some of the logging messages. >>>> >>>> As I stated in the bug my personal opinion is that "info" level >>>> logging should be fairly limited in order to make "-Xlog:all" a >>>> useful flag to get a reasonable amount of output about what is >>>> happening in a JVM. >>>> >>>> One approach could be to move the most verbose output to >>>> classresolve=trace and keep the rest of classresolve output on the >>>> debug level. >>>> >>>> The fact that the flag was called "TraceClassResolution" is in my >>>> mind a hint that if it produces large amounts of output then >>>> perhaps that output should be logged on the "trace" log level. >>> >>> +1 for this approach. >>> >>> I quite agree with Mikael that we should be a bit careful what we >>> log at info level. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> /Mikael >>>> >>>>> >>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>> modified to check for the new output. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>> >> > From harold.seigel at oracle.com Thu Mar 10 14:56:42 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 10 Mar 2016 09:56:42 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E09AFF.1000009@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56E07B0E.3010002@oracle.com> <56E091B3.8040305@oracle.com> <56E09AFF.1000009@oracle.com> Message-ID: <56E18B2A.7010401@oracle.com> Hi Coleen, The changes look good. Thanks for adding the new test. Harold On 3/9/2016 4:51 PM, Coleen Phillimore wrote: > > > On 3/9/16 4:12 PM, Coleen Phillimore wrote: >> >> Hi Harold, >> Thank you for the code review! >> >> I added a test for the stack trace logging. I also made some other >> minor changes that you pointed out. I also added a function to find >> the field offset from a char* which is used by "depth", but that can >> be used by other things in javaClasses.cpp that need to know field >> offsets without adding to vmSymbols.hpp. > > I reverted this last change because it used CATCH to exit if there's > an exception, ie didn't properly handle errors. To pass a name to > compute_offset() you need to add the string to vmSymbols.hpp for now. > > Also hg added the test. > > Thanks, > Coleen >> >> Also, I made the assertion changes discussed with David in this >> version. Reran some jck tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_hotspot/ >> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_jdk/ >> >> I didn't change jdk since 02. >> >> Thanks, >> Coleen >> >> >> On 3/9/16 2:35 PM, harold seigel wrote: >>> Hi Coleen, >>> >>> The JVM changes look good. Could you add a test or test case for >>> the new 'stacktrace' logging tag? >>> >>> Thanks, Harold >>> >>> On 3/2/2016 7:03 PM, Coleen Phillimore wrote: >>>> Freshly tested changes with jck tests, with missing checks and >>>> other changes to use the depth field, as pointed out by Aleksey. >>>> I've kept the StackTraceElement[] allocation in Java to match the >>>> new API that was approved. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>>> Summary: replace JVM_GetStackTraceDepth and >>>>>>> JVM_GetStackTraceElement, >>>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>>> StackTraceElement[] >>>>>>> >>>>>>> These improvements were found during the investigation for >>>>>>> replacing >>>>>>> Throwable with the StackWalkAPI. This change also adds >>>>>>> iterator for >>>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>>> >>>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>>> approved. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>>> Looks interesting! >>>>>> >>>>>> Is there an underlying reason why we can't return the pre-filled >>>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to >>>>>> begin >>>>>> with? This will avoid leaking StackTraceElement constructor into >>>>>> standard library, *and* allows to make StackTraceElement fields >>>>>> final. >>>>>> Taking stuff back from the standard library is hard, if not >>>>>> impossible, >>>>>> so we better expose as little as possible. >>>>> >>>>> We measured that it's faster to allocate the StackTraceElement >>>>> array in Java and it seems cleaner to the Java guys. >>>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>>> >>>>>> Other minor nits: >>>>>> >>>>>> * Initializing fields to their default values is a code smell >>>>>> in Java: >>>>>> private transient int depth = 0; >>>>> >>>>> ok, not sure what "code smell" means but it doesn't have to be >>>>> initialized like this. It's set in the native code. >>>>>> >>>>>> * Passing a null array to getStackTraceElement probably SEGVs? >>>>>> I don't >>>>>> see the null checks in native parts. >>>>> >>>>> Yes, it would SEGV. I'll add some checks for null and make sure >>>>> it's an array of StackTraceElement. >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> -Aleksey >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Mar 10 15:40:52 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Mar 2016 10:40:52 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E18B2A.7010401@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56E07B0E.3010002@oracle.com> <56E091B3.8040305@oracle.com> <56E09AFF.1000009@oracle.com> <56E18B2A.7010401@oracle.com> Message-ID: <56E19584.8080808@oracle.com> Thank you, Harold! Coleen On 3/10/16 9:56 AM, harold seigel wrote: > Hi Coleen, > > The changes look good. Thanks for adding the new test. > > Harold > > On 3/9/2016 4:51 PM, Coleen Phillimore wrote: >> >> >> On 3/9/16 4:12 PM, Coleen Phillimore wrote: >>> >>> Hi Harold, >>> Thank you for the code review! >>> >>> I added a test for the stack trace logging. I also made some other >>> minor changes that you pointed out. I also added a function to find >>> the field offset from a char* which is used by "depth", but that can >>> be used by other things in javaClasses.cpp that need to know field >>> offsets without adding to vmSymbols.hpp. >> >> I reverted this last change because it used CATCH to exit if there's >> an exception, ie didn't properly handle errors. To pass a name to >> compute_offset() you need to add the string to vmSymbols.hpp for now. >> >> Also hg added the test. >> >> Thanks, >> Coleen >>> >>> Also, I made the assertion changes discussed with David in this >>> version. Reran some jck tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_hotspot/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_jdk/ >>> >>> I didn't change jdk since 02. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 3/9/16 2:35 PM, harold seigel wrote: >>>> Hi Coleen, >>>> >>>> The JVM changes look good. Could you add a test or test case for >>>> the new 'stacktrace' logging tag? >>>> >>>> Thanks, Harold >>>> >>>> On 3/2/2016 7:03 PM, Coleen Phillimore wrote: >>>>> Freshly tested changes with jck tests, with missing checks and >>>>> other changes to use the depth field, as pointed out by Aleksey. >>>>> I've kept the StackTraceElement[] allocation in Java to match the >>>>> new API that was approved. >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>>>> Summary: replace JVM_GetStackTraceDepth and >>>>>>>> JVM_GetStackTraceElement, >>>>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>>>> StackTraceElement[] >>>>>>>> >>>>>>>> These improvements were found during the investigation for >>>>>>>> replacing >>>>>>>> Throwable with the StackWalkAPI. This change also adds >>>>>>>> iterator for >>>>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>>>> >>>>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on >>>>>>>> all >>>>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>>>> approved. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>>>> Looks interesting! >>>>>>> >>>>>>> Is there an underlying reason why we can't return the pre-filled >>>>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to >>>>>>> begin >>>>>>> with? This will avoid leaking StackTraceElement constructor into >>>>>>> standard library, *and* allows to make StackTraceElement fields >>>>>>> final. >>>>>>> Taking stuff back from the standard library is hard, if not >>>>>>> impossible, >>>>>>> so we better expose as little as possible. >>>>>> >>>>>> We measured that it's faster to allocate the StackTraceElement >>>>>> array in Java and it seems cleaner to the Java guys. >>>>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>>>> >>>>>>> Other minor nits: >>>>>>> >>>>>>> * Initializing fields to their default values is a code smell >>>>>>> in Java: >>>>>>> private transient int depth = 0; >>>>>> >>>>>> ok, not sure what "code smell" means but it doesn't have to be >>>>>> initialized like this. It's set in the native code. >>>>>>> >>>>>>> * Passing a null array to getStackTraceElement probably SEGVs? >>>>>>> I don't >>>>>>> see the null checks in native parts. >>>>>> >>>>>> Yes, it would SEGV. I'll add some checks for null and make sure >>>>>> it's an array of StackTraceElement. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> -Aleksey >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.stuefe at gmail.com Thu Mar 10 16:25:04 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Mar 2016 17:25:04 +0100 Subject: UL: logging before initialization? Message-ID: Hi all, I wanted to use UL to log some information from early OS initialization but found that we initialize logging quite late. It is initialized way after os::init() runs. I also see that warnings and errors are printed unconditionally even before, only log calls for levels <= info are quietly swallowed. Would there be a way to move UL initialization and parsing of -Xlog Arguments to an earlier point to be able to use logging in os::init()? Or, if that is not possible, would there be a way to delay printing of early logging calls to after logging initialization and then print them out in one go? I think this would be not trivial though: one would have to collect all logging output in memory somewhere - because we do not yet know which tags are switched on - and then, once -Xlog is parsed, filter it by tag before printing it out. What do you think, would that be a worthwhile change? I am a bit unhappy about how logging calls are quietly swallowed, so for any code which runs at VM initialization, one always has to keep in mind that UL may not yet be initialized. Kind Regards, Thomas From jon.masamitsu at oracle.com Thu Mar 10 17:21:46 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 10 Mar 2016 09:21:46 -0800 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E0FDD3.6020501@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> Message-ID: <56E1AD2A.201@oracle.com> On 03/09/2016 08:53 PM, David Holmes wrote: > On 9/03/2016 9:33 PM, Fairoz Matte wrote: >> Background: >> >> After the backport of >> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers >> to null in 8u. >> >> As there is no condition to handle such scenario in >> share/vm/memory/sharedHeap.cpp, which causes the crash. >> >> The similar condition is already implemented for following scenarios >> >> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >> >> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >> >> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >> >> >> >> Fix: >> >> Condition check is added in src/share/vm/runtime/arguments.cpp file >> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >> >> Thanks for the base patch from Jon. >> >> Due to this patch it makes some of the test cases absolute. They have >> been removed. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ > > This existing code looks wrong: > > 1675 FLAG_SET_DEFAULT(ParallelGCThreads, > 1676 Abstract_VM_Version::parallel_worker_threads()); > 1677 if (ParallelGCThreads == 0) { > 1678 FLAG_SET_DEFAULT(ParallelGCThreads, > 1679 Abstract_VM_Version::parallel_worker_threads()); > > Line 1678 seems to do the same as 1675 - is > Abstract_VM_Version::parallel_worker_threads() somehow expected to > return a different value on the second call ?? No, Abstract_VM_Version::parallel_worker_threads() won't return a different value for a second call. It's harmless but would be cleaner deleting 1675,1676. Jon > > That aside I'm confused by the fix as we have: > > ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, > > so it seems odd to report an error for setting a value that is already > the default ?? > > Thanks, > David From max.ockner at oracle.com Thu Mar 10 18:22:57 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 10 Mar 2016 13:22:57 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E0B89B.5070603@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> Message-ID: <56E1BB81.8000705@oracle.com> Hello, I have responded to these comments. webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ - classloadingpreorder replaced by classload+preorder - In order to support aliasing to a log configuration with multiple tags, the logging alias table is expanded to fit the output of the LOG_TAGS(tag) macro. - comment in metaspaceShared is changed to classload+preorder. Thanks, Max On 3/9/2016 6:58 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html > > > We talked about this but I've changed my opinion. I think looking at > this in the code, it might make more sense to make this log(classload, > preorder) since anyone knowing about this option will know to specify > both tags. I think it's used for CDS. Will this work for the > aliasing table? If not, I think the tag is better classloadpreorder > > http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html > > > The comment is wrong, it says classloaderpreorder, rather than > classloadingpreorder. > > thanks, > Coleen > > On 3/9/16 12:10 PM, Max Ockner wrote: >> Hello again! >> >> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >> - Deleted TraceClassLoadingPreorder flag from globals.hpp >> >> Thanks, >> Max >> >> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>> Hey, Max, >>> >>> Looks good. Just a few comments: >>> >>> In src/share/vm/classfile/classFileParser.cpp should this have a >>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>> farther up in the scope, but in case someone were to delete it >>> later, it might make sense to have a more local one? Not sure what >>> the standard is on this. >>> >>> Also I think you forgot to delete the option from runtime/globals.hpp. >>> >>> Thanks, >>> Rachel >>> >>> >>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>> Hi, >>>> >>>> Please review this small Unified Logging change. >>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>> level. Debug level was chosen since there are 342 lines of output >>>> for java -version. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>> >>>> Tested with jtreg runtime tests. >>>> No existing tests reference TraceClassLoadingPreorder from >>>> hotspot/test or jdk/test. >>>> >>>> Thanks, >>>> Max >>> >> > From coleen.phillimore at oracle.com Thu Mar 10 19:22:55 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Mar 2016 14:22:55 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E1BB81.8000705@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> Message-ID: <56E1C98F.4080305@oracle.com> I think this looks really good with two tags. The alias table handling looks fine to me. I have two minor comments and I don't need to see another webrev. http://cr.openjdk.java.net/~mockner/8149995.03/src/share/vm/memory/metaspaceShared.cpp.udiff.html *!// Should be class load order as per -_Xlog:classloading+preorder_* should be *!// Should be class load order as per -_Xlog:classload+preorder_* http://cr.openjdk.java.net/~mockner/8149995.03/src/share/vm/runtime/arguments.cpp.udiff.html Also, can you assign alf instead AliasedLoggingFlag alf; if (sscanf(arg, "-%" XSTR(BUFLEN) NAME_RANGE "%c", name, &dummy) == 1) { alf = catch_logging_aliases(name); likeif it's used only inside this scope. if (sscanf(arg, "-%" XSTR(BUFLEN) NAME_RANGE "%c", name, &dummy) == 1) { AliasedLoggingFlag alf = catch_logging_aliases(name); Thanks, Coleen On 3/10/16 1:22 PM, Max Ockner wrote: > Hello, > > I have responded to these comments. > > webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ > - classloadingpreorder replaced by classload+preorder > - In order to support aliasing to a log configuration with multiple > tags, the logging alias table is expanded to fit the output of the > LOG_TAGS(tag) macro. > - comment in metaspaceShared is changed to classload+preorder. > > Thanks, > Max > > On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >> >> >> We talked about this but I've changed my opinion. I think looking >> at this in the code, it might make more sense to make this >> log(classload, preorder) since anyone knowing about this option will >> know to specify both tags. I think it's used for CDS. Will this >> work for the aliasing table? If not, I think the tag is better >> classloadpreorder >> >> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >> >> >> The comment is wrong, it says classloaderpreorder, rather than >> classloadingpreorder. >> >> thanks, >> Coleen >> >> On 3/9/16 12:10 PM, Max Ockner wrote: >>> Hello again! >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>> >>> Thanks, >>> Max >>> >>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>> Hey, Max, >>>> >>>> Looks good. Just a few comments: >>>> >>>> In src/share/vm/classfile/classFileParser.cpp should this have a >>>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>>> farther up in the scope, but in case someone were to delete it >>>> later, it might make sense to have a more local one? Not sure what >>>> the standard is on this. >>>> >>>> Also I think you forgot to delete the option from runtime/globals.hpp. >>>> >>>> Thanks, >>>> Rachel >>>> >>>> >>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>> Hi, >>>>> >>>>> Please review this small Unified Logging change. >>>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>>> level. Debug level was chosen since there are 342 lines of output >>>>> for java -version. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>> >>>>> Tested with jtreg runtime tests. >>>>> No existing tests reference TraceClassLoadingPreorder from >>>>> hotspot/test or jdk/test. >>>>> >>>>> Thanks, >>>>> Max >>>> >>> >> > From kim.barrett at oracle.com Thu Mar 10 20:42:35 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Mar 2016 15:42:35 -0500 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E1AD2A.201@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> Message-ID: <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> > On Mar 10, 2016, at 12:21 PM, Jon Masamitsu wrote: > > > > On 03/09/2016 08:53 PM, David Holmes wrote: >> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>> Background: >>> >>> After the backport of https://bugs.openjdk.java.net/browse/JDK-8017462, The flag -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers to null in 8u. >>> >>> As there is no condition to handle such scenario in share/vm/memory/sharedHeap.cpp, which causes the crash. >>> >>> The similar condition is already implemented for following scenarios >>> >>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>> >>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>> >>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>> >>> >>> >>> Fix: >>> >>> Condition check is added in src/share/vm/runtime/arguments.cpp file to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>> >>> Thanks for the base patch from Jon. >>> >>> Due to this patch it makes some of the test cases absolute. They have been removed. >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >> >> This existing code looks wrong: >> >> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1676 Abstract_VM_Version::parallel_worker_threads()); >> 1677 if (ParallelGCThreads == 0) { >> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1679 Abstract_VM_Version::parallel_worker_threads()); >> >> Line 1678 seems to do the same as 1675 - is Abstract_VM_Version::parallel_worker_threads() somehow expected to return a different value on the second call ?? > > No, Abstract_VM_Version::parallel_worker_threads() won't return a different > value for a second call. It's harmless but would be cleaner deleting 1675,1676. The retry setting to parallel_worker_threads() again code dates back to the initial G1 checkin. Hard to know what was intended. The current jdk9 code does not have that: it looks like FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); if (ParallelGCThreads == 0) { assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value for ParallelGCThreads should not be 0."); vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); } This proposed change is for jdk8u-something, correct? In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be seen above. Making use of that decision, a cleanup pass was made that eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend it?s 1 or do some other special thing? code. The backport of 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken that into account. For example, http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb 17 13:42:03 2016 +0000 +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb 18 20:30:45 2016 +0000 @@ -3991,8 +3991,15 @@ TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); - uint active_workers = (G1CollectedHeap::use_parallel_gc_threads() ? - workers()->active_workers() : 1); + uint active_workers = AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), + workers()->active_workers(), + Threads::number_of_non_daemon_threads()); Note the conditionalization on use_parallel_gc_threads(). It might be that the simplest thing to do for 8u backporting is indeed to backport prevention of ParallelGCThreads == 0, as suggested in the proposed patch. From thomas.schatzl at oracle.com Thu Mar 10 20:46:45 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 10 Mar 2016 21:46:45 +0100 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> Message-ID: <1457642805.2363.5.camel@oracle.com> Hi, On Thu, 2016-03-10 at 15:42 -0500, Kim Barrett wrote: > > On Mar 10, 2016, at 12:21 PM, Jon Masamitsu < > > jon.masamitsu at oracle.com> wrote: > > > > > > [...] > The retry setting to parallel_worker_threads() again code dates back > to the initial G1 checkin. Hard to know what was intended. > > The current jdk9 code does not have that: it looks like > > FLAG_SET_DEFAULT(ParallelGCThreads, > Abstract_VM_Version::parallel_worker_threads()); > if (ParallelGCThreads == 0) { > assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value > for ParallelGCThreads should not be 0."); > vm_exit_during_initialization("The flag -XX:+UseG1GC can not be > combined with -XX:ParallelGCThreads=0", NULL); > } > > This proposed change is for jdk8u-something, correct? > > In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be > seen above. Making use of that decision, a cleanup pass was made > that eliminated a whole bunch of ?if (ParallelGCThreads == 0) then > pretend it?s 1 or do some other special thing? code. The backport of > 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken > that into account. For example, just some historical note: in 8u, ParallelGCThreads == 0 means "use the VM thread, single threaded", and ParallelGCThreads == 1 means use a single worker thread. In jdk9 we removed that option to use the vm thread in a single threaded way. We did not backport that change because of potential performance impact (whatever that might be). Thanks, Thomas From ioi.lam at oracle.com Thu Mar 10 22:50:56 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Mar 2016 14:50:56 -0800 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E1BB81.8000705@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> Message-ID: <56E1FA50.4090905@oracle.com> Hi Max, The changes look good. I just have one comment: $ java -Xlog:classload | less [0.108s][info][classload] java.lang.Object source: /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage ... For consistency, I think the preorder output should us the same style. I.e., remove "loading" and replace "from" to "source:" 5686 if (!is_internal()) { 5687 if (log_is_enabled(Debug, classload, preorder)){ 5688 ResourceMark rm(THREAD); 5689 outputStream* log = LogHandle(classload, preorder)::debug_stream(); 5690 log->print("loading %s", _class_name->as_klass_external_name()); 5691 if (stream->source() != NULL) { 5692 log->print(" from %s", stream->source()); 5693 } 5694 log->cr(); 5695 } 5696 Thanks - Ioi On 3/10/16 10:22 AM, Max Ockner wrote: > Hello, > > I have responded to these comments. > > webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ > - classloadingpreorder replaced by classload+preorder > - In order to support aliasing to a log configuration with multiple > tags, the logging alias table is expanded to fit the output of the > LOG_TAGS(tag) macro. > - comment in metaspaceShared is changed to classload+preorder. > > Thanks, > Max > > On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >> >> >> We talked about this but I've changed my opinion. I think looking >> at this in the code, it might make more sense to make this >> log(classload, preorder) since anyone knowing about this option will >> know to specify both tags. I think it's used for CDS. Will this >> work for the aliasing table? If not, I think the tag is better >> classloadpreorder >> >> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >> >> >> The comment is wrong, it says classloaderpreorder, rather than >> classloadingpreorder. >> >> thanks, >> Coleen >> >> On 3/9/16 12:10 PM, Max Ockner wrote: >>> Hello again! >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>> >>> Thanks, >>> Max >>> >>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>> Hey, Max, >>>> >>>> Looks good. Just a few comments: >>>> >>>> In src/share/vm/classfile/classFileParser.cpp should this have a >>>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>>> farther up in the scope, but in case someone were to delete it >>>> later, it might make sense to have a more local one? Not sure what >>>> the standard is on this. >>>> >>>> Also I think you forgot to delete the option from runtime/globals.hpp. >>>> >>>> Thanks, >>>> Rachel >>>> >>>> >>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>> Hi, >>>>> >>>>> Please review this small Unified Logging change. >>>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>>> level. Debug level was chosen since there are 342 lines of output >>>>> for java -version. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>> >>>>> Tested with jtreg runtime tests. >>>>> No existing tests reference TraceClassLoadingPreorder from >>>>> hotspot/test or jdk/test. >>>>> >>>>> Thanks, >>>>> Max >>>> >>> >> > From david.holmes at oracle.com Fri Mar 11 02:12:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2016 12:12:56 +1000 Subject: UL: logging before initialization? In-Reply-To: References: Message-ID: <56E229A8.4020907@oracle.com> Hi Thomas, Expanding to hotspot-dev as UL was not designed/built by the runtime team. My comments below based on my limited understanding of UL. On 11/03/2016 2:25 AM, Thomas St?fe wrote: > Hi all, > > I wanted to use UL to log some information from early OS initialization but > found that we initialize logging quite late. It is initialized way after > os::init() runs. There are various dependencies in the unified logging framework that prevent it (or at least parts of it) from being used early eg: - argument parsing and log configuration - existence of current thread (for logStreams) > I also see that warnings and errors are printed unconditionally even > before, only log calls for levels <= info are quietly swallowed. Are those warnings/errors using UL? I suspect not. Silent swallowing is not good though. > Would there be a way to move UL initialization and parsing of -Xlog > Arguments to an earlier point to be able to use logging in os::init()? I don't see how you could utilize tags and levels until after full initialization of the logging system, so that would preclude using it as early as os::init. > Or, if that is not possible, would there be a way to delay printing of > early logging calls to after logging initialization and then print them out > in one go? I think this would be not trivial though: one would have to > collect all logging output in memory somewhere - because we do not yet know > which tags are switched on - and then, once -Xlog is parsed, filter it by > tag before printing it out. Yeah that seems difficult/complex given the problem that the VM is in the early stages of initialization > What do you think, would that be a worthwhile change? I am a bit unhappy > about how logging calls are quietly swallowed, so for any code which runs > at VM initialization, one always has to keep in mind that UL may not yet be > initialized. Not a new problem (adding more code during VM initialization) but one that is getting more complicated :) Cheers, David > Kind Regards, Thomas > From david.holmes at oracle.com Fri Mar 11 07:04:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2016 17:04:21 +1000 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> Message-ID: <56E26DF5.8080300@oracle.com> Hi Thomas, Thanks for persevering with this. Sorry for the delayed response. On 10/03/2016 2:58 AM, Thomas St?fe wrote: > Hi all, > > please take a look at this next version of the fix. > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ > > I am the first to admit that this is quite ugly :(, but it is a > pragmatic solution. > > Some details: > > - I added os::strerror() as a drop-in replacement for ::strerror() - it > returns the text as before, but does not localize and does not handle > unknown error values; so it can be implemented using a simple static > string table and is always safe to use. Ok. But I don't think we need os::lasterror() if we have this. A follow up clean-up is okay for that though. Also it does seem to handle unknown error values. > - I added os::errno_name() for those cases where one would want the > literalized errno value (e.g. "EINVAL") instead of the full text. Ok. For the unknown case can it return the numeric value that it was passed? > - I fixed all callsites in the hotspot which used ::strerror to use > os::strerror, or, in some few cases (mostly my own coding for AIX), > os::errno_name(). Bit subjective but okay - I personally don't care either way. :) > - To avoid including os.hpp in debug.hpp, I moved the implemntation of > assert_status to debug.cpp Okay ... did the include cause a problem? General minor comments: src/os/posix/vm/os_posix.cpp Indentation of wrapped call needs fixing --- src/share/vm/runtime/os.hpp Typo: + // sugested in the POSIX standard. -> suggested --- src/share/vm/utilities/vmError.cpp Good catch on the code that potentially reports the wrong error using get_last_error! Even the simple print_cr(..., strerror(errno), errno) could in fact print non-matching values if strerror itself caused an error (unlikely of course :) ). Please check all copyright years - attachListener_solaris.cpp was updated to 2015 instead of 2016 :) Also note correct format for two year copyrights - in src/share/vm/logging/logFileOutput.cpp you have: Copyright (c) 2015,2016 Oracle but it should be: Copyright (c) 2015, 2016, Oracle Thanks, David > Kind Regards, Thomas > > > > > On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore > > wrote: > > > This latest version seems okay (or at least better than the other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas St?fe wrote: > > Hi David, > > On Mon, Feb 29, 2016 at 4:44 AM, David Holmes > > >> wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, Thomas St?fe wrote: > > Hi, > > please take a look at this proposed fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > This adds a replacement function os::strerror() as > a drop-in for > strerror(), which has a number of issues. > > strerror() is unsafe to use and may cause (and has > caused) > crashes in > multithreaded scenarios. It is also not ideal for > log files > because of the > implicit localization of the error messages. > > For details please see the discussion under the bug > report. > > > I just came across strerror_l, which is required to be > thread-safe. > Is that a possible alternative? (I'm not sure how > locale's are > obtained). > > > Sorry, I think this API is glibc only. At least I cannot > find this in > our AIX headers, nor on Solaris. > > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of POSIX.1-2008. But as per Dalibor's > link not necessarily available: > > "This function is missing on some platforms: glibc 2.3.6, Mac OS > X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX > 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, > mingw, MSVC 9, Interix 3.5, BeOS. " > > Pity. > > > Otherwise what you have seems okay - though I do > dislike having to > duplicate all that details already buried in the system > headers/library. Not sure we need to the long text at > the VM level - > which would simplify things a bit. > > > I agree, I dislike this too. Like everyone else in this > thread. But I > think this is a pragmatic solution. > > I am a bit stuck here - should we really get rid of the long > text > feature? There are some callsites of strerror() in the > hotspot where > arguably the long text is better suited: > - in assert_status() (see debug.hpp) - this ends up in the > header of > error files, if this suddenly changes to a literalized > errno, people may > be upset > > > I added assert_status purely to expand on what the failing > status was :) I'm happy to see EINVAL in that context rather > than "invalid argument" (or whatever) :) > > - when failing to write a heap dump file - see > services/heapDumper.cpp. > Which ends as printout on the command line, I think. > > > Maybe ... if it is an error the user can fix. > > The safe option would be to provide both variants (short and > long text). > Or, provide the safe, short variant for all logging calls - when > "EINVAL" is enough, and let users continue to use strerror() > for those > few cases where the long text is needed. > > What do you think? > > > Trying to decide what makes me least unhappy. :) Given you've > already done the work I guess having long and short forms is okay. > > Thanks, > David > > Thanks, Thomas > > Thanks, > David > > > Please note that I did not yet change any call > sites, although > all call > sites in the os namespace should already use the > new function. I > wanted to > see whether there would be any general objections. > > Kind Regards, Thomas > > > > From david.holmes at oracle.com Fri Mar 11 07:10:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2016 17:10:32 +1000 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E091B3.8040305@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D77F55.9010801@oracle.com> <56E07B0E.3010002@oracle.com> <56E091B3.8040305@oracle.com> Message-ID: <56E26F68.6030703@oracle.com> A belated "looks okay to me " :) Thanks, David On 10/03/2016 7:12 AM, Coleen Phillimore wrote: > > Hi Harold, > Thank you for the code review! > > I added a test for the stack trace logging. I also made some other > minor changes that you pointed out. I also added a function to find the > field offset from a char* which is used by "depth", but that can be used > by other things in javaClasses.cpp that need to know field offsets > without adding to vmSymbols.hpp. > > Also, I made the assertion changes discussed with David in this > version. Reran some jck tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_hotspot/ > open webrev at http://cr.openjdk.java.net/~coleenp/8150778.03_jdk/ > > I didn't change jdk since 02. > > Thanks, > Coleen > > > On 3/9/16 2:35 PM, harold seigel wrote: >> Hi Coleen, >> >> The JVM changes look good. Could you add a test or test case for the >> new 'stacktrace' logging tag? >> >> Thanks, Harold >> >> On 3/2/2016 7:03 PM, Coleen Phillimore wrote: >>> Freshly tested changes with jck tests, with missing checks and other >>> changes to use the depth field, as pointed out by Aleksey. I've kept >>> the StackTraceElement[] allocation in Java to match the new API that >>> was approved. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/ >>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/ >>> >>> Thanks, >>> Coleen >>> >>> On 3/2/16 2:57 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/2/16 1:58 PM, Aleksey Shipilev wrote: >>>>> Hi Coleen, >>>>> >>>>> On 03/02/2016 09:44 PM, Coleen Phillimore wrote: >>>>>> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, >>>>>> with JVM_GetStackTraceElements that gets all the elements in the >>>>>> StackTraceElement[] >>>>>> >>>>>> These improvements were found during the investigation for replacing >>>>>> Throwable with the StackWalkAPI. This change also adds iterator for >>>>>> BacktraceBuilder to make changing format of backtrace easier. >>>>>> >>>>>> Tested with -testset core, RBT nightly hotspot nightly tests on all >>>>>> platforms, and jck tests on linux x64. Compatibility request is >>>>>> approved. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8150778 >>>>> Looks interesting! >>>>> >>>>> Is there an underlying reason why we can't return the pre-filled >>>>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin >>>>> with? This will avoid leaking StackTraceElement constructor into >>>>> standard library, *and* allows to make StackTraceElement fields final. >>>>> Taking stuff back from the standard library is hard, if not >>>>> impossible, >>>>> so we better expose as little as possible. >>>> >>>> We measured that it's faster to allocate the StackTraceElement array >>>> in Java and it seems cleaner to the Java guys. >>>> It came from similar code we've been prototyping for StackFrameInfo. >>>>> >>>>> Other minor nits: >>>>> >>>>> * Initializing fields to their default values is a code smell in >>>>> Java: >>>>> private transient int depth = 0; >>>> >>>> ok, not sure what "code smell" means but it doesn't have to be >>>> initialized like this. It's set in the native code. >>>>> >>>>> * Passing a null array to getStackTraceElement probably SEGVs? I >>>>> don't >>>>> see the null checks in native parts. >>>> >>>> Yes, it would SEGV. I'll add some checks for null and make sure >>>> it's an array of StackTraceElement. >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>> >>> >> > From marcus.larsson at oracle.com Fri Mar 11 08:14:05 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Mar 2016 09:14:05 +0100 Subject: UL: logging before initialization? In-Reply-To: <56E229A8.4020907@oracle.com> References: <56E229A8.4020907@oracle.com> Message-ID: <56E27E4D.3060108@oracle.com> Hi, On 2016-03-11 03:12, David Holmes wrote: > Hi Thomas, > > Expanding to hotspot-dev as UL was not designed/built by the runtime > team. > > My comments below based on my limited understanding of UL. > > On 11/03/2016 2:25 AM, Thomas St?fe wrote: >> Hi all, >> >> I wanted to use UL to log some information from early OS >> initialization but >> found that we initialize logging quite late. It is initialized way after >> os::init() runs. > > There are various dependencies in the unified logging framework that > prevent it (or at least parts of it) from being used early eg: > - argument parsing and log configuration > - existence of current thread (for logStreams) Currently, the framework can be used as soon as static initialization is done. This doesn't include the logStreams of course since they require resource allocations. The problem is as you say that there is no way to configure the logging before parsing the -Xlog command. This means up until that point the default configuration will apply, which means warnings and errors to stdout. > >> I also see that warnings and errors are printed unconditionally even >> before, only log calls for levels <= info are quietly swallowed. > > Are those warnings/errors using UL? I suspect not. They could be, since errors and warnings are enabled by default. > > Silent swallowing is not good though. > >> Would there be a way to move UL initialization and parsing of -Xlog >> Arguments to an earlier point to be able to use logging in os::init()? > > I don't see how you could utilize tags and levels until after full > initialization of the logging system, so that would preclude using it > as early as os::init. It is a possible solution I guess. I don't know how dependent argument parsing is on other initialization. There would always be some part of the initialization where you only have warning and error logging unless we do the parsing first thing during startup, which I assume will be impossible. > >> Or, if that is not possible, would there be a way to delay printing of >> early logging calls to after logging initialization and then print >> them out >> in one go? I think this would be not trivial though: one would have to >> collect all logging output in memory somewhere - because we do not >> yet know >> which tags are switched on - and then, once -Xlog is parsed, filter >> it by >> tag before printing it out. > > Yeah that seems difficult/complex given the problem that the VM is in > the early stages of initialization > >> What do you think, would that be a worthwhile change? I am a bit unhappy >> about how logging calls are quietly swallowed, so for any code which >> runs >> at VM initialization, one always has to keep in mind that UL may not >> yet be >> initialized. > > Not a new problem (adding more code during VM initialization) but one > that is getting more complicated :) I think it would perhaps be worthwhile if there's demand for a bunch of info to trace level logging from startup code (before argument parsing). Thanks, Marcus > > Cheers, > David > >> Kind Regards, Thomas >> From cheleswer.sahu at oracle.com Fri Mar 11 09:31:55 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 11 Mar 2016 01:31:55 -0800 (PST) Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: <56E16C85.30102@oracle.com> Message-ID: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> Hi Thomas, Dmitry, ? Thanks for your review comments. ?My answers are below for your review comments ? 1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){ 1874 ? ? ? ? break; 1875 ? ? ? } >> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will? not able to read the data, it will return lesser number of bytes, which contains the partial data of ??prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. ? 2) Just interesting, do you really need to set memory to 0 by memset? >> ?I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. ? For rest of the comments I have made correction in the code. The new webrev is available in the below location http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ ? ? Regards, Cheleswer ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Thursday, March 10, 2016 7:39 PM To: Dmitry Dmitriev Cc: Cheleswer Sahu; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly ? (Sorry, pressed Send button too early) Just wanted to add that 1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){ 1874 ? ? ? ? break; 1875 ? ? ? } may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. Kind Regards, Thomas ? On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: Hi?Cheleswer, ? thanks for fixing this. ? Some more issues: ? -?1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); ? Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. ? -?1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024); ? Format specifier for Size is wrong.%d is int, but?p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. (But I know this coding was there before) ? Beside those points, I think both points of Dmitry are valid. ? Also, I find? ? ? Kind Regards, Thomas ? On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: Hi Cheleswer, Looks good, but I have questions/comments about other code in this function: 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". 2) Just interesting, do you really need to set memory to 0 by memset? Thanks, Dmitry On 10.03.2016 13:43, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ Bug Brief: In check_addr0(),? pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. Regards, Cheleswer ? ? ? From thomas.stuefe at gmail.com Fri Mar 11 11:22:48 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Mar 2016 12:22:48 +0100 Subject: UL: logging before initialization? In-Reply-To: <56E27E4D.3060108@oracle.com> References: <56E229A8.4020907@oracle.com> <56E27E4D.3060108@oracle.com> Message-ID: Hi David, Marcus, thanks for thinking about this! Please find my comments inline. On Fri, Mar 11, 2016 at 9:14 AM, Marcus Larsson wrote: > Hi, > > On 2016-03-11 03:12, David Holmes wrote: > >> Hi Thomas, >> >> Expanding to hotspot-dev as UL was not designed/built by the runtime team. >> >> My comments below based on my limited understanding of UL. >> >> On 11/03/2016 2:25 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> I wanted to use UL to log some information from early OS initialization >>> but >>> found that we initialize logging quite late. It is initialized way after >>> os::init() runs. >>> >> >> There are various dependencies in the unified logging framework that >> prevent it (or at least parts of it) from being used early eg: >> - argument parsing and log configuration >> - existence of current thread (for logStreams) >> > > Currently, the framework can be used as soon as static initialization is > done. This doesn't include the logStreams of course since they require > resource allocations. The problem is as you say that there is no way to > configure the logging before parsing the -Xlog command. This means up until > that point the default configuration will apply, which means warnings and > errors to stdout. > > >> I also see that warnings and errors are printed unconditionally even >>> before, only log calls for levels <= info are quietly swallowed. >>> >> >> Are those warnings/errors using UL? I suspect not. >> > > They could be, since errors and warnings are enabled by default. They are from UL. I see errors and warnings. Decorators seem to be off though, e.g. the timestamp, because they rely on initialization in os::init(). But nothing serious which breaks logging as long as one is fine with default settings. > > > >> Silent swallowing is not good though. >> >> Would there be a way to move UL initialization and parsing of -Xlog >>> Arguments to an earlier point to be able to use logging in os::init()? >>> >> >> I don't see how you could utilize tags and levels until after full >> initialization of the logging system, so that would preclude using it as >> early as os::init. >> > > It is a possible solution I guess. I don't know how dependent argument > parsing is on other initialization. There would always be some part of the > initialization where you only have warning and error logging unless we do > the parsing first thing during startup, which I assume will be impossible. > > Sure, the logging system must be fully initialized to use it. However, I argue that the logging system should be as independent as possible from the rest of the VM, so not rely on VM initialization. If that is the case - and I think it is now - then logging initialization and -Xlog parsing can be moved up in Thread::create_vm() to before os::init(). I would even argue that if this does not work, it is an error. For example, if we were to require Thread::current() to work for logging,e.g. for log decorators, this would mean logging breaks if Thread::current() is not available. So, if we make the logging system work for pre-initialization time, and add regression tests for this, this is a pretty good way to keep the logging system healthy and robust and avoid too much dependencies into the VM. I would think that the logging system as it is now is already robust - the fact that it works, with default settings, right after static initialization is a good sign. So, we could probably move initialization and -Xlog parsing to an earlier point with not much work. > >> Or, if that is not possible, would there be a way to delay printing of >>> early logging calls to after logging initialization and then print them >>> out >>> in one go? I think this would be not trivial though: one would have to >>> collect all logging output in memory somewhere - because we do not yet >>> know >>> which tags are switched on - and then, once -Xlog is parsed, filter it by >>> tag before printing it out. >>> >> >> Yeah that seems difficult/complex given the problem that the VM is in the >> early stages of initialization >> >> I really do not like this solution either, I only added this for completeness and to make my first proposal look better in comparison :) > What do you think, would that be a worthwhile change? I am a bit unhappy >>> about how logging calls are quietly swallowed, so for any code which runs >>> at VM initialization, one always has to keep in mind that UL may not yet >>> be >>> initialized. >>> >> >> Not a new problem (adding more code during VM initialization) but one >> that is getting more complicated :) >> > > I think it would perhaps be worthwhile if there's demand for a bunch of > info to trace level logging from startup code (before argument parsing). > > At least in the AIX port we have a lot of tracing going on very early. For platform porters, OS initialization is a very interesting time. We have now a very primitive trace there which I would love to switch to UL, but right now the trace output would just be swallowed by not-yet-initialized UL. Thank you, Thomas > Thanks, > Marcus > > > >> Cheers, >> David >> >> Kind Regards, Thomas >>> >>> > From dmitry.dmitriev at oracle.com Fri Mar 11 11:29:44 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 11 Mar 2016 14:29:44 +0300 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> Message-ID: <56E2AC28.4040306@oracle.com> Hi Cheleswer, Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. Thanks, Dmitry On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > Thanks for your review comments. My answers are below for your review > comments > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > >> For this it has been thought that mostly read() will return the > desired number of bytes, but only in case if something goes wrong and > read() will not able to read the data, it will return lesser number > of bytes, which contains the partial data of ?prmap_t? structure. The > reason could be like file is corrupted, in such cases we don?t want to > read anymore and feel it?s safe to skip the rest of file. > > 2) Just interesting, do you really need to set memory to 0 by memset? > > >> I thought this it is good to have a clean buffer every time we > read something into it, but it?s really not that much required as we > are reading a binary data. So I am removing this line from the code. > > For rest of the comments I have made correction in the code. The new > webrev is available in the below location > > http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > Regards, > > Cheleswer > > *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Thursday, March 10, 2016 7:39 PM > *To:* Dmitry Dmitriev > *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer > is not updated correctly > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() > stopped reading in a middle of a record. You could just continue to > read until you read the rest of the record. > > Kind Regards, Thomas > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe > wrote: > > Hi Cheleswer, > > thanks for fixing this. > > Some more issues: > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > Why the "+1"? It is unnecessary and causes the allocation to be > 200 bytes larger than necessary. > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > Format specifier for Size is wrong.%d is int, but p->pr_size is > size_t. Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > Beside those points, I think both points of Dmitry are valid. > > Also, I find > > Kind Regards, Thomas > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev > > > wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in > this function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by > memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ > > > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, > because of this it was reading only first two entries from > buffer. > > Regards, > > Cheleswer > From thomas.stuefe at gmail.com Fri Mar 11 11:32:42 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Mar 2016 12:32:42 +0100 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> Message-ID: Hi Cheleswer, this version looks fine too me. Thank you for doing this. Kind Regards, Thomas On Fri, Mar 11, 2016 at 10:31 AM, Cheleswer Sahu wrote: > Hi Thomas, Dmitry, > > > > Thanks for your review comments. My answers are below for your review > comments > > > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > >> For this it has been thought that mostly read() will return the desired > number of bytes, but only in case if something goes wrong and read() will > not able to read the data, it will return lesser number of bytes, which > contains the partial data of ?prmap_t? structure. The reason could be like > file is corrupted, in such cases we don?t want to read anymore and feel > it?s safe to skip the rest of file. > > > > 2) Just interesting, do you really need to set memory to 0 by memset? > > >> I thought this it is good to have a clean buffer every time we read > something into it, but it?s really not that much required as we are reading > a binary data. So I am removing this line from the code. > > > > For rest of the comments I have made correction in the code. The new > webrev is available in the below location > > http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > > > > Regards, > > Cheleswer > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Thursday, March 10, 2016 7:39 PM > *To:* Dmitry Dmitriev > *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is > not updated correctly > > > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() stopped > reading in a middle of a record. You could just continue to read until you > read the rest of the record. > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe > wrote: > > Hi Cheleswer, > > > > thanks for fixing this. > > > > Some more issues: > > > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes > larger than necessary. > > > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. > Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > > > Beside those points, I think both points of Dmitry are valid. > > > > Also, I find > > > > > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev < > dmitry.dmitriev at oracle.com> wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this > function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ < > http://cr.openjdk.java.net/%7Ecsahu/8151509/> > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of this > it was reading only first two entries from buffer. > > Regards, > > Cheleswer > > > > > > > From cheleswer.sahu at oracle.com Fri Mar 11 11:38:15 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 11 Mar 2016 03:38:15 -0800 (PST) Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <56E2AC28.4040306@oracle.com> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> Message-ID: Thanks Dmitry and Thomas for reviews. After adding space I will ?request for the push. ? Regards, Cheleswer ? From: Dmitry Dmitriev Sent: Friday, March 11, 2016 5:00 PM To: Cheleswer Sahu; Thomas St?fe Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly ? Hi Cheleswer, Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. Thanks, Dmitry On 11.03.2016 12:31, Cheleswer Sahu wrote: Hi Thomas, Dmitry, ? Thanks for your review comments. ?My answers are below for your review comments ? 1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){ 1874 ? ? ? ? break; 1875 ? ? ? } >> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will? not able to read the data, it will return lesser number of bytes, which contains the partial data of ??prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. ? 2) Just interesting, do you really need to set memory to 0 by memset? >> ?I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. ? For rest of the comments I have made correction in the code. The new webrev is available in the below location HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ ? ? Regards, Cheleswer ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Thursday, March 10, 2016 7:39 PM To: Dmitry Dmitriev Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly ? (Sorry, pressed Send button too early) Just wanted to add that 1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){ 1874 ? ? ? ? break; 1875 ? ? ? } may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. Kind Regards, Thomas ? On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: Hi?Cheleswer, ? thanks for fixing this. ? Some more issues: ? -?1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); ? Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. ? -?1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024); ? Format specifier for Size is wrong.%d is int, but?p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. (But I know this coding was there before) ? Beside those points, I think both points of Dmitry are valid. ? Also, I find? ? ? Kind Regards, Thomas ? On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: Hi Cheleswer, Looks good, but I have questions/comments about other code in this function: 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". 2) Just interesting, do you really need to set memory to 0 by memset? Thanks, Dmitry On 10.03.2016 13:43, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ Bug Brief: In check_addr0(),? pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. Regards, Cheleswer ? ? ? ? From dmitry.dmitriev at oracle.com Fri Mar 11 11:40:31 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 11 Mar 2016 14:40:31 +0300 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> Message-ID: <56E2AEAF.3030101@oracle.com> Cheleswer, thank you! But I think you need a "R"eviewer for that change before push. Dmitry On 11.03.2016 14:38, Cheleswer Sahu wrote: > > Thanks Dmitry and Thomas for reviews. After adding space I will > request for the push. > > Regards, > > Cheleswer > > *From:*Dmitry Dmitriev > *Sent:* Friday, March 11, 2016 5:00 PM > *To:* Cheleswer Sahu; Thomas St?fe > *Cc:* serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer > is not updated correctly > > Hi Cheleswer, > > Please, add space between SIZE_FORMAT and " because C++11 requires a > space between literal and identifier. Not need a new webrev for that. > > Thanks, > Dmitry > > On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > Thanks for your review comments. My answers are below for your > review comments > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > > >> For this it has been thought that mostly read() will return the > desired number of bytes, but only in case if something goes wrong > and read() will not able to read the data, it will return lesser > number of bytes, which contains the partial data of ?prmap_t? > structure. The reason could be like file is corrupted, in such > cases we don?t want to read anymore and feel it?s safe to skip the > rest of file. > > 2) Just interesting, do you really need to set memory to 0 by memset? > > >> I thought this it is good to have a clean buffer every time we > read something into it, but it?s really not that much required as > we are reading a binary data. So I am removing this line from the > code. > > For rest of the comments I have made correction in the code. The > new webrev is available in the below location > > http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > Regards, > > Cheleswer > > *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Thursday, March 10, 2016 7:39 PM > *To:* Dmitry Dmitriev > *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net > ; > hotspot-runtime-dev at openjdk.java.net > > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function > pointer is not updated correctly > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() > stopped reading in a middle of a record. You could just continue > to read until you read the rest of the record. > > Kind Regards, Thomas > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe > > wrote: > > Hi Cheleswer, > > thanks for fixing this. > > Some more issues: > > - 1866 char *mbuff = (char *) calloc(read_chunk, > sizeof(prmap_t) + 1); > > Why the "+1"? It is unnecessary and causes the allocation to > be 200 bytes larger than necessary. > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > Format specifier for Size is wrong.%d is int, but p->pr_size > is size_t. Theoretical truncation for mappings larger than > 4g*1024. > > (But I know this coding was there before) > > Beside those points, I think both points of Dmitry are valid. > > Also, I find > > Kind Regards, Thomas > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev > > wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code > in this function: > 1) I think that "::close(fd);" should be inside "if (fd >= > 0) {". > 2) Just interesting, do you really need to set memory to 0 > by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: > http://cr.openjdk.java.net/~csahu/8151509/ > > > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated > correctly, because of this it was reading only first > two entries from buffer. > > Regards, > > Cheleswer > From david.holmes at oracle.com Fri Mar 11 12:53:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2016 22:53:39 +1000 Subject: UL: logging before initialization? In-Reply-To: References: <56E229A8.4020907@oracle.com> <56E27E4D.3060108@oracle.com> Message-ID: <56E2BFD3.7060306@oracle.com> On 11/03/2016 9:22 PM, Thomas St?fe wrote: > Hi David, Marcus, > > thanks for thinking about this! Please find my comments inline. > > On Fri, Mar 11, 2016 at 9:14 AM, Marcus Larsson > > wrote: > > Hi, > > On 2016-03-11 03:12, David Holmes wrote: > > Hi Thomas, > > Expanding to hotspot-dev as UL was not designed/built by the > runtime team. > > My comments below based on my limited understanding of UL. > > On 11/03/2016 2:25 AM, Thomas St?fe wrote: > > Hi all, > > I wanted to use UL to log some information from early OS > initialization but > found that we initialize logging quite late. It is > initialized way after > os::init() runs. > > > There are various dependencies in the unified logging framework > that prevent it (or at least parts of it) from being used early eg: > - argument parsing and log configuration > - existence of current thread (for logStreams) > > > Currently, the framework can be used as soon as static > initialization is done. This doesn't include the logStreams of > course since they require resource allocations. The problem is as > you say that there is no way to configure the logging before parsing > the -Xlog command. This means up until that point the default > configuration will apply, which means warnings and errors to stdout. > > > I also see that warnings and errors are printed > unconditionally even > before, only log calls for levels <= info are quietly swallowed. > > > Are those warnings/errors using UL? I suspect not. > > > They could be, since errors and warnings are enabled by default. > > > They are from UL. I see errors and warnings. Decorators seem to be off > though, e.g. the timestamp, because they rely on initialization in > os::init(). But nothing serious which breaks logging as long as one is > fine with default settings. > > > > > Silent swallowing is not good though. > > Would there be a way to move UL initialization and parsing > of -Xlog > Arguments to an earlier point to be able to use logging in > os::init()? > > > I don't see how you could utilize tags and levels until after > full initialization of the logging system, so that would > preclude using it as early as os::init. > > > It is a possible solution I guess. I don't know how dependent > argument parsing is on other initialization. There would always be > some part of the initialization where you only have warning and > error logging unless we do the parsing first thing during startup, > which I assume will be impossible. > > > Sure, the logging system must be fully initialized to use it. However, I > argue that the logging system should be as independent as possible from > the rest of the VM, so not rely on VM initialization. If that is the > case - and I think it is now - then logging initialization and -Xlog > parsing can be moved up in Thread::create_vm() to before os::init(). You would need to examine the complete transitive closure of logging code to see if such a move is feasible. > I would even argue that if this does not work, it is an error. For > example, if we were to require Thread::current() to work for > logging,e.g. for log decorators, this would mean logging breaks if > Thread::current() is not available. So, if we make the logging system > work for pre-initialization time, and add regression tests for this, > this is a pretty good way to keep the logging system healthy and robust > and avoid too much dependencies into the VM. > > I would think that the logging system as it is now is already robust - > the fact that it works, with default settings, right after static > initialization is a good sign. So, we could probably move initialization > and -Xlog parsing to an earlier point with not much work. While the logging system has taken a number of steps to make itself immune to some initialization issues (for example "locking" uses a semaphore and doesn't rely on Thread::current()), different parts of the system have different dependencies - which seems unavoidable to me. I don't know if it would be possible to enable a subset of the API earlier in the initialization sequence by refactoring some of the configuration logic and argument parsing. David ----- > > Or, if that is not possible, would there be a way to delay > printing of > early logging calls to after logging initialization and then > print them out > in one go? I think this would be not trivial though: one > would have to > collect all logging output in memory somewhere - because we > do not yet know > which tags are switched on - and then, once -Xlog is parsed, > filter it by > tag before printing it out. > > > Yeah that seems difficult/complex given the problem that the VM > is in the early stages of initialization > > > I really do not like this solution either, I only added this for > completeness and to make my first proposal look better in comparison :) > > What do you think, would that be a worthwhile change? I am a > bit unhappy > about how logging calls are quietly swallowed, so for any > code which runs > at VM initialization, one always has to keep in mind that UL > may not yet be > initialized. > > > Not a new problem (adding more code during VM initialization) > but one that is getting more complicated :) > > > I think it would perhaps be worthwhile if there's demand for a bunch > of info to trace level logging from startup code (before argument > parsing). > > > At least in the AIX port we have a lot of tracing going on very early. > For platform porters, OS initialization is a very interesting time. We > have now a very primitive trace there which I would love to switch to > UL, but right now the trace output would just be swallowed by > not-yet-initialized UL. > > Thank you, > > Thomas > > Thanks, > Marcus > > > > Cheers, > David > > Kind Regards, Thomas > > > From thomas.stuefe at gmail.com Fri Mar 11 13:31:37 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Mar 2016 14:31:37 +0100 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <56E2AEAF.3030101@oracle.com> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> <56E2AEAF.3030101@oracle.com> Message-ID: Dmitry is right, at least I am only a committer, not a "R"eviewer. On Fri, Mar 11, 2016 at 12:40 PM, Dmitry Dmitriev < dmitry.dmitriev at oracle.com> wrote: > Cheleswer, thank you! But I think you need a "R"eviewer for that change > before push. > > Dmitry > > > On 11.03.2016 14:38, Cheleswer Sahu wrote: > > Thanks Dmitry and Thomas for reviews. After adding space I will request > for the push. > > > > Regards, > > Cheleswer > > > > *From:* Dmitry Dmitriev > *Sent:* Friday, March 11, 2016 5:00 PM > *To:* Cheleswer Sahu; Thomas St?fe > *Cc:* serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is > not updated correctly > > > > Hi Cheleswer, > > Please, add space between SIZE_FORMAT and " because C++11 requires a space > between literal and identifier. Not need a new webrev for that. > > Thanks, > Dmitry > > On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > > > Thanks for your review comments. My answers are below for your review > comments > > > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > > >> For this it has been thought that mostly read() will return the desired > number of bytes, but only in case if something goes wrong and read() will > not able to read the data, it will return lesser number of bytes, which > contains the partial data of ?prmap_t? structure. The reason could be like > file is corrupted, in such cases we don?t want to read anymore and feel > it?s safe to skip the rest of file. > > > > 2) Just interesting, do you really need to set memory to 0 by memset? > > >> I thought this it is good to have a clean buffer every time we read > something into it, but it?s really not that much required as we are reading > a binary data. So I am removing this line from the code. > > > > For rest of the comments I have made correction in the code. The new > webrev is available in the below location > > http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > > > > Regards, > > Cheleswer > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com > ] > *Sent:* Thursday, March 10, 2016 7:39 PM > *To:* Dmitry Dmitriev > *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is > not updated correctly > > > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() stopped > reading in a middle of a record. You could just continue to read until you > read the rest of the record. > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe > wrote: > > Hi Cheleswer, > > > > thanks for fixing this. > > > > Some more issues: > > > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes > larger than necessary. > > > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. > Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > > > Beside those points, I think both points of Dmitry are valid. > > > > Also, I find > > > > > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev < > dmitry.dmitriev at oracle.com> wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this > function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for > > https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ < > http://cr.openjdk.java.net/%7Ecsahu/8151509/> > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of this > it was reading only first two entries from buffer. > > Regards, > > Cheleswer > > > > > > > > > > > From bengt.rutisson at oracle.com Fri Mar 11 13:30:49 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 11 Mar 2016 14:30:49 +0100 Subject: RFR: 8146551: The output from -Xlog:classresolve=info has been shortened In-Reply-To: <56E18A93.3030707@oracle.com> References: <56D617FE.9010504@oracle.com> <56D80687.6060501@oracle.com> <56D807B9.3000709@oracle.com> <56D89FDD.40804@oracle.com> <56E07037.6080801@oracle.com> <56E18A93.3030707@oracle.com> Message-ID: <56E2C889.2060000@oracle.com> Hi Max, On 2016-03-10 15:54, Max Ockner wrote: > Hello, > > Thanks to everyone for their ideas and help. If there are no more > concerns, I would like to submit this. I'm not one of the reviewers of this, (just had a quick look now and it does look good to me) but since I was involved in other discussions in this email thread I thought I'd say that I am fine with you pushing this. I think the discussions regarding how to use the UL framework will be handled in other threads. Thanks, Bengt > > Thanks, > Max > > On 3/9/2016 1:49 PM, Rachel Protacio wrote: >> Looks good to me, Max. And I agree with your decision about the level. >> >> Rachel >> >> On 3/3/2016 3:34 PM, Max Ockner wrote: >>> Thanks for the additional feedback. >>> I have set all of the output to the debug level. >>> webrev: http://cr.openjdk.java.net/~mockner/8146551.04/ >>> >>> You can't really infer anything about the verbosity of a Trace* >>> option from the face that it starts with "Trace", though I agree >>> that it would make a lot more sense if that were the case... >>> >>> I chose to put all of the output on debug after accounting for 2 >>> things; >>> (1) The output is extremely verbose, even for java -version. >>> Therefore, all output should be either debug or trace level. >>> (2) None of the output ever conditioned on Verbose or WizardMode. >>> Based on the conventions we have been following, the output >>> shouldn't be on trace level. >>> >>> ==> Debug level. >>> >>> Thanks, >>> Max >>> >>> On 3/3/2016 4:45 AM, Bengt Rutisson wrote: >>>> >>>> Hi Max and Mikael, >>>> >>>> On 2016-03-03 10:40, Mikael Gerdin wrote: >>>>> Hi Max, >>>>> >>>>> On 2016-03-01 23:30, Max Ockner wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this small fix which attempts to shorten the output >>>>>> from >>>>>> -Xlog:classresolve=info to an acceptable length. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146551 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8146551.02/ >>>>>> >>>>>> Summary: java '-Xlog:classresolve=info -version' used to produce >>>>>> 3,683 >>>>>> lines of output. This is unacceptably verbose for info level >>>>>> logging and >>>>>> most of the output is not useful. >>>>>> >>>>>> "java -Xlog:classresolve=info -version" used to produce: >>>>>> - 3,683 total lines of output. >>>>>> - 3,121 total lines of output from >>>>>> ConstantPool::trace_class_resolution(). >>>>>> - 1,329 unique lines of output. >>>>>> - 767 unique lines of output from >>>>>> ConstantPool::trace_class_resolution(). >>>>>> - 562 total lines of output from all other sources, all >>>>>> unique. >>>>>> >>>>>> The code in ConstantPool which called >>>>>> ConstantPool::trace_class_resolution() was doing approximately this: >>>>>> >>>>>> if (log_is_enabled(Info,classresolve)){ trace_class_resolution(...)} >>>>>> else { resolve the class } >>>>>> >>>>>> So if logging was turned on, the class would not be resolved >>>>>> properly, >>>>>> but it would produce a log entry saying that the class was being >>>>>> resolved. As a result, the constant pool entry would still contain a >>>>>> Symbol* the next time this piece of code was reached, and it would >>>>>> produce yet another classresolve log entry. In some cases, this was >>>>>> producing many consecutive identical log entries, taking up full >>>>>> pages >>>>>> at worst, and averaging a little over 4 duplicates per message. >>>>>> Not cool. >>>>>> >>>>>> The above duplication issue has been fixed, and the >>>>>> ConstantPool::trace_class_resolution output has been moved to the >>>>>> debug >>>>>> leve. There are still 562 unique lines of output for "java >>>>>> -Xlog:classresolve=info -version". There are now 767 additional >>>>>> unique >>>>>> lines of output when for the "java -Xlog:classresolve=debug >>>>>> -version" . >>>>>> This is better than before but still quite a lot. It seems like >>>>>> all of >>>>>> the info level output is equally important(or unimportant), as >>>>>> you can >>>>>> see in the sample below: >>>>>> >>>>>> [0.026s][info][classresolve] java.lang.reflect.Type java.lang.Object >>>>>> (super) >>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.Object >>>>>> (super) >>>>>> [0.026s][info][classresolve] java.lang.Class java.io.Serializable >>>>>> (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>> java.lang.reflect.GenericDeclaration (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class java.lang.reflect.Type >>>>>> (interface) >>>>>> [0.026s][info][classresolve] java.lang.Class >>>>>> java.lang.reflect.AnnotatedElement (interface) >>>>>> [0.026s][info][classresolve] java.lang.Cloneable java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.ClassLoader >>>>>> java.lang.Object (super) >>>>>> [0.027s][info][classresolve] java.lang.System java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.Throwable java.lang.Object >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.Throwable >>>>>> java.io.Serializable >>>>>> (interface) >>>>>> [0.027s][info][classresolve] java.lang.Error java.lang.Throwable >>>>>> (super) >>>>>> [0.027s][info][classresolve] java.lang.ThreadDeath >>>>>> java.lang.Error (super) >>>>>> >>>>>> How do you feel about this? Possible solutions include setting all >>>>>> output to debug level, or removing some of the logging messages. >>>>> >>>>> As I stated in the bug my personal opinion is that "info" level >>>>> logging should be fairly limited in order to make "-Xlog:all" a >>>>> useful flag to get a reasonable amount of output about what is >>>>> happening in a JVM. >>>>> >>>>> One approach could be to move the most verbose output to >>>>> classresolve=trace and keep the rest of classresolve output on the >>>>> debug level. >>>>> >>>>> The fact that the flag was called "TraceClassResolution" is in my >>>>> mind a hint that if it produces large amounts of output then >>>>> perhaps that output should be logged on the "trace" log level. >>>> >>>> +1 for this approach. >>>> >>>> I quite agree with Mikael that we should be a bit careful what we >>>> log at info level. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Tested with jtreg runtime tests. ClassResolutionTest.java has been >>>>>> modified to check for the new output. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>> >>> >> > From marcus.larsson at oracle.com Fri Mar 11 14:21:44 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Mar 2016 15:21:44 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56D5A1BB.6030403@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> Message-ID: <56E2D478.3090202@oracle.com> Third time's the charm. Webrev: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. Tested with included internal VM tests through RBT. Thanks, Marcus On 2016-03-01 15:05, Marcus Larsson wrote: > Hi, > > After some offline discussions I'm withdrawing this patch. I will > instead investigate if I can achieve similar behavior using log > rotation as the default. > > Thanks, > Marcus > > On 03/01/2016 12:11 PM, Marcus Larsson wrote: >> Hi again, >> >> Taking a different approach to this. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >> >> Existing files will now by default be renamed/archived with a .X >> suffix where X is the lowest number such that the resulting file name >> is available (jvm.log becomes jvm.log.0). A mode option for >> controlling this behavior has been added as well. It can be set to >> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >> >> Tested with included jtreg test through JPRT. >> >> Thanks, >> Marcus >> >> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to make sure UL truncates existing >>> log files before writing to them. Since files are opened in append >>> mode, truncation isn't done automatically, so instead the patch adds >>> an attempt to remove the log file before opening it. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>> >>> Testing: >>> Included test through JPRT >>> >>> Thanks, >>> Marcus >> > From robbin.ehn at oracle.com Fri Mar 11 14:27:56 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 11 Mar 2016 15:27:56 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E14EC2.6010204@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> <56E14EC2.6010204@oracle.com> Message-ID: <56E2D5EC.8000505@oracle.com> Hi, please review this updated changeset. Webrev: http://cr.openjdk.java.net/~rehn/8151264/v2/webrev/ Thanks! /Robbin On 03/10/2016 11:38 AM, Robbin Ehn wrote: > Thanks David for looking at this. > > On 03/10/2016 11:19 AM, David Holmes wrote: >> Hi Robbin, >> >> On 9/03/2016 7:02 PM, Robbin Ehn wrote: >>> >>> Hi, please review this minor change. >> >> A notification mechanism is not so minor - what are the programming >> rules for the callbacks? which threads might execute them? Are there any >> obvious deadlock/livelock potentials? Do we need to unregister a >> callback? >> >> At a minimum there should be some comments regarding the nature of the >> callback and what it can and can't do. > > Yes, I will document it better. > >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ >> >> Some minor nits: >> >> src/share/vm/logging/log.cpp >> >> Copyright needs 2016 added. >> >> --- >> >> src/share/vm/logging/logConfiguration.cpp >> >> + assert(cb != NULL, "Should not initialize register NULL as >> listener."); >> >> "initialize register" doesn't make grammatical sense - delete >> "initialize" >> >> + for (size_t i=0;i<_n_listener_callbacks;i++) { >> >> Style nits: spaces around operators and after ; >> >> --- >> >> src/share/vm/logging/logConfiguration.hpp >> >> + // After any configuration change this method should be called by in >> scope of LogConfigurationLock >> >> Delete 'by' - or may I suggest: >> >> // This should be called after any configuration change while still >> holding ConfigurationLock >> > > Yes, thanks! > > /Robbin > >> Thanks, >> David >> ----- >> >>> Tested with a new internal vm test (included). >>> >>> Thanks! >>> >>> /Robbin From thomas.stuefe at gmail.com Fri Mar 11 14:34:09 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Mar 2016 15:34:09 +0100 Subject: UL: logging before initialization? In-Reply-To: <56E2BFD3.7060306@oracle.com> References: <56E229A8.4020907@oracle.com> <56E27E4D.3060108@oracle.com> <56E2BFD3.7060306@oracle.com> Message-ID: Hi David, On Fri, Mar 11, 2016 at 1:53 PM, David Holmes wrote: > On 11/03/2016 9:22 PM, Thomas St?fe wrote: > >> Hi David, Marcus, >> >> thanks for thinking about this! Please find my comments inline. >> >> On Fri, Mar 11, 2016 at 9:14 AM, Marcus Larsson >> > wrote: >> >> Hi, >> >> On 2016-03-11 03:12, David Holmes wrote: >> >> Hi Thomas, >> >> Expanding to hotspot-dev as UL was not designed/built by the >> runtime team. >> >> My comments below based on my limited understanding of UL. >> >> On 11/03/2016 2:25 AM, Thomas St?fe wrote: >> >> Hi all, >> >> I wanted to use UL to log some information from early OS >> initialization but >> found that we initialize logging quite late. It is >> initialized way after >> os::init() runs. >> >> >> There are various dependencies in the unified logging framework >> that prevent it (or at least parts of it) from being used early >> eg: >> - argument parsing and log configuration >> - existence of current thread (for logStreams) >> >> >> Currently, the framework can be used as soon as static >> initialization is done. This doesn't include the logStreams of >> course since they require resource allocations. The problem is as >> you say that there is no way to configure the logging before parsing >> the -Xlog command. This means up until that point the default >> configuration will apply, which means warnings and errors to stdout. >> >> >> I also see that warnings and errors are printed >> unconditionally even >> before, only log calls for levels <= info are quietly >> swallowed. >> >> >> Are those warnings/errors using UL? I suspect not. >> >> >> They could be, since errors and warnings are enabled by default. >> >> >> They are from UL. I see errors and warnings. Decorators seem to be off >> though, e.g. the timestamp, because they rely on initialization in >> os::init(). But nothing serious which breaks logging as long as one is >> fine with default settings. >> >> >> >> >> Silent swallowing is not good though. >> >> Would there be a way to move UL initialization and parsing >> of -Xlog >> Arguments to an earlier point to be able to use logging in >> os::init()? >> >> >> I don't see how you could utilize tags and levels until after >> full initialization of the logging system, so that would >> preclude using it as early as os::init. >> >> >> It is a possible solution I guess. I don't know how dependent >> argument parsing is on other initialization. There would always be >> some part of the initialization where you only have warning and >> error logging unless we do the parsing first thing during startup, >> which I assume will be impossible. >> >> >> Sure, the logging system must be fully initialized to use it. However, I >> argue that the logging system should be as independent as possible from >> the rest of the VM, so not rely on VM initialization. If that is the >> case - and I think it is now - then logging initialization and -Xlog >> parsing can be moved up in Thread::create_vm() to before os::init(). >> > > You would need to examine the complete transitive closure of logging code > to see if such a move is feasible. > > Not sure I understand. Making sure that the logging system itself does not contain deep VM dependencies should be feasible. If with "logging code" you mean logging calls by the various components, I would think that anyone introducing logging calls should not log anything which is not available at the time the logging call is executed. Or do I not understand? Thomas > I would even argue that if this does not work, it is an error. For >> example, if we were to require Thread::current() to work for >> logging,e.g. for log decorators, this would mean logging breaks if >> Thread::current() is not available. So, if we make the logging system >> work for pre-initialization time, and add regression tests for this, >> this is a pretty good way to keep the logging system healthy and robust >> and avoid too much dependencies into the VM. >> >> I would think that the logging system as it is now is already robust - >> the fact that it works, with default settings, right after static >> initialization is a good sign. So, we could probably move initialization >> and -Xlog parsing to an earlier point with not much work. >> > > While the logging system has taken a number of steps to make itself immune > to some initialization issues (for example "locking" uses a semaphore and > doesn't rely on Thread::current()), different parts of the system have > different dependencies - which seems unavoidable to me. I don't know if it > would be possible to enable a subset of the API earlier in the > initialization sequence by refactoring some of the configuration logic and > argument parsing. > > David > ----- > > > >> Or, if that is not possible, would there be a way to delay >> printing of >> early logging calls to after logging initialization and then >> print them out >> in one go? I think this would be not trivial though: one >> would have to >> collect all logging output in memory somewhere - because we >> do not yet know >> which tags are switched on - and then, once -Xlog is parsed, >> filter it by >> tag before printing it out. >> >> >> Yeah that seems difficult/complex given the problem that the VM >> is in the early stages of initialization >> >> >> I really do not like this solution either, I only added this for >> completeness and to make my first proposal look better in comparison :) >> >> What do you think, would that be a worthwhile change? I am a >> bit unhappy >> about how logging calls are quietly swallowed, so for any >> code which runs >> at VM initialization, one always has to keep in mind that UL >> may not yet be >> initialized. >> >> >> Not a new problem (adding more code during VM initialization) >> but one that is getting more complicated :) >> >> >> I think it would perhaps be worthwhile if there's demand for a bunch >> of info to trace level logging from startup code (before argument >> parsing). >> >> >> At least in the AIX port we have a lot of tracing going on very early. >> For platform porters, OS initialization is a very interesting time. We >> have now a very primitive trace there which I would love to switch to >> UL, but right now the trace output would just be swallowed by >> not-yet-initialized UL. >> >> Thank you, >> >> Thomas >> >> Thanks, >> Marcus >> >> >> >> Cheers, >> David >> >> Kind Regards, Thomas >> >> >> >> From bengt.rutisson at oracle.com Fri Mar 11 14:35:22 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 11 Mar 2016 15:35:22 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D478.3090202@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> Message-ID: <56E2D7AA.1060803@oracle.com> Hi Marcus, On 2016-03-11 15:21, Marcus Larsson wrote: > Third time's the charm. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ I had a quick look at the code changes. It is not really my area of the code, so I'll leave to someone else to formally review it. However, I downloaded the patch a played a bit with the logging. This is much more like the way I would like it! Thanks! So, from a functional perspective this looks good to me. Thanks, Bengt > > This patch makes log file rotation the default. Default thresholds are > 5 rotated files with a target size of 20MiB. Truncating behavior can > be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). > > If a log file already exists during log file initialization it will be > rotated. If any of the target file names (file.0 to file.4 in the > default case) are available, that filename will be used for the > existing log. If all names are taken the VM will attempt to overwrite > the oldest file. > > This should prevent unlimited log file creations and avoid accidental > loss of log files from previous runs. The default thresholds (5 files, > 20MiB each) is just a suggestion. If you think it should be > higher/lower let me know. > > Tested with included internal VM tests through RBT. > > Thanks, > Marcus > > On 2016-03-01 15:05, Marcus Larsson wrote: >> Hi, >> >> After some offline discussions I'm withdrawing this patch. I will >> instead investigate if I can achieve similar behavior using log >> rotation as the default. >> >> Thanks, >> Marcus >> >> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>> Hi again, >>> >>> Taking a different approach to this. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>> >>> Existing files will now by default be renamed/archived with a .X >>> suffix where X is the lowest number such that the resulting file >>> name is available (jvm.log becomes jvm.log.0). A mode option for >>> controlling this behavior has been added as well. It can be set to >>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>> >>> Tested with included jtreg test through JPRT. >>> >>> Thanks, >>> Marcus >>> >>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to make sure UL truncates >>>> existing log files before writing to them. Since files are opened >>>> in append mode, truncation isn't done automatically, so instead the >>>> patch adds an attempt to remove the log file before opening it. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>> >>>> Testing: >>>> Included test through JPRT >>>> >>>> Thanks, >>>> Marcus >>> >> > From marcus.larsson at oracle.com Fri Mar 11 14:39:41 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Mar 2016 15:39:41 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D7AA.1060803@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2D7AA.1060803@oracle.com> Message-ID: <56E2D8AD.8040902@oracle.com> Hi, On 2016-03-11 15:35, Bengt Rutisson wrote: > > Hi Marcus, > > On 2016-03-11 15:21, Marcus Larsson wrote: >> Third time's the charm. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ > > I had a quick look at the code changes. It is not really my area of > the code, so I'll leave to someone else to formally review it. > > However, I downloaded the patch a played a bit with the logging. This > is much more like the way I would like it! Thanks! > > So, from a functional perspective this looks good to me. > Thanks for the feedback! Marcus > Thanks, > Bengt > >> >> This patch makes log file rotation the default. Default thresholds >> are 5 rotated files with a target size of 20MiB. Truncating behavior >> can be achieved by setting filecount to 0 >> (-Xlog::myfile.log::filecount=0). >> >> If a log file already exists during log file initialization it will >> be rotated. If any of the target file names (file.0 to file.4 in the >> default case) are available, that filename will be used for the >> existing log. If all names are taken the VM will attempt to overwrite >> the oldest file. >> >> This should prevent unlimited log file creations and avoid accidental >> loss of log files from previous runs. The default thresholds (5 >> files, 20MiB each) is just a suggestion. If you think it should be >> higher/lower let me know. >> >> Tested with included internal VM tests through RBT. >> >> Thanks, >> Marcus >> >> On 2016-03-01 15:05, Marcus Larsson wrote: >>> Hi, >>> >>> After some offline discussions I'm withdrawing this patch. I will >>> instead investigate if I can achieve similar behavior using log >>> rotation as the default. >>> >>> Thanks, >>> Marcus >>> >>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Taking a different approach to this. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>> >>>> Existing files will now by default be renamed/archived with a .X >>>> suffix where X is the lowest number such that the resulting file >>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>> controlling this behavior has been added as well. It can be set to >>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>> >>>> Tested with included jtreg test through JPRT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to make sure UL truncates >>>>> existing log files before writing to them. Since files are opened >>>>> in append mode, truncation isn't done automatically, so instead >>>>> the patch adds an attempt to remove the log file before opening it. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>> >>>>> Testing: >>>>> Included test through JPRT >>>>> >>>>> Thanks, >>>>> Marcus >>>> >>> >> > From jon.masamitsu at oracle.com Fri Mar 11 15:44:14 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 11 Mar 2016 07:44:14 -0800 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> Message-ID: <56E2E7CE.1080809@oracle.com> On 3/10/2016 12:42 PM, Kim Barrett wrote: >> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu wrote: >> >> >> >> On 03/09/2016 08:53 PM, David Holmes wrote: >>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>> Background: >>>> >>>> After the backport of https://bugs.openjdk.java.net/browse/JDK-8017462, The flag -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the _workers to null in 8u. >>>> >>>> As there is no condition to handle such scenario in share/vm/memory/sharedHeap.cpp, which causes the crash. >>>> >>>> The similar condition is already implemented for following scenarios >>>> >>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>> >>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>> >>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>> >>>> >>>> >>>> Fix: >>>> >>>> Condition check is added in src/share/vm/runtime/arguments.cpp file to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>> >>>> Thanks for the base patch from Jon. >>>> >>>> Due to this patch it makes some of the test cases absolute. They have been removed. >>>> >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>> >>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>> This existing code looks wrong: >>> >>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>> 1677 if (ParallelGCThreads == 0) { >>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>> >>> Line 1678 seems to do the same as 1675 - is Abstract_VM_Version::parallel_worker_threads() somehow expected to return a different value on the second call ?? >> No, Abstract_VM_Version::parallel_worker_threads() won't return a different >> value for a second call. It's harmless but would be cleaner deleting 1675,1676. I retract this suggestion to delete 1675-1676. I'll 99.99% sure that it would be OK, but argument processing being what it is and this being an update fix, leave those lines in. I've been surprised before. > The retry setting to parallel_worker_threads() again code dates back to the initial G1 checkin. Hard to know what was intended. > > The current jdk9 code does not have that: it looks like > > FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); > if (ParallelGCThreads == 0) { > assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value for ParallelGCThreads should not be 0."); > vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); > } > > This proposed change is for jdk8u-something, correct? > > In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be seen above. Making use of that decision, a cleanup pass was made that eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend it?s 1 or do some other special thing? code. The backport of 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken that into account. For example, > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 > --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb 17 13:42:03 2016 +0000 > +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb 18 20:30:45 2016 +0000 > @@ -3991,8 +3991,15 @@ > > TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); > > - uint active_workers = (G1CollectedHeap::use_parallel_gc_threads() ? > - workers()->active_workers() : 1); > + uint active_workers = AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), > + workers()->active_workers(), > + Threads::number_of_non_daemon_threads()); > > Note the conditionalization on use_parallel_gc_threads(). > > It might be that the simplest thing to do for 8u backporting is indeed to backport prevention of ParallelGCThreads == 0, as suggested in the proposed patch. I agree although I'll also respond to Thomas next. Jon > > > From robbin.ehn at oracle.com Fri Mar 11 15:50:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 11 Mar 2016 16:50:51 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D478.3090202@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> Message-ID: <56E2E95B.8050500@oracle.com> Hi Marcus, Two small things. src/share/vm/runtime/os.hpp: + static int compare_file_modified_times(const char* file1, const char* file2); Is this so generic that we should have it os.[h,c]pp? E.g. if we want to compare ctime, etc.. ? On 03/11/2016 03:21 PM, Marcus Larsson wrote: > Third time's the charm. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ > > This patch makes log file rotation the default. Default thresholds are 5 > rotated files with a target size of 20MiB. Truncating behavior can be > achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). src/share/vm/logging/logFileOutput.hpp: + static const size_t DefaultRotationFileSize = 2097152; // 20MiB Missing a 0 here, I prefer to write this as 20*1024*1024 > > If a log file already exists during log file initialization it will be > rotated. If any of the target file names (file.0 to file.4 in the > default case) are available, that filename will be used for the existing > log. If all names are taken the VM will attempt to overwrite the oldest > file. > > This should prevent unlimited log file creations and avoid accidental > loss of log files from previous runs. The default thresholds (5 files, > 20MiB each) is just a suggestion. If you think it should be higher/lower > let me know. > > Tested with included internal VM tests through RBT. I also functional tested this and it works as intended. There is an issue regarding removing the current log file. Discussed in side-channel it will be handled outside this CS since it not directly related. Otherwise looks good! /Robbin > > Thanks, > Marcus > > On 2016-03-01 15:05, Marcus Larsson wrote: >> Hi, >> >> After some offline discussions I'm withdrawing this patch. I will >> instead investigate if I can achieve similar behavior using log >> rotation as the default. >> >> Thanks, >> Marcus >> >> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>> Hi again, >>> >>> Taking a different approach to this. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>> >>> Existing files will now by default be renamed/archived with a .X >>> suffix where X is the lowest number such that the resulting file name >>> is available (jvm.log becomes jvm.log.0). A mode option for >>> controlling this behavior has been added as well. It can be set to >>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>> >>> Tested with included jtreg test through JPRT. >>> >>> Thanks, >>> Marcus >>> >>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to make sure UL truncates existing >>>> log files before writing to them. Since files are opened in append >>>> mode, truncation isn't done automatically, so instead the patch adds >>>> an attempt to remove the log file before opening it. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>> >>>> Testing: >>>> Included test through JPRT >>>> >>>> Thanks, >>>> Marcus >>> >> > From jon.masamitsu at oracle.com Fri Mar 11 15:59:28 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 11 Mar 2016 07:59:28 -0800 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <1457642805.2363.5.camel@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <1457642805.2363.5.camel@oracle.com> Message-ID: <56E2EB60.6080507@oracle.com> On 3/10/2016 12:46 PM, Thomas Schatzl wrote: > Hi, > > On Thu, 2016-03-10 at 15:42 -0500, Kim Barrett wrote: >>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu < >>> jon.masamitsu at oracle.com> wrote: >>> >>> >>> > [...] >> The retry setting to parallel_worker_threads() again code dates back >> to the initial G1 checkin. Hard to know what was intended. >> >> The current jdk9 code does not have that: it looks like >> >> FLAG_SET_DEFAULT(ParallelGCThreads, >> Abstract_VM_Version::parallel_worker_threads()); >> if (ParallelGCThreads == 0) { >> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >> for ParallelGCThreads should not be 0."); >> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >> combined with -XX:ParallelGCThreads=0", NULL); >> } >> >> This proposed change is for jdk8u-something, correct? >> >> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >> seen above. Making use of that decision, a cleanup pass was made >> that eliminated a whole bunch of ?if (ParallelGCThreads == 0) then >> pretend it?s 1 or do some other special thing? code. The backport of >> 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken >> that into account. For example, > just some historical note: in 8u, ParallelGCThreads == 0 means "use the > VM thread, single threaded", and ParallelGCThreads == 1 means use a > single worker thread. By "VM thread, single threaded" I believe you mean that we used the serial version (no threading code) and let the VM execute it. I recall this being the case with some ParNew code. > In jdk9 we removed that option to use the vm thread in a single > threaded way. > > We did not backport that change because of potential performance impact > (whatever that might be). This can be fixed while leaving the ParallelGCThreads == 0 as an option for G1. In the 8u it is no longer an option for ParNew nor ParallelGC (both prohibit ParallelGCThreads == 0 in the argument processing). How about we make G1 like the other collectors in 8u and prohibit ParallelGCThreads == 0. That would be the simplest and most consistent thing to do (in my opinion). Jon > > Thanks, > Thomas > From max.ockner at oracle.com Fri Mar 11 16:14:27 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 11 Mar 2016 11:14:27 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E1FA50.4090905@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> <56E1FA50.4090905@oracle.com> Message-ID: <56E2EEE3.6090705@oracle.com> Ioi, Thanks for your comments. I have made the change you suggested, and it is reflected in the test. webrev: http://cr.openjdk.java.net/~mockner/8149995.04/ Thanks, Max On 3/10/2016 5:50 PM, Ioi Lam wrote: > Hi Max, > > The changes look good. I just have one comment: > > $ java -Xlog:classload | less > [0.108s][info][classload] java.lang.Object source: > /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage > ... > > For consistency, I think the preorder output should us the same style. > I.e., remove "loading" and replace "from" to "source:" > > 5686 if (!is_internal()) { > 5687 if (log_is_enabled(Debug, classload, preorder)){ > 5688 ResourceMark rm(THREAD); > 5689 outputStream* log = LogHandle(classload, > preorder)::debug_stream(); > 5690 log->print("loading %s", > _class_name->as_klass_external_name()); > 5691 if (stream->source() != NULL) { > 5692 log->print(" from %s", stream->source()); > 5693 } > 5694 log->cr(); > 5695 } > 5696 > > Thanks > - Ioi > > > On 3/10/16 10:22 AM, Max Ockner wrote: >> Hello, >> >> I have responded to these comments. >> >> webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ >> - classloadingpreorder replaced by classload+preorder >> - In order to support aliasing to a log configuration with multiple >> tags, the logging alias table is expanded to fit the output of the >> LOG_TAGS(tag) macro. >> - comment in metaspaceShared is changed to classload+preorder. >> >> Thanks, >> Max >> >> On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >>> >>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >>> >>> >>> We talked about this but I've changed my opinion. I think looking >>> at this in the code, it might make more sense to make this >>> log(classload, preorder) since anyone knowing about this option will >>> know to specify both tags. I think it's used for CDS. Will this >>> work for the aliasing table? If not, I think the tag is better >>> classloadpreorder >>> >>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >>> >>> >>> The comment is wrong, it says classloaderpreorder, rather than >>> classloadingpreorder. >>> >>> thanks, >>> Coleen >>> >>> On 3/9/16 12:10 PM, Max Ockner wrote: >>>> Hello again! >>>> >>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>>> >>>> Thanks, >>>> Max >>>> >>>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>>> Hey, Max, >>>>> >>>>> Looks good. Just a few comments: >>>>> >>>>> In src/share/vm/classfile/classFileParser.cpp should this have a >>>>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>>>> farther up in the scope, but in case someone were to delete it >>>>> later, it might make sense to have a more local one? Not sure what >>>>> the standard is on this. >>>>> >>>>> Also I think you forgot to delete the option from >>>>> runtime/globals.hpp. >>>>> >>>>> Thanks, >>>>> Rachel >>>>> >>>>> >>>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small Unified Logging change. >>>>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>>>> level. Debug level was chosen since there are 342 lines of output >>>>>> for java -version. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>>> >>>>>> Tested with jtreg runtime tests. >>>>>> No existing tests reference TraceClassLoadingPreorder from >>>>>> hotspot/test or jdk/test. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>> >>>> >>> >> > From gerard.ziemski at oracle.com Fri Mar 11 16:40:47 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 11 Mar 2016 10:40:47 -0600 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D478.3090202@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> Message-ID: hi Marcus, I?m still going through the webrev, but I thought I would report my feedback so far. ------------------------------------------------ #1 File src/os/posix/vm/os_posix.cpp How about instead of: +int os::compare_file_modified_times(const char* file1, const char* file2) { + struct stat st[2]; + struct timespec filetime[2]; + + for (int i = 0; i < 2; i++) { + const char* file = (i == 0 ? file1 : file2); + int ret = os::stat(file, &st[i]); + assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno)); +#ifdef __APPLE__ + filetime[i] = st[i].st_mtimespec; +#else + filetime[i] = st[i].st_mtim; +#endif + } + + int diff = filetime[0].tv_sec - filetime[1].tv_sec; + if (diff == 0) { + return filetime[0].tv_nsec - filetime[1].tv_nsec; + } + return diff; +} we have something like this, which doesn?t use arrays or a loop mimicking inline function: static inline struct timespec get_timespec(const char* file) { struct stat st; int ret = stat(file, &st); assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno)); #ifdef __APPLE__ return st.st_mtimespec; #else return st.st_mtim; #endif } int compare_file_modified_times(const char* file1, const char* file2) { struct timespec filetime1 = get_timespec(file1); struct timespec filetime2 = get_timespec(file2); int diff = filetime1.tv_sec - filetime2.tv_sec; if (diff == 0) { return filetime1.tv_nsec - filetime2.tv_nsec; } return diff; } Similarly we should use static inline function instead of a loop in src/os/windows/vm/os_windows.cpp ----------------------------------------------- #2 File src/share/vm/logging/log.cpp Doesn?t this function produce an error or at least a warning on a product build without asserts? +static void delete_file(const char* filename) { + if (!file_exists(filename)) { + return; + } + int ret = remove(filename); + assert(ret == 0, "failed to remove file '%s': %s", filename, strerror(errno)); +} ----------------------------------------------- #3 File src/share/vm/logging/log.cpp The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with: char buf[16]; and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard") ----------------------------------------------- #4 File src/share/vm/logging/log.cpp Should we clarify that we are rounding the results of log10 down by explicitly using floor and explicitly casting it to uint? static uint number_of_digits_new(uint number) { double d = static_cast(number); uint res = 1 + static_cast(floor(log10(d))); return res; } cheers > On Mar 11, 2016, at 8:21 AM, Marcus Larsson wrote: > > Third time's the charm. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ > > This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). > > If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. > > This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. > > Tested with included internal VM tests through RBT. > > Thanks, > Marcus > > On 2016-03-01 15:05, Marcus Larsson wrote: >> Hi, >> >> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >> >> Thanks, >> Marcus >> >> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>> Hi again, >>> >>> Taking a different approach to this. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>> >>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>> >>> Tested with included jtreg test through JPRT. >>> >>> Thanks, >>> Marcus >>> >>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>> >>>> Testing: >>>> Included test through JPRT >>>> >>>> Thanks, >>>> Marcus >>> >> > From ioi.lam at oracle.com Fri Mar 11 18:13:34 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 11 Mar 2016 10:13:34 -0800 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E2EEE3.6090705@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> <56E1FA50.4090905@oracle.com> <56E2EEE3.6090705@oracle.com> Message-ID: <56E30ACE.3040304@oracle.com> Hi Max, The code change looks good. Did you forget to include the test in the webrev? Thanks - Ioi On 3/11/16 8:14 AM, Max Ockner wrote: > Ioi, > > Thanks for your comments. I have made the change you suggested, and it > is reflected in the test. > webrev: http://cr.openjdk.java.net/~mockner/8149995.04/ > > Thanks, > Max > > On 3/10/2016 5:50 PM, Ioi Lam wrote: >> Hi Max, >> >> The changes look good. I just have one comment: >> >> $ java -Xlog:classload | less >> [0.108s][info][classload] java.lang.Object source: >> /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage >> ... >> >> For consistency, I think the preorder output should us the same >> style. I.e., remove "loading" and replace "from" to "source:" >> >> 5686 if (!is_internal()) { >> 5687 if (log_is_enabled(Debug, classload, preorder)){ >> 5688 ResourceMark rm(THREAD); >> 5689 outputStream* log = LogHandle(classload, >> preorder)::debug_stream(); >> 5690 log->print("loading %s", >> _class_name->as_klass_external_name()); >> 5691 if (stream->source() != NULL) { >> 5692 log->print(" from %s", stream->source()); >> 5693 } >> 5694 log->cr(); >> 5695 } >> 5696 >> >> Thanks >> - Ioi >> >> >> On 3/10/16 10:22 AM, Max Ockner wrote: >>> Hello, >>> >>> I have responded to these comments. >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ >>> - classloadingpreorder replaced by classload+preorder >>> - In order to support aliasing to a log configuration with multiple >>> tags, the logging alias table is expanded to fit the output of the >>> LOG_TAGS(tag) macro. >>> - comment in metaspaceShared is changed to classload+preorder. >>> >>> Thanks, >>> Max >>> >>> On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >>>> >>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>> >>>> >>>> We talked about this but I've changed my opinion. I think looking >>>> at this in the code, it might make more sense to make this >>>> log(classload, preorder) since anyone knowing about this option >>>> will know to specify both tags. I think it's used for CDS. Will >>>> this work for the aliasing table? If not, I think the tag is better >>>> classloadpreorder >>>> >>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >>>> >>>> >>>> The comment is wrong, it says classloaderpreorder, rather than >>>> classloadingpreorder. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 3/9/16 12:10 PM, Max Ockner wrote: >>>>> Hello again! >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>>>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>>>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>>>> Hey, Max, >>>>>> >>>>>> Looks good. Just a few comments: >>>>>> >>>>>> In src/share/vm/classfile/classFileParser.cpp should this have a >>>>>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>>>>> farther up in the scope, but in case someone were to delete it >>>>>> later, it might make sense to have a more local one? Not sure >>>>>> what the standard is on this. >>>>>> >>>>>> Also I think you forgot to delete the option from >>>>>> runtime/globals.hpp. >>>>>> >>>>>> Thanks, >>>>>> Rachel >>>>>> >>>>>> >>>>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this small Unified Logging change. >>>>>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>>>>> level. Debug level was chosen since there are 342 lines of >>>>>>> output for java -version. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>>>> >>>>>>> Tested with jtreg runtime tests. >>>>>>> No existing tests reference TraceClassLoadingPreorder from >>>>>>> hotspot/test or jdk/test. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>> >>>>> >>>> >>> >> > From max.ockner at oracle.com Fri Mar 11 18:46:31 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 11 Mar 2016 13:46:31 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E30ACE.3040304@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> <56E1FA50.4090905@oracle.com> <56E2EEE3.6090705@oracle.com> <56E30ACE.3040304@oracle.com> Message-ID: <56E31287.4090504@oracle.com> Yes I did forget the test. It should be there now. http://cr.openjdk.java.net/~mockner/8149995.04/test/runtime/logging/ClassLoadPreorderTest.java.html Thanks, Max On 3/11/2016 1:13 PM, Ioi Lam wrote: > Hi Max, > > The code change looks good. Did you forget to include the test in the > webrev? > > Thanks > - Ioi > > On 3/11/16 8:14 AM, Max Ockner wrote: >> Ioi, >> >> Thanks for your comments. I have made the change you suggested, and >> it is reflected in the test. >> webrev: http://cr.openjdk.java.net/~mockner/8149995.04/ >> >> Thanks, >> Max >> >> On 3/10/2016 5:50 PM, Ioi Lam wrote: >>> Hi Max, >>> >>> The changes look good. I just have one comment: >>> >>> $ java -Xlog:classload | less >>> [0.108s][info][classload] java.lang.Object source: >>> /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage >>> ... >>> >>> For consistency, I think the preorder output should us the same >>> style. I.e., remove "loading" and replace "from" to "source:" >>> >>> 5686 if (!is_internal()) { >>> 5687 if (log_is_enabled(Debug, classload, preorder)){ >>> 5688 ResourceMark rm(THREAD); >>> 5689 outputStream* log = LogHandle(classload, >>> preorder)::debug_stream(); >>> 5690 log->print("loading %s", >>> _class_name->as_klass_external_name()); >>> 5691 if (stream->source() != NULL) { >>> 5692 log->print(" from %s", stream->source()); >>> 5693 } >>> 5694 log->cr(); >>> 5695 } >>> 5696 >>> >>> Thanks >>> - Ioi >>> >>> >>> On 3/10/16 10:22 AM, Max Ockner wrote: >>>> Hello, >>>> >>>> I have responded to these comments. >>>> >>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ >>>> - classloadingpreorder replaced by classload+preorder >>>> - In order to support aliasing to a log configuration with >>>> multiple tags, the logging alias table is expanded to fit the >>>> output of the LOG_TAGS(tag) macro. >>>> - comment in metaspaceShared is changed to classload+preorder. >>>> >>>> Thanks, >>>> Max >>>> >>>> On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >>>>> >>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>>> >>>>> >>>>> We talked about this but I've changed my opinion. I think >>>>> looking at this in the code, it might make more sense to make this >>>>> log(classload, preorder) since anyone knowing about this option >>>>> will know to specify both tags. I think it's used for CDS. Will >>>>> this work for the aliasing table? If not, I think the tag is >>>>> better classloadpreorder >>>>> >>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >>>>> >>>>> >>>>> The comment is wrong, it says classloaderpreorder, rather than >>>>> classloadingpreorder. >>>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 3/9/16 12:10 PM, Max Ockner wrote: >>>>>> Hello again! >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>>>>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>>>>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>>>>> Hey, Max, >>>>>>> >>>>>>> Looks good. Just a few comments: >>>>>>> >>>>>>> In src/share/vm/classfile/classFileParser.cpp should this have a >>>>>>> ResourceMark rm(THREAD) at 5688? I realize there is probably one >>>>>>> farther up in the scope, but in case someone were to delete it >>>>>>> later, it might make sense to have a more local one? Not sure >>>>>>> what the standard is on this. >>>>>>> >>>>>>> Also I think you forgot to delete the option from >>>>>>> runtime/globals.hpp. >>>>>>> >>>>>>> Thanks, >>>>>>> Rachel >>>>>>> >>>>>>> >>>>>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this small Unified Logging change. >>>>>>>> TraceClassLoadingPreorder has been converted to UL at the Debug >>>>>>>> level. Debug level was chosen since there are 342 lines of >>>>>>>> output for java -version. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>>>>> >>>>>>>> Tested with jtreg runtime tests. >>>>>>>> No existing tests reference TraceClassLoadingPreorder from >>>>>>>> hotspot/test or jdk/test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>> >>>>>> >>>>> >>>> >>> >> > From ioi.lam at oracle.com Fri Mar 11 19:31:16 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 11 Mar 2016 11:31:16 -0800 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E31287.4090504@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> <56E1FA50.4090905@oracle.com> <56E2EEE3.6090705@oracle.com> <56E30ACE.3040304@oracle.com> <56E31287.4090504@oracle.com> Message-ID: <56E31D04.9090804@oracle.com> Looks good. Thanks! - Ioi On 3/11/16 10:46 AM, Max Ockner wrote: > Yes I did forget the test. It should be there now. > > http://cr.openjdk.java.net/~mockner/8149995.04/test/runtime/logging/ClassLoadPreorderTest.java.html > > > Thanks, > Max > > > On 3/11/2016 1:13 PM, Ioi Lam wrote: >> Hi Max, >> >> The code change looks good. Did you forget to include the test in the >> webrev? >> >> Thanks >> - Ioi >> >> On 3/11/16 8:14 AM, Max Ockner wrote: >>> Ioi, >>> >>> Thanks for your comments. I have made the change you suggested, and >>> it is reflected in the test. >>> webrev: http://cr.openjdk.java.net/~mockner/8149995.04/ >>> >>> Thanks, >>> Max >>> >>> On 3/10/2016 5:50 PM, Ioi Lam wrote: >>>> Hi Max, >>>> >>>> The changes look good. I just have one comment: >>>> >>>> $ java -Xlog:classload | less >>>> [0.108s][info][classload] java.lang.Object source: >>>> /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage >>>> ... >>>> >>>> For consistency, I think the preorder output should us the same >>>> style. I.e., remove "loading" and replace "from" to "source:" >>>> >>>> 5686 if (!is_internal()) { >>>> 5687 if (log_is_enabled(Debug, classload, preorder)){ >>>> 5688 ResourceMark rm(THREAD); >>>> 5689 outputStream* log = LogHandle(classload, >>>> preorder)::debug_stream(); >>>> 5690 log->print("loading %s", >>>> _class_name->as_klass_external_name()); >>>> 5691 if (stream->source() != NULL) { >>>> 5692 log->print(" from %s", stream->source()); >>>> 5693 } >>>> 5694 log->cr(); >>>> 5695 } >>>> 5696 >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 3/10/16 10:22 AM, Max Ockner wrote: >>>>> Hello, >>>>> >>>>> I have responded to these comments. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ >>>>> - classloadingpreorder replaced by classload+preorder >>>>> - In order to support aliasing to a log configuration with >>>>> multiple tags, the logging alias table is expanded to fit the >>>>> output of the LOG_TAGS(tag) macro. >>>>> - comment in metaspaceShared is changed to classload+preorder. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>>>> >>>>>> >>>>>> We talked about this but I've changed my opinion. I think >>>>>> looking at this in the code, it might make more sense to make >>>>>> this log(classload, preorder) since anyone knowing about this >>>>>> option will know to specify both tags. I think it's used for >>>>>> CDS. Will this work for the aliasing table? If not, I think the >>>>>> tag is better classloadpreorder >>>>>> >>>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >>>>>> >>>>>> >>>>>> The comment is wrong, it says classloaderpreorder, rather than >>>>>> classloadingpreorder. >>>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/9/16 12:10 PM, Max Ockner wrote: >>>>>>> Hello again! >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>>>>>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>>>>>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>>>>>> Hey, Max, >>>>>>>> >>>>>>>> Looks good. Just a few comments: >>>>>>>> >>>>>>>> In src/share/vm/classfile/classFileParser.cpp should this have >>>>>>>> a ResourceMark rm(THREAD) at 5688? I realize there is probably >>>>>>>> one farther up in the scope, but in case someone were to delete >>>>>>>> it later, it might make sense to have a more local one? Not >>>>>>>> sure what the standard is on this. >>>>>>>> >>>>>>>> Also I think you forgot to delete the option from >>>>>>>> runtime/globals.hpp. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rachel >>>>>>>> >>>>>>>> >>>>>>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this small Unified Logging change. >>>>>>>>> TraceClassLoadingPreorder has been converted to UL at the >>>>>>>>> Debug level. Debug level was chosen since there are 342 lines >>>>>>>>> of output for java -version. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>>>>>> >>>>>>>>> Tested with jtreg runtime tests. >>>>>>>>> No existing tests reference TraceClassLoadingPreorder from >>>>>>>>> hotspot/test or jdk/test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From dmitry.dmitriev at oracle.com Fri Mar 11 20:46:29 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 11 Mar 2016 23:46:29 +0300 Subject: RFR (M): 8142510: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> Message-ID: <56E32EA5.6050602@oracle.com> Hi Gerard, Few comments, otherwise looks good. Thank you for doing that! 1) src/share/vm/runtime/globals.cpp I think that it's unnecessary to declare string_length and range_string as static in create_range_str function. 2) src/share/vm/runtime/commandLineFlagConstraintList.cpp New function CommandLineFlagConstraintList::find looks very similar to the existing one CommandLineFlagConstraintList::find_if_needs_check. I think that you can remove duplicated logic by refactoring CommandLineFlagConstraintList::find_if_needs_check as follows: CommandLineFlagConstraint* CommandLineFlagConstraintList::find_if_needs_check(const char* name) { CommandLineFlagConstraint* found = find(name); if ((found != NULL) && (found->type() > _validating_type)) { *** Please add appropriate comment here, why found is set back to NULL *** found = NULL; } return found; } Thanks, Dmitry On 09.03.2016 20:33, Gerard Ziemski wrote: > hi all, > > Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) > > bug https://bugs.openjdk.java.net/browse/JDK-8142510 > webrev http://cr.openjdk.java.net/~gziemski/8142510_rev0 > > tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation > > > cheers From coleen.phillimore at oracle.com Fri Mar 11 21:09:10 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 16:09:10 -0500 Subject: RFR (xs) 8151728: jni test crashes JVM assert(_handle != __null) failed: resolving NULL handle Message-ID: <56E333F6.6030706@oracle.com> Summary: New assert needs to check for null. If there's an OOM during Throwable.backtrace creation, the backtrace can be null, so the BacktraceIterator() checks for null, but the assert I added didn't. Retested on failing test, Throwable tests and instrumented VM to force this (removed instrumentation). open webrev at http://cr.openjdk.java.net/~coleenp/8151728/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8151728 Thanks, Coleen From harold.seigel at oracle.com Fri Mar 11 21:12:02 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 11 Mar 2016 16:12:02 -0500 Subject: RFR (xs) 8151728: jni test crashes JVM assert(_handle != __null) failed: resolving NULL handle In-Reply-To: <56E333F6.6030706@oracle.com> References: <56E333F6.6030706@oracle.com> Message-ID: <56E334A2.601@oracle.com> Looks good. Harold On 3/11/2016 4:09 PM, Coleen Phillimore wrote: > Summary: New assert needs to check for null. > > If there's an OOM during Throwable.backtrace creation, the backtrace > can be null, so the BacktraceIterator() checks for null, but the > assert I added didn't. > > Retested on failing test, Throwable tests and instrumented VM to force > this (removed instrumentation). > > open webrev at http://cr.openjdk.java.net/~coleenp/8151728/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8151728 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Fri Mar 11 21:21:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 16:21:57 -0500 Subject: RFR: 8149995: TraceClassLoadingPreorder has been converted to Unified Logging. In-Reply-To: <56E31D04.9090804@oracle.com> References: <56DED4A1.6070208@oracle.com> <56DF2E4D.6020706@oracle.com> <56E05902.6070406@oracle.com> <56E0B89B.5070603@oracle.com> <56E1BB81.8000705@oracle.com> <56E1FA50.4090905@oracle.com> <56E2EEE3.6090705@oracle.com> <56E30ACE.3040304@oracle.com> <56E31287.4090504@oracle.com> <56E31D04.9090804@oracle.com> Message-ID: <56E336F5.5060502@oracle.com> Still looks good to me. Coleen On 3/11/16 2:31 PM, Ioi Lam wrote: > Looks good. Thanks! > > - Ioi > > On 3/11/16 10:46 AM, Max Ockner wrote: >> Yes I did forget the test. It should be there now. >> >> http://cr.openjdk.java.net/~mockner/8149995.04/test/runtime/logging/ClassLoadPreorderTest.java.html >> >> >> Thanks, >> Max >> >> >> On 3/11/2016 1:13 PM, Ioi Lam wrote: >>> Hi Max, >>> >>> The code change looks good. Did you forget to include the test in >>> the webrev? >>> >>> Thanks >>> - Ioi >>> >>> On 3/11/16 8:14 AM, Max Ockner wrote: >>>> Ioi, >>>> >>>> Thanks for your comments. I have made the change you suggested, and >>>> it is reflected in the test. >>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.04/ >>>> >>>> Thanks, >>>> Max >>>> >>>> On 3/10/2016 5:50 PM, Ioi Lam wrote: >>>>> Hi Max, >>>>> >>>>> The changes look good. I just have one comment: >>>>> >>>>> $ java -Xlog:classload | less >>>>> [0.108s][info][classload] java.lang.Object source: >>>>> /jdk/bld/jdk9_rt/images/jdk/lib/modules/bootmodules.jimage >>>>> ... >>>>> >>>>> For consistency, I think the preorder output should us the same >>>>> style. I.e., remove "loading" and replace "from" to "source:" >>>>> >>>>> 5686 if (!is_internal()) { >>>>> 5687 if (log_is_enabled(Debug, classload, preorder)){ >>>>> 5688 ResourceMark rm(THREAD); >>>>> 5689 outputStream* log = LogHandle(classload, >>>>> preorder)::debug_stream(); >>>>> 5690 log->print("loading %s", >>>>> _class_name->as_klass_external_name()); >>>>> 5691 if (stream->source() != NULL) { >>>>> 5692 log->print(" from %s", stream->source()); >>>>> 5693 } >>>>> 5694 log->cr(); >>>>> 5695 } >>>>> 5696 >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 3/10/16 10:22 AM, Max Ockner wrote: >>>>>> Hello, >>>>>> >>>>>> I have responded to these comments. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.03/ >>>>>> - classloadingpreorder replaced by classload+preorder >>>>>> - In order to support aliasing to a log configuration with >>>>>> multiple tags, the logging alias table is expanded to fit the >>>>>> output of the LOG_TAGS(tag) macro. >>>>>> - comment in metaspaceShared is changed to classload+preorder. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 3/9/2016 6:58 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/classfile/classFileParser.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> We talked about this but I've changed my opinion. I think >>>>>>> looking at this in the code, it might make more sense to make >>>>>>> this log(classload, preorder) since anyone knowing about this >>>>>>> option will know to specify both tags. I think it's used for >>>>>>> CDS. Will this work for the aliasing table? If not, I think the >>>>>>> tag is better classloadpreorder >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mockner/8149995.02/src/share/vm/memory/metaspaceShared.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> The comment is wrong, it says classloaderpreorder, rather than >>>>>>> classloadingpreorder. >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/9/16 12:10 PM, Max Ockner wrote: >>>>>>>> Hello again! >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995.02/ >>>>>>>> - Added "ResourceMark rm(THREAD);" in classFileParser.cpp >>>>>>>> - Deleted TraceClassLoadingPreorder flag from globals.hpp >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 3/8/2016 2:55 PM, Rachel Protacio wrote: >>>>>>>>> Hey, Max, >>>>>>>>> >>>>>>>>> Looks good. Just a few comments: >>>>>>>>> >>>>>>>>> In src/share/vm/classfile/classFileParser.cpp should this have >>>>>>>>> a ResourceMark rm(THREAD) at 5688? I realize there is probably >>>>>>>>> one farther up in the scope, but in case someone were to >>>>>>>>> delete it later, it might make sense to have a more local one? >>>>>>>>> Not sure what the standard is on this. >>>>>>>>> >>>>>>>>> Also I think you forgot to delete the option from >>>>>>>>> runtime/globals.hpp. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rachel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/8/2016 8:33 AM, Max Ockner wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review this small Unified Logging change. >>>>>>>>>> TraceClassLoadingPreorder has been converted to UL at the >>>>>>>>>> Debug level. Debug level was chosen since there are 342 lines >>>>>>>>>> of output for java -version. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149995 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149995/ >>>>>>>>>> >>>>>>>>>> Tested with jtreg runtime tests. >>>>>>>>>> No existing tests reference TraceClassLoadingPreorder from >>>>>>>>>> hotspot/test or jdk/test. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Mar 11 21:24:01 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 16:24:01 -0500 Subject: RFR (xs) 8151728: jni test crashes JVM assert(_handle != __null) failed: resolving NULL handle In-Reply-To: <56E334A2.601@oracle.com> References: <56E333F6.6030706@oracle.com> <56E334A2.601@oracle.com> Message-ID: <56E33771.8070304@oracle.com> Thanks for reviewing this so quickly, Harold. I'll wait a little and check it in under the "trivial change rule". Coleen On 3/11/16 4:12 PM, harold seigel wrote: > Looks good. > > Harold > > On 3/11/2016 4:09 PM, Coleen Phillimore wrote: >> Summary: New assert needs to check for null. >> >> If there's an OOM during Throwable.backtrace creation, the backtrace >> can be null, so the BacktraceIterator() checks for null, but the >> assert I added didn't. >> >> Retested on failing test, Throwable tests and instrumented VM to >> force this (removed instrumentation). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8151728/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8151728 >> >> Thanks, >> Coleen >> > From george.triantafillou at oracle.com Fri Mar 11 22:03:40 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 11 Mar 2016 17:03:40 -0500 Subject: RFR (xs) 8151728: jni test crashes JVM assert(_handle != __null) failed: resolving NULL handle In-Reply-To: <56E333F6.6030706@oracle.com> References: <56E333F6.6030706@oracle.com> Message-ID: <56E340BC.4060403@oracle.com> Hi Coleen, Change look good. -George On 3/11/2016 4:09 PM, Coleen Phillimore wrote: > Summary: New assert needs to check for null. > > If there's an OOM during Throwable.backtrace creation, the backtrace > can be null, so the BacktraceIterator() checks for null, but the > assert I added didn't. > > Retested on failing test, Throwable tests and instrumented VM to force > this (removed instrumentation). > > open webrev at http://cr.openjdk.java.net/~coleenp/8151728/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8151728 > > Thanks, > Coleen > From coleen.phillimore at oracle.com Fri Mar 11 22:23:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 17:23:59 -0500 Subject: RFR (xs) 8151728: jni test crashes JVM assert(_handle != __null) failed: resolving NULL handle In-Reply-To: <56E340BC.4060403@oracle.com> References: <56E333F6.6030706@oracle.com> <56E340BC.4060403@oracle.com> Message-ID: <56E3457F.6070200@oracle.com> Thanks you for reviewing, George. It's already being checked in so I can't credit you. Coleen On 3/11/16 5:03 PM, George Triantafillou wrote: > Hi Coleen, > > Change look good. > > -George > > On 3/11/2016 4:09 PM, Coleen Phillimore wrote: >> Summary: New assert needs to check for null. >> >> If there's an OOM during Throwable.backtrace creation, the backtrace >> can be null, so the BacktraceIterator() checks for null, but the >> assert I added didn't. >> >> Retested on failing test, Throwable tests and instrumented VM to >> force this (removed instrumentation). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8151728/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8151728 >> >> Thanks, >> Coleen >> > From aleksey.shipilev at oracle.com Fri Mar 11 23:36:29 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Mar 2016 02:36:29 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56DE06EF.7040408@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <56DE06EF.7040408@oracle.com> Message-ID: <56E3567D.8010807@oracle.com> On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >> Aside: see the last experiment, avoiding StringTable::intern (shows in >> profiles a lot!) trims down construction costs down even further. I'd >> think that is a worthwhile improvement to consider. > > Hm, this is an interesting experiment. I've been looking for a better > way to store the name of the method rather than cpref. I did some preliminary work for storing class names (those are easy, since Class.name is already there on Java side). Would be nice to handle both method names and source files, because we are looking at some nice improvements: https://bugs.openjdk.java.net/browse/JDK-8151751 Can you pick it up, and follow up further? Cheers, -Aleksey From coleen.phillimore at oracle.com Fri Mar 11 23:49:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Mar 2016 18:49:24 -0500 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E3567D.8010807@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <56DE06EF.7040408@oracle.com> <56E3567D.8010807@oracle.com> Message-ID: <56E35984.7030806@oracle.com> On 3/11/16 6:36 PM, Aleksey Shipilev wrote: > On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >>> Aside: see the last experiment, avoiding StringTable::intern (shows in >>> profiles a lot!) trims down construction costs down even further. I'd >>> think that is a worthwhile improvement to consider. >> Hm, this is an interesting experiment. I've been looking for a better >> way to store the name of the method rather than cpref. > I did some preliminary work for storing class names (those are easy, > since Class.name is already there on Java side). Would be nice to handle > both method names and source files, because we are looking at some nice > improvements: > https://bugs.openjdk.java.net/browse/JDK-8151751 > > Can you pick it up, and follow up further? Yes, I think caching String classname on Class might be also helpful for the StackWalk API. My impression was that the performance of Throwable.getStackTrace() wasn't super critical since it's used in exceptional conditions. Let me know otherwise. I linked the bug I care about to this. thanks, Coleen > > Cheers, > -Aleksey > From aleksey.shipilev at oracle.com Sat Mar 12 00:01:38 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Mar 2016 03:01:38 +0300 Subject: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E35984.7030806@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <56DE06EF.7040408@oracle.com> <56E3567D.8010807@oracle.com> <56E35984.7030806@oracle.com> Message-ID: <56E35C62.9070003@oracle.com> On 03/12/2016 02:49 AM, Coleen Phillimore wrote: > On 3/11/16 6:36 PM, Aleksey Shipilev wrote: >> On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >>>> Aside: see the last experiment, avoiding StringTable::intern (shows in >>>> profiles a lot!) trims down construction costs down even further. I'd >>>> think that is a worthwhile improvement to consider. >>> Hm, this is an interesting experiment. I've been looking for a better >>> way to store the name of the method rather than cpref. >> I did some preliminary work for storing class names (those are easy, >> since Class.name is already there on Java side). Would be nice to handle >> both method names and source files, because we are looking at some nice >> improvements: >> https://bugs.openjdk.java.net/browse/JDK-8151751 >> >> Can you pick it up, and follow up further? > > Yes, I think caching String classname on Class might be also helpful > for the StackWalk API. > > My impression was that the performance of Throwable.getStackTrace() > wasn't super critical since it's used in exceptional conditions. Let me > know otherwise. While we keep our guidance at "beware of using Exceptions frequently", we should not avoid easy fixes that make them less painful. Granted, projects that conscientiously use Exceptions for e.g. non-local returns have learned to nop out fillInStackTrace(). But it would be nice to alleviate the pain for those who overlook that, or have no choice needing the actual stack trace. (Even used on non-critical paths, CPU time spent dealing with Exceptions worldwide is better spent elsewhere; it would be an eco-friendly fix to do :)). Thanks, -Aleksey From thomas.stuefe at gmail.com Sat Mar 12 07:35:22 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 12 Mar 2016 08:35:22 +0100 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56DF4BAD.1040109@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> Message-ID: Thank you, Coleen! On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > This latest version seems okay (or at least better than the other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > >> Hi Thomas, >> >> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> On Mon, Feb 29, 2016 at 4:44 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> On 27/02/2016 2:05 AM, Thomas St?fe wrote: >>> >>> Hi, >>> >>> please take a look at this proposed fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148425 >>> Webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >>> >>> This adds a replacement function os::strerror() as a drop-in for >>> strerror(), which has a number of issues. >>> >>> strerror() is unsafe to use and may cause (and has caused) >>> crashes in >>> multithreaded scenarios. It is also not ideal for log files >>> because of the >>> implicit localization of the error messages. >>> >>> For details please see the discussion under the bug report. >>> >>> >>> I just came across strerror_l, which is required to be thread-safe. >>> Is that a possible alternative? (I'm not sure how locale's are >>> obtained). >>> >>> >>> Sorry, I think this API is glibc only. At least I cannot find this in >>> our AIX headers, nor on Solaris. >>> >> >> It is a POSIX API: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >> >> added in 2006 but part of POSIX.1-2008. But as per Dalibor's link not >> necessarily available: >> >> "This function is missing on some platforms: glibc 2.3.6, Mac OS X 10.5, >> FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX >> 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, mingw, MSVC 9, Interix 3.5, >> BeOS. " >> >> Pity. >> >> >> Otherwise what you have seems okay - though I do dislike having to >>> duplicate all that details already buried in the system >>> headers/library. Not sure we need to the long text at the VM level - >>> which would simplify things a bit. >>> >>> >>> I agree, I dislike this too. Like everyone else in this thread. But I >>> think this is a pragmatic solution. >>> >>> I am a bit stuck here - should we really get rid of the long text >>> feature? There are some callsites of strerror() in the hotspot where >>> arguably the long text is better suited: >>> - in assert_status() (see debug.hpp) - this ends up in the header of >>> error files, if this suddenly changes to a literalized errno, people may >>> be upset >>> >> >> I added assert_status purely to expand on what the failing status was :) >> I'm happy to see EINVAL in that context rather than "invalid argument" (or >> whatever) :) >> >> - when failing to write a heap dump file - see services/heapDumper.cpp. >>> Which ends as printout on the command line, I think. >>> >> >> Maybe ... if it is an error the user can fix. >> >> The safe option would be to provide both variants (short and long text). >>> Or, provide the safe, short variant for all logging calls - when >>> "EINVAL" is enough, and let users continue to use strerror() for those >>> few cases where the long text is needed. >>> >>> What do you think? >>> >> >> Trying to decide what makes me least unhappy. :) Given you've already >> done the work I guess having long and short forms is okay. >> >> Thanks, >> David >> >> Thanks, Thomas >>> >>> Thanks, >>> David >>> >>> >>> Please note that I did not yet change any call sites, although >>> all call >>> sites in the os namespace should already use the new function. I >>> wanted to >>> see whether there would be any general objections. >>> >>> Kind Regards, Thomas >>> >>> >>> > From thomas.stuefe at gmail.com Sat Mar 12 08:22:10 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 12 Mar 2016 09:22:10 +0100 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56E26DF5.8080300@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> Message-ID: Hi David, thanks again for your review. Here the new version: http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ And the diff to the last version: http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt I fixed the indention, copyright comments and the typo. Further comments inline. On Fri, Mar 11, 2016 at 8:04 AM, David Holmes wrote: > Hi Thomas, > > Thanks for persevering with this. Sorry for the delayed response. > > On 10/03/2016 2:58 AM, Thomas St?fe wrote: > >> Hi all, >> >> please take a look at this next version of the fix. >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ >> >> I am the first to admit that this is quite ugly :(, but it is a >> pragmatic solution. >> >> Some details: >> >> - I added os::strerror() as a drop-in replacement for ::strerror() - it >> returns the text as before, but does not localize and does not handle >> unknown error values; so it can be implemented using a simple static >> string table and is always safe to use. >> > > Ok. But I don't think we need os::lasterror() if we have this. A follow up > clean-up is okay for that though. > > I would love to keep this functionality, because I like printing out the short concise errno values, and there are a number of logging changes coming at least for AIX. It also does not cost much, as the large string table is already there. If the second API does not suit you, would it be accepable for you if I hide this functionality behind a second parameter in strerror, defaulting to false, like I did in my first version? E.g. os::strerror(int e, bool short_name=false); ? But talking about clean-up, could we get rid of os::lasterror() ? I think that function is a bad idea, and it fortunately is only called in two places, both just need strerror() and no Win32 error handling anyway. I also would like to remove os::get_last_error(). It returns errno on *nix, win32 error on Windows. Both are different things, plus there is also an errno on Windows The return value of this function is useless without knowing what the returned error number actually is, so it is not of much use. Also it does seem to handle unknown error values. > > - I added os::errno_name() for those cases where one would want the >> literalized errno value (e.g. "EINVAL") instead of the full text. >> > > Ok. For the unknown case can it return the numeric value that it was > passed? > > I would like to avoid this. This would make the function more complicated. I'd need to keep this thread-safe, so I either would have to allocate thread local storage for the return string somehow or, alternatively, keep a fixed string table a la [][] {"unknown (0)", "unknown(1)"} for the first n values or so. Also, ::strerror() behaves not consistently for the EINVAL case on all platforms anyway - on Linux and Bsd, it returns the numerical value, but on Solaris, Windows and AIX, it just returns "Unknown". Many callsites I saw take this already into account and print out the numerical errno value in addition to the error string. - I fixed all callsites in the hotspot which used ::strerror to use >> os::strerror, or, in some few cases (mostly my own coding for AIX), >> os::errno_name(). >> > > Bit subjective but okay - I personally don't care either way. :) > > - To avoid including os.hpp in debug.hpp, I moved the implemntation of >> assert_status to debug.cpp >> > > Okay ... did the include cause a problem? > os.hpp is a large beast. I wanted to keep it out of debug.hpp, to not force this include upon anyone who includes debug.hpp just to get assert(). I also try to avoid calling system apis in header files. > > > General minor comments: > > src/os/posix/vm/os_posix.cpp > > Indentation of wrapped call needs fixing > > Fixed > --- > > src/share/vm/runtime/os.hpp > > Typo: > > + // sugested in the POSIX standard. > > -> suggested > > Fixed > --- > > src/share/vm/utilities/vmError.cpp > > Good catch on the code that potentially reports the wrong error using > get_last_error! Even the simple print_cr(..., strerror(errno), errno) could > in fact print non-matching values if strerror itself caused an error > (unlikely of course :) ). > > Thanks :) > Please check all copyright years - attachListener_solaris.cpp was updated > to 2015 instead of 2016 :) Also note correct format for two year copyrights > - in src/share/vm/logging/logFileOutput.cpp you have: > > Copyright (c) 2015,2016 Oracle > > but it should be: > > Copyright (c) 2015, 2016, Oracle > > Fixed > Thanks, > David > > Thanks! Thomas > > Kind Regards, Thomas >> >> >> >> >> On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore >> > >> wrote: >> >> >> This latest version seems okay (or at least better than the other >> workarounds). >> >> thanks, >> Coleen >> >> >> On 3/1/16 12:30 AM, David Holmes wrote: >> >> Hi Thomas, >> >> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> >> Hi David, >> >> On Mon, Feb 29, 2016 at 4:44 AM, David Holmes >> >> > >> >> wrote: >> >> Hi Thomas, >> >> On 27/02/2016 2:05 AM, Thomas St?fe wrote: >> >> Hi, >> >> please take a look at this proposed fix: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8148425 >> Webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >> >> This adds a replacement function os::strerror() as >> a drop-in for >> strerror(), which has a number of issues. >> >> strerror() is unsafe to use and may cause (and has >> caused) >> crashes in >> multithreaded scenarios. It is also not ideal for >> log files >> because of the >> implicit localization of the error messages. >> >> For details please see the discussion under the bug >> report. >> >> >> I just came across strerror_l, which is required to be >> thread-safe. >> Is that a possible alternative? (I'm not sure how >> locale's are >> obtained). >> >> >> Sorry, I think this API is glibc only. At least I cannot >> find this in >> our AIX headers, nor on Solaris. >> >> >> It is a POSIX API: >> >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >> >> added in 2006 but part of POSIX.1-2008. But as per Dalibor's >> link not necessarily available: >> >> "This function is missing on some platforms: glibc 2.3.6, Mac OS >> X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX >> 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, Cygwin, >> mingw, MSVC 9, Interix 3.5, BeOS. " >> >> Pity. >> >> >> Otherwise what you have seems okay - though I do >> dislike having to >> duplicate all that details already buried in the system >> headers/library. Not sure we need to the long text at >> the VM level - >> which would simplify things a bit. >> >> >> I agree, I dislike this too. Like everyone else in this >> thread. But I >> think this is a pragmatic solution. >> >> I am a bit stuck here - should we really get rid of the long >> text >> feature? There are some callsites of strerror() in the >> hotspot where >> arguably the long text is better suited: >> - in assert_status() (see debug.hpp) - this ends up in the >> header of >> error files, if this suddenly changes to a literalized >> errno, people may >> be upset >> >> >> I added assert_status purely to expand on what the failing >> status was :) I'm happy to see EINVAL in that context rather >> than "invalid argument" (or whatever) :) >> >> - when failing to write a heap dump file - see >> services/heapDumper.cpp. >> Which ends as printout on the command line, I think. >> >> >> Maybe ... if it is an error the user can fix. >> >> The safe option would be to provide both variants (short and >> long text). >> Or, provide the safe, short variant for all logging calls - >> when >> "EINVAL" is enough, and let users continue to use strerror() >> for those >> few cases where the long text is needed. >> >> What do you think? >> >> >> Trying to decide what makes me least unhappy. :) Given you've >> already done the work I guess having long and short forms is okay. >> >> Thanks, >> David >> >> Thanks, Thomas >> >> Thanks, >> David >> >> >> Please note that I did not yet change any call >> sites, although >> all call >> sites in the os namespace should already use the >> new function. I >> wanted to >> see whether there would be any general objections. >> >> Kind Regards, Thomas >> >> >> >> >> From ecki at zusammenkunft.net Sat Mar 12 09:21:56 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 12 Mar 2016 10:21:56 +0100 Subject: AW: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM In-Reply-To: <56E35C62.9070003@oracle.com> References: <56D73477.4030100@oracle.com> <56D737DD.7000700@oracle.com> <56D745B7.4040508@oracle.com> <56D74B4B.9090708@oracle.com> <56D98D73.4010302@oracle.com> <56DE06EF.7040408@oracle.com> <56E3567D.8010807@oracle.com> <56E35984.7030806@oracle.com> <56E35C62.9070003@oracle.com> Message-ID: <56e3dfb7.c74fc20a.f49de.09d7@mx.google.com> Hello, Regarding ?exceptional?: Speeding up stack-walking can greatly help log&trace frameworks (when they are configured to log the callsite). They hopefully do not use Throwables anymore, but I guess the other variants to get the stack traces of the last few frames on the stack still benefit from your idea. Bernd Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobime Von: Aleksey Shipilev Gesendet: Samstag, 12. M?rz 2016 02:32 An: Coleen Phillimore; hotspot-runtime-dev; core-libs-dev Betreff: Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM On 03/12/2016 02:49 AM, Coleen Phillimore wrote: > On 3/11/16 6:36 PM, Aleksey Shipilev wrote: >> On 03/08/2016 01:55 AM, Coleen Phillimore wrote: >>>> Aside: see the last experiment, avoiding StringTable::intern (shows in >>>> profiles a lot!) trims down construction costs down even further. I'd >>>> think that is a worthwhile improvement to consider. >>> Hm, this is an interesting experiment. I've been looking for a better >>> way to store the name of the method rather than cpref. >> I did some preliminary work for storing class names (those are easy, >> since Class.name is already there on Java side). Would be nice to handle >> both method names and source files, because we are looking at some nice >> improvements: >> https://bugs.openjdk.java.net/browse/JDK-8151751 >> >> Can you pick it up, and follow up further? > > Yes, I think caching String classname on Class might be also helpful > for the StackWalk API. > > My impression was that the performance of Throwable.getStackTrace() > wasn't super critical since it's used in exceptional conditions. Let me > know otherwise. While we keep our guidance at "beware of using Exceptions frequently", we should not avoid easy fixes that make them less painful. Granted, projects that conscientiously use Exceptions for e.g. non-local returns have learned to nop out fillInStackTrace(). But it would be nice to alleviate the pain for those who overlook that, or have no choice needing the actual stack trace. (Even used on non-critical paths, CPU time spent dealing with Exceptions worldwide is better spent elsewhere; it would be an eco-friendly fix to do :)). Thanks, -Aleksey From dmitry.samersoff at oracle.com Sun Mar 13 11:03:45 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 13 Mar 2016 14:03:45 +0300 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D8AD.8040902@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com> Message-ID: <56E54911.9090807@oracle.com> Marcus, 1. os_posix/os_windows.cpp Windows version is expensive and change access time of a log file. So it's better to create os::get_mtime() that uses stat() for both, windows and posix and LogFileOutput::calc_mtime_diff(). Also it saves a bit of compiler power unrolling loop. 2. log.cpp size_t number_of_lines_with_substring_in_file() When you plan to use it ? Current implementation is rather expensive, but if you plan to run it manually only, I'm OK with it. 3. logFileOutput.cpp 82. Please, change file_exists to can_be_rotated() and check that log output is a *regular file* and you have a write access to it. 87. Please, don't use floating point math. Just allocate 10 extra bytes, it fit all possible file length value. 93. if we have log.01, log.03 etc this function creates log.02 instead of log.04. Sorry! I'm not follow logic of ll.118 What happens if some log parsing tool change log file mtime? Please, limit the number of old logs (FileCountOption) to some reasonable value (e.g. 999) and use binary search to find the name of a next file. Also please check full log file name against MAX_PATH constant. -Dmitry On 2016-03-11 17:39, Marcus Larsson wrote: > Hi, > > On 2016-03-11 15:35, Bengt Rutisson wrote: >> >> Hi Marcus, >> >> On 2016-03-11 15:21, Marcus Larsson wrote: >>> Third time's the charm. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >> >> I had a quick look at the code changes. It is not really my area of >> the code, so I'll leave to someone else to formally review it. >> >> However, I downloaded the patch a played a bit with the logging. This >> is much more like the way I would like it! Thanks! >> >> So, from a functional perspective this looks good to me. >> > > Thanks for the feedback! > > Marcus > >> Thanks, >> Bengt >> >>> >>> This patch makes log file rotation the default. Default thresholds >>> are 5 rotated files with a target size of 20MiB. Truncating behavior >>> can be achieved by setting filecount to 0 >>> (-Xlog::myfile.log::filecount=0). >>> >>> If a log file already exists during log file initialization it will >>> be rotated. If any of the target file names (file.0 to file.4 in the >>> default case) are available, that filename will be used for the >>> existing log. If all names are taken the VM will attempt to overwrite >>> the oldest file. >>> >>> This should prevent unlimited log file creations and avoid accidental >>> loss of log files from previous runs. The default thresholds (5 >>> files, 20MiB each) is just a suggestion. If you think it should be >>> higher/lower let me know. >>> >>> Tested with included internal VM tests through RBT. >>> >>> Thanks, >>> Marcus >>> >>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>> Hi, >>>> >>>> After some offline discussions I'm withdrawing this patch. I will >>>> instead investigate if I can achieve similar behavior using log >>>> rotation as the default. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>> Hi again, >>>>> >>>>> Taking a different approach to this. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>> >>>>> Existing files will now by default be renamed/archived with a .X >>>>> suffix where X is the lowest number such that the resulting file >>>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>>> controlling this behavior has been added as well. It can be set to >>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>> >>>>> Tested with included jtreg test through JPRT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to make sure UL truncates >>>>>> existing log files before writing to them. Since files are opened >>>>>> in append mode, truncation isn't done automatically, so instead >>>>>> the patch adds an attempt to remove the log file before opening it. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>> >>>>>> Testing: >>>>>> Included test through JPRT >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>> >>>> >>> >> > -- 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 david.holmes at oracle.com Mon Mar 14 00:49:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 10:49:06 +1000 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E2E7CE.1080809@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> Message-ID: <56E60A82.3020905@oracle.com> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: > > > On 3/10/2016 12:42 PM, Kim Barrett wrote: >>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>> wrote: >>> >>> >>> >>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>> Background: >>>>> >>>>> After the backport of >>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>> _workers to null in 8u. >>>>> >>>>> As there is no condition to handle such scenario in >>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>> >>>>> The similar condition is already implemented for following scenarios >>>>> >>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>> >>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>> >>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>> >>>>> >>>>> >>>>> Fix: >>>>> >>>>> Condition check is added in src/share/vm/runtime/arguments.cpp file >>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>> >>>>> Thanks for the base patch from Jon. >>>>> >>>>> Due to this patch it makes some of the test cases absolute. They >>>>> have been removed. >>>>> >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>> This existing code looks wrong: >>>> >>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>> 1677 if (ParallelGCThreads == 0) { >>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>> >>>> Line 1678 seems to do the same as 1675 - is >>>> Abstract_VM_Version::parallel_worker_threads() somehow expected to >>>> return a different value on the second call ?? >>> No, Abstract_VM_Version::parallel_worker_threads() won't return a >>> different >>> value for a second call. It's harmless but would be cleaner deleting >>> 1675,1676. > > I retract this suggestion to delete 1675-1676. I'll 99.99% sure that it > would be > OK, but argument processing being what it is and this being an update fix, > leave those lines in. I've been surprised before. Okay on being conservative here. But I repeat my earlier statement: That aside I'm confused by the fix as we have: ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, so it seems odd to report an error for setting a value that is already the default ?? David ----- >> The retry setting to parallel_worker_threads() again code dates back >> to the initial G1 checkin. Hard to know what was intended. >> >> The current jdk9 code does not have that: it looks like >> >> FLAG_SET_DEFAULT(ParallelGCThreads, >> Abstract_VM_Version::parallel_worker_threads()); >> if (ParallelGCThreads == 0) { >> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >> for ParallelGCThreads should not be 0."); >> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >> combined with -XX:ParallelGCThreads=0", NULL); >> } >> >> This proposed change is for jdk8u-something, correct? >> >> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >> seen above. Making use of that decision, a cleanup pass was made that >> eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend >> it?s 1 or do some other special thing? code. The backport of 8017462 >> to 8u72 (i.e. 8149347) looks like it might not have taken that into >> account. For example, >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 >> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb >> 17 13:42:03 2016 +0000 >> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb >> 18 20:30:45 2016 +0000 >> @@ -3991,8 +3991,15 @@ >> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >> - uint active_workers = (G1CollectedHeap::use_parallel_gc_threads() ? >> - workers()->active_workers() : 1); >> + uint active_workers = >> AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), >> + >> workers()->active_workers(), >> + >> Threads::number_of_non_daemon_threads()); >> >> Note the conditionalization on use_parallel_gc_threads(). >> >> It might be that the simplest thing to do for 8u backporting is indeed >> to backport prevention of ParallelGCThreads == 0, as suggested in the >> proposed patch. > > I agree although I'll also respond to Thomas next. > > Jon > >> >> >> > From david.holmes at oracle.com Mon Mar 14 01:29:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 11:29:15 +1000 Subject: UL: logging before initialization? In-Reply-To: References: <56E229A8.4020907@oracle.com> <56E27E4D.3060108@oracle.com> <56E2BFD3.7060306@oracle.com> Message-ID: <56E613EB.9080507@oracle.com> On 12/03/2016 12:34 AM, Thomas St?fe wrote: > Hi David, > > On Fri, Mar 11, 2016 at 1:53 PM, David Holmes > wrote: > > On 11/03/2016 9:22 PM, Thomas St?fe wrote: > > Hi David, Marcus, > > thanks for thinking about this! Please find my comments inline. > > On Fri, Mar 11, 2016 at 9:14 AM, Marcus Larsson > > >> wrote: > > Hi, > > On 2016-03-11 03:12, David Holmes wrote: > > Hi Thomas, > > Expanding to hotspot-dev as UL was not designed/built > by the > runtime team. > > My comments below based on my limited understanding of UL. > > On 11/03/2016 2:25 AM, Thomas St?fe wrote: > > Hi all, > > I wanted to use UL to log some information from > early OS > initialization but > found that we initialize logging quite late. It is > initialized way after > os::init() runs. > > > There are various dependencies in the unified logging > framework > that prevent it (or at least parts of it) from being > used early eg: > - argument parsing and log configuration > - existence of current thread (for logStreams) > > > Currently, the framework can be used as soon as static > initialization is done. This doesn't include the logStreams of > course since they require resource allocations. The problem > is as > you say that there is no way to configure the logging > before parsing > the -Xlog command. This means up until that point the default > configuration will apply, which means warnings and errors > to stdout. > > > I also see that warnings and errors are printed > unconditionally even > before, only log calls for levels <= info are > quietly swallowed. > > > Are those warnings/errors using UL? I suspect not. > > > They could be, since errors and warnings are enabled by > default. > > > They are from UL. I see errors and warnings. Decorators seem to > be off > though, e.g. the timestamp, because they rely on initialization in > os::init(). But nothing serious which breaks logging as long as > one is > fine with default settings. > > > > > Silent swallowing is not good though. > > Would there be a way to move UL initialization and > parsing > of -Xlog > Arguments to an earlier point to be able to use > logging in > os::init()? > > > I don't see how you could utilize tags and levels until > after > full initialization of the logging system, so that would > preclude using it as early as os::init. > > > It is a possible solution I guess. I don't know how dependent > argument parsing is on other initialization. There would > always be > some part of the initialization where you only have warning and > error logging unless we do the parsing first thing during > startup, > which I assume will be impossible. > > > Sure, the logging system must be fully initialized to use it. > However, I > argue that the logging system should be as independent as > possible from > the rest of the VM, so not rely on VM initialization. If that is the > case - and I think it is now - then logging initialization and -Xlog > parsing can be moved up in Thread::create_vm() to before os::init(). > > > You would need to examine the complete transitive closure of logging > code to see if such a move is feasible. > > > Not sure I understand. > > Making sure that the logging system itself does not contain deep VM > dependencies should be feasible. If with "logging code" you mean logging > calls by the various components, I would think that anyone introducing > logging calls should not log anything which is not available at the time > the logging call is executed. Or do I not understand? Just the logging system itself, but dependencies are often not obvious inside the VM - eg allocation -> NMT Thanks, David > > Thomas > > I would even argue that if this does not work, it is an error. For > example, if we were to require Thread::current() to work for > logging,e.g. for log decorators, this would mean logging breaks if > Thread::current() is not available. So, if we make the logging > system > work for pre-initialization time, and add regression tests for this, > this is a pretty good way to keep the logging system healthy and > robust > and avoid too much dependencies into the VM. > > I would think that the logging system as it is now is already > robust - > the fact that it works, with default settings, right after static > initialization is a good sign. So, we could probably move > initialization > and -Xlog parsing to an earlier point with not much work. > > > While the logging system has taken a number of steps to make itself > immune to some initialization issues (for example "locking" uses a > semaphore and doesn't rely on Thread::current()), different parts of > the system have different dependencies - which seems unavoidable to > me. I don't know if it would be possible to enable a subset of the > API earlier in the initialization sequence by refactoring some of > the configuration logic and argument parsing. > > David > ----- > > > > > Or, if that is not possible, would there be a way > to delay > printing of > early logging calls to after logging initialization > and then > print them out > in one go? I think this would be not trivial > though: one > would have to > collect all logging output in memory somewhere - > because we > do not yet know > which tags are switched on - and then, once -Xlog > is parsed, > filter it by > tag before printing it out. > > > Yeah that seems difficult/complex given the problem > that the VM > is in the early stages of initialization > > > I really do not like this solution either, I only added this for > completeness and to make my first proposal look better in > comparison :) > > What do you think, would that be a worthwhile > change? I am a > bit unhappy > about how logging calls are quietly swallowed, so > for any > code which runs > at VM initialization, one always has to keep in > mind that UL > may not yet be > initialized. > > > Not a new problem (adding more code during VM > initialization) > but one that is getting more complicated :) > > > I think it would perhaps be worthwhile if there's demand > for a bunch > of info to trace level logging from startup code (before > argument > parsing). > > > At least in the AIX port we have a lot of tracing going on very > early. > For platform porters, OS initialization is a very interesting > time. We > have now a very primitive trace there which I would love to > switch to > UL, but right now the trace output would just be swallowed by > not-yet-initialized UL. > > Thank you, > > Thomas > > Thanks, > Marcus > > > > Cheers, > David > > Kind Regards, Thomas > > > > From david.holmes at oracle.com Mon Mar 14 01:49:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 11:49:14 +1000 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> Message-ID: <56E6189A.1010409@oracle.com> On 11/03/2016 9:38 PM, Cheleswer Sahu wrote: > Thanks Dmitry and Thomas for reviews. After adding space I will request for the push. Consider this Reviewed. But this needs to pushed to hs-rt and currently the webrev is against jdk9/dev. Thanks, David > > > Regards, > > Cheleswer > > > > From: Dmitry Dmitriev > Sent: Friday, March 11, 2016 5:00 PM > To: Cheleswer Sahu; Thomas St?fe > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly > > > > Hi Cheleswer, > > Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. > > Thanks, > Dmitry > > > > On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > > > Thanks for your review comments. My answers are below for your review comments > > > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > > > >>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will not able to read the data, it will return lesser number of bytes, which contains the partial data of ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. > > > > 2) Just interesting, do you really need to set memory to 0 by memset? > >>> I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. > > > > For rest of the comments I have made correction in the code. The new webrev is available in the below location > > HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > > > > Regards, > > Cheleswer > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Thursday, March 10, 2016 7:39 PM > To: Dmitry Dmitriev > Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly > > > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: > > Hi Cheleswer, > > > > thanks for fixing this. > > > > Some more issues: > > > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. > > > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024); > > > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > > > Beside those points, I think both points of Dmitry are valid. > > > > Also, I find > > > > > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. > > Regards, > > Cheleswer > > > > > > > > > From david.holmes at oracle.com Mon Mar 14 01:50:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 11:50:14 +1000 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> Message-ID: <56E618D6.8000207@oracle.com> PS. Copyright year needs updating. David On 11/03/2016 9:38 PM, Cheleswer Sahu wrote: > Thanks Dmitry and Thomas for reviews. After adding space I will request for the push. > > > > Regards, > > Cheleswer > > > > From: Dmitry Dmitriev > Sent: Friday, March 11, 2016 5:00 PM > To: Cheleswer Sahu; Thomas St?fe > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly > > > > Hi Cheleswer, > > Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. > > Thanks, > Dmitry > > > > On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > > > Thanks for your review comments. My answers are below for your review comments > > > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > > > >>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will not able to read the data, it will return lesser number of bytes, which contains the partial data of ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. > > > > 2) Just interesting, do you really need to set memory to 0 by memset? > >>> I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. > > > > For rest of the comments I have made correction in the code. The new webrev is available in the below location > > HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ > > > > > > Regards, > > Cheleswer > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Thursday, March 10, 2016 7:39 PM > To: Dmitry Dmitriev > Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly > > > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: > > Hi Cheleswer, > > > > thanks for fixing this. > > > > Some more issues: > > > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. > > > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024); > > > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > > > Beside those points, I think both points of Dmitry are valid. > > > > Also, I find > > > > > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. > > Regards, > > Cheleswer > > > > > > > > > From david.holmes at oracle.com Mon Mar 14 02:06:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 12:06:18 +1000 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E2D5EC.8000505@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> <56E14EC2.6010204@oracle.com> <56E2D5EC.8000505@oracle.com> Message-ID: <56E61C9A.2080001@oracle.com> On 12/03/2016 12:27 AM, Robbin Ehn wrote: > Hi, please review this updated changeset. > > Webrev: http://cr.openjdk.java.net/~rehn/8151264/v2/webrev/ Thanks for the updates! Three minor nits in src/share/vm/logging/logConfiguration.hpp + // JavaMain thread may call this callback if there is an early registration "JavaMain" is not a defined thing in the VM. I presume this means the main Java thread that created the VM so "The main Java thread may call ..." + // else the attach listener JavaThread, started via diagonstic command, will be executing thread. diagonstic -> diagnostic + // The main purpose if this callback is to see if a loglevel have been changed. purpose if -> purpose of No need to see new webrev. Thanks, David > Thanks! > > /Robbin > > On 03/10/2016 11:38 AM, Robbin Ehn wrote: >> Thanks David for looking at this. >> >> On 03/10/2016 11:19 AM, David Holmes wrote: >>> Hi Robbin, >>> >>> On 9/03/2016 7:02 PM, Robbin Ehn wrote: >>>> >>>> Hi, please review this minor change. >>> >>> A notification mechanism is not so minor - what are the programming >>> rules for the callbacks? which threads might execute them? Are there any >>> obvious deadlock/livelock potentials? Do we need to unregister a >>> callback? >>> >>> At a minimum there should be some comments regarding the nature of the >>> callback and what it can and can't do. >> >> Yes, I will document it better. >> >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >>>> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ >>> >>> Some minor nits: >>> >>> src/share/vm/logging/log.cpp >>> >>> Copyright needs 2016 added. >>> >>> --- >>> >>> src/share/vm/logging/logConfiguration.cpp >>> >>> + assert(cb != NULL, "Should not initialize register NULL as >>> listener."); >>> >>> "initialize register" doesn't make grammatical sense - delete >>> "initialize" >>> >>> + for (size_t i=0;i<_n_listener_callbacks;i++) { >>> >>> Style nits: spaces around operators and after ; >>> >>> --- >>> >>> src/share/vm/logging/logConfiguration.hpp >>> >>> + // After any configuration change this method should be called by in >>> scope of LogConfigurationLock >>> >>> Delete 'by' - or may I suggest: >>> >>> // This should be called after any configuration change while still >>> holding ConfigurationLock >>> >> >> Yes, thanks! >> >> /Robbin >> >>> Thanks, >>> David >>> ----- >>> >>>> Tested with a new internal vm test (included). >>>> >>>> Thanks! >>>> >>>> /Robbin From david.holmes at oracle.com Mon Mar 14 03:43:04 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 13:43:04 +1000 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> Message-ID: <56E63348.2010607@oracle.com> On 12/03/2016 6:22 PM, Thomas St?fe wrote: > Hi David, > > thanks again for your review. Here the new version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ > > And the diff to the last version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt > > I fixed the indention, copyright comments and the typo. All looks good - thanks. > Further comments inline. Ditto :) > > On Fri, Mar 11, 2016 at 8:04 AM, David Holmes > wrote: > > Hi Thomas, > > Thanks for persevering with this. Sorry for the delayed response. > > On 10/03/2016 2:58 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at this next version of the fix. > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ > > I am the first to admit that this is quite ugly :(, but it is a > pragmatic solution. > > Some details: > > - I added os::strerror() as a drop-in replacement for > ::strerror() - it > returns the text as before, but does not localize and does not > handle > unknown error values; so it can be implemented using a simple static > string table and is always safe to use. > > > Ok. But I don't think we need os::lasterror() if we have this. A > follow up clean-up is okay for that though. > > > I would love to keep this functionality, because I like printing out the > short concise errno values, and there are a number of logging changes > coming at least for AIX. It also does not cost much, as the large string > table is already there. > > If the second API does not suit you, would it be accepable for you if I > hide this functionality behind a second parameter in strerror, > defaulting to false, like I did in my first version? E.g. > os::strerror(int e, bool short_name=false); ? That was what I was thinking of yes. :) > But talking about clean-up, could we get rid of os::lasterror() ? I > think that function is a bad idea, and it fortunately is only called in > two places, both just need strerror() and no Win32 error handling anyway. Sounds good. lasterror() is a fragile API as it is too easy to introduce unexpected system calls between the call to lasterror and the action you want to check for the error. > I also would like to remove os::get_last_error(). It returns errno on > *nix, win32 error on Windows. Both are different things, plus there is > also an errno on Windows The return value of this function is useless > without knowing what the returned error number actually is, so it is not > of much use. Simplifying and streamlining all this sounds good. > Also it does seem to handle unknown error values. > > - I added os::errno_name() for those cases where one would want the > literalized errno value (e.g. "EINVAL") instead of the full text. > > > Ok. For the unknown case can it return the numeric value that it was > passed? > > > I would like to avoid this. This would make the function more complicated. > > I'd need to keep this thread-safe, so I either would have to allocate > thread local storage for the return string somehow or, alternatively, > keep a fixed string table a la [][] {"unknown (0)", "unknown(1)"} for > the first n values or so. Okay. I was thinking this would be simpler but of course we have to convert to a string. I note that linux defines ~133 errno values, and you have entries for ~75 - are they all the POSIX ones? I'm wondering whether we should have a fallback strategy for an unknown (platform-specific) error by using the platform strerror even though not thread-safe (the window of exposure is vastly reduced) ? > Also, ::strerror() behaves not consistently for the EINVAL case on all > platforms anyway - on Linux and Bsd, it returns the numerical value, but > on Solaris, Windows and AIX, it just returns "Unknown". Many callsites I > saw take this already into account and print out the numerical errno > value in addition to the error string. I doubt those callsites are not taking into account unknown values - I think you will find they originally only reported the numerical value and were then augmented to also print the strerror message. Thanks, David > - I fixed all callsites in the hotspot which used ::strerror to use > os::strerror, or, in some few cases (mostly my own coding for AIX), > os::errno_name(). > > > Bit subjective but okay - I personally don't care either way. :) > > - To avoid including os.hpp in debug.hpp, I moved the > implemntation of > assert_status to debug.cpp > > > Okay ... did the include cause a problem? > > > os.hpp is a large beast. I wanted to keep it out of debug.hpp, to not > force this include upon anyone who includes debug.hpp just to get > assert(). I also try to avoid calling system apis in header files. > > > > General minor comments: > > src/os/posix/vm/os_posix.cpp > > Indentation of wrapped call needs fixing > > > Fixed > > --- > > src/share/vm/runtime/os.hpp > > Typo: > > + // sugested in the POSIX standard. > > -> suggested > > > Fixed > > --- > > src/share/vm/utilities/vmError.cpp > > Good catch on the code that potentially reports the wrong error > using get_last_error! Even the simple print_cr(..., strerror(errno), > errno) could in fact print non-matching values if strerror itself > caused an error (unlikely of course :) ). > > > Thanks :) > > > Please check all copyright years - attachListener_solaris.cpp was > updated to 2015 instead of 2016 :) Also note correct format for two > year copyrights - in src/share/vm/logging/logFileOutput.cpp you have: > > Copyright (c) 2015,2016 Oracle > > but it should be: > > Copyright (c) 2015, 2016, Oracle > > Fixed > > Thanks, > David > > > Thanks! > > Thomas > > > Kind Regards, Thomas > > > > > On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore > > >> wrote: > > > This latest version seems okay (or at least better than the > other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas St?fe wrote: > > Hi David, > > On Mon, Feb 29, 2016 at 4:44 AM, David Holmes > > > > > >>> wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, Thomas St?fe wrote: > > Hi, > > please take a look at this proposed fix: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > This adds a replacement function > os::strerror() as > a drop-in for > strerror(), which has a number of issues. > > strerror() is unsafe to use and may cause > (and has > caused) > crashes in > multithreaded scenarios. It is also not > ideal for > log files > because of the > implicit localization of the error messages. > > For details please see the discussion > under the bug > report. > > > I just came across strerror_l, which is > required to be > thread-safe. > Is that a possible alternative? (I'm not sure how > locale's are > obtained). > > > Sorry, I think this API is glibc only. At least I > cannot > find this in > our AIX headers, nor on Solaris. > > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of POSIX.1-2008. But as per > Dalibor's > link not necessarily available: > > "This function is missing on some platforms: glibc > 2.3.6, Mac OS > X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix > 3.1.8, AIX > 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, > Cygwin, > mingw, MSVC 9, Interix 3.5, BeOS. " > > Pity. > > > Otherwise what you have seems okay - though I do > dislike having to > duplicate all that details already buried in > the system > headers/library. Not sure we need to the long > text at > the VM level - > which would simplify things a bit. > > > I agree, I dislike this too. Like everyone else in this > thread. But I > think this is a pragmatic solution. > > I am a bit stuck here - should we really get rid of > the long > text > feature? There are some callsites of strerror() in the > hotspot where > arguably the long text is better suited: > - in assert_status() (see debug.hpp) - this ends up > in the > header of > error files, if this suddenly changes to a literalized > errno, people may > be upset > > > I added assert_status purely to expand on what the failing > status was :) I'm happy to see EINVAL in that context > rather > than "invalid argument" (or whatever) :) > > - when failing to write a heap dump file - see > services/heapDumper.cpp. > Which ends as printout on the command line, I think. > > > Maybe ... if it is an error the user can fix. > > The safe option would be to provide both variants > (short and > long text). > Or, provide the safe, short variant for all logging > calls - when > "EINVAL" is enough, and let users continue to use > strerror() > for those > few cases where the long text is needed. > > What do you think? > > > Trying to decide what makes me least unhappy. :) Given > you've > already done the work I guess having long and short > forms is okay. > > Thanks, > David > > Thanks, Thomas > > Thanks, > David > > > Please note that I did not yet change any call > sites, although > all call > sites in the os namespace should already > use the > new function. I > wanted to > see whether there would be any general > objections. > > Kind Regards, Thomas > > > > > From sangheon.kim at oracle.com Mon Mar 14 06:34:52 2016 From: sangheon.kim at oracle.com (sangheon) Date: Sun, 13 Mar 2016 23:34:52 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E60A82.3020905@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> Message-ID: <56E65B8C.4010908@oracle.com> Hi David, On 03/13/2016 05:49 PM, David Holmes wrote: > On 12/03/2016 1:44 AM, Jon Masamitsu wrote: >> >> >> On 3/10/2016 12:42 PM, Kim Barrett wrote: >>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>>> wrote: >>>> >>>> >>>> >>>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>>> Background: >>>>>> >>>>>> After the backport of >>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>>> _workers to null in 8u. >>>>>> >>>>>> As there is no condition to handle such scenario in >>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>>> >>>>>> The similar condition is already implemented for following scenarios >>>>>> >>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>>> >>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>>> >>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>>> >>>>>> >>>>>> >>>>>> Fix: >>>>>> >>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp file >>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>>> >>>>>> Thanks for the base patch from Jon. >>>>>> >>>>>> Due to this patch it makes some of the test cases absolute. They >>>>>> have been removed. >>>>>> >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>>> This existing code looks wrong: >>>>> >>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>>> 1677 if (ParallelGCThreads == 0) { >>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>>> >>>>> Line 1678 seems to do the same as 1675 - is >>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected to >>>>> return a different value on the second call ?? >>>> No, Abstract_VM_Version::parallel_worker_threads() won't return a >>>> different >>>> value for a second call. It's harmless but would be cleaner deleting >>>> 1675,1676. >> >> I retract this suggestion to delete 1675-1676. I'll 99.99% sure that it >> would be >> OK, but argument processing being what it is and this being an update >> fix, >> leave those lines in. I've been surprised before. > > Okay on being conservative here. But I repeat my earlier statement: > > That aside I'm confused by the fix as we have: > > ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, > > so it seems odd to report an error for setting a value that is already > the default ?? A flag's value set by default(FLAG_IS_DEFAULT) is different from set by command-line(FLAG_SET_CMDLINE) when we process that flag. Usually a flag that has a default value of '0' means 'will be decided ergonomically'. From above example, 1675 FLAG_SET_DEFAULT(ParallelGCThreads, 1676 Abstract_VM_Version::parallel_worker_threads()); 1677 if (ParallelGCThreads == 0) { 1678 FLAG_SET_DEFAULT(ParallelGCThreads, 1679 Abstract_VM_Version::parallel_worker_threads()); line1676, parallel_worker_threads() is checking whether the flag is a default value or not. And use the value if it is not 'set-by-default'. unsigned int Abstract_VM_Version::parallel_worker_threads() { if (!_parallel_worker_threads_initialized) { if (FLAG_IS_DEFAULT(ParallelGCThreads)) { _parallel_worker_threads = VM_Version::calc_parallel_worker_threads(); } else { _parallel_worker_threads = ParallelGCThreads; } _parallel_worker_threads_initialized = true; } return _parallel_worker_threads; } Thanks, Sangheon > > David > ----- > >>> The retry setting to parallel_worker_threads() again code dates back >>> to the initial G1 checkin. Hard to know what was intended. >>> >>> The current jdk9 code does not have that: it looks like >>> >>> FLAG_SET_DEFAULT(ParallelGCThreads, >>> Abstract_VM_Version::parallel_worker_threads()); >>> if (ParallelGCThreads == 0) { >>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >>> for ParallelGCThreads should not be 0."); >>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >>> combined with -XX:ParallelGCThreads=0", NULL); >>> } >>> >>> This proposed change is for jdk8u-something, correct? >>> >>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >>> seen above. Making use of that decision, a cleanup pass was made that >>> eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend >>> it?s 1 or do some other special thing? code. The backport of 8017462 >>> to 8u72 (i.e. 8149347) looks like it might not have taken that into >>> account. For example, >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 >>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb >>> 17 13:42:03 2016 +0000 >>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb >>> 18 20:30:45 2016 +0000 >>> @@ -3991,8 +3991,15 @@ >>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >>> - uint active_workers = >>> (G1CollectedHeap::use_parallel_gc_threads() ? >>> - workers()->active_workers() : 1); >>> + uint active_workers = >>> AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), >>> + >>> workers()->active_workers(), >>> + >>> Threads::number_of_non_daemon_threads()); >>> >>> Note the conditionalization on use_parallel_gc_threads(). >>> >>> It might be that the simplest thing to do for 8u backporting is indeed >>> to backport prevention of ParallelGCThreads == 0, as suggested in the >>> proposed patch. >> >> I agree although I'll also respond to Thomas next. >> >> Jon >> >>> >>> >>> >> From david.holmes at oracle.com Mon Mar 14 06:46:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 16:46:58 +1000 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread Message-ID: <56E65E62.8040003@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was: # Internal Error (/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950), pid=27906, tid=13248 # assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: Must be VMThread or JavaThread with a stack showing in part: #34 0xf6623ec0 in report_vm_error ( file=0xf71b6140 "/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp", line=3901, error_msg=0xf71b62e0 "assert(thread->is_VM_thread() || thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be VMThread or JavaThread") at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218 #35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc, context=0xc1b58d4c) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901 #36 #37 0xf776b430 in __kernel_vsyscall () #38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0 #39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879 #40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg=) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367 #41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800, __in_chrg=) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611 #42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800, __in_chrg=) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655 #43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724 #44 0xf6f74e12 in JavaThread::run (this=0xc20cd800) at /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698 #45 0xf6d238ec in java_start (thread=0xc20cd800) What appears to be happening is that the thread has blocked SR_signum (SIGUSR2) at some point (though there is no code that does this), and the signal has become pending on the thread due to the event sampling logic. The thread terminates, executing well into the destructor until it gets to os::free_thread which restores the original signal mask for the thread - that signal mask has SR_signum unblocked and so the signal is delivered immediately and we enter the SR_handler. For some reason this triggers the assertion failure - though why exactly is unclear as we have not released the thread memory as yet, nor done anything that should invalidate that call. Whatever the reason the state of the thread causes secondary failures in the error reporting code as well. Attempts to reproduce this bug have been unsuccessful (so maybe we had a random memory stomp on the thread state - who knows.) So what I am doing is simply adding an additional assertion to try and catch, during regular testing, any occurrence of SR_signum being blocked while a thread is terminating. In addition a couple of minor cleanups in the signal related code: - strictly speaking SR_handler needs to use Thread::current_or_null_safe() because it needs ot use library-based TLS in a signal context. - sigsets should (POSIX recommendation) be explicitly emptied/filled before being set via pthread_sigmask - change 0 to NULL in call to pthread_sigmask Testing: - JPRT, original failing testcase Thanks, David From david.holmes at oracle.com Mon Mar 14 06:51:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 16:51:45 +1000 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E65B8C.4010908@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> Message-ID: <56E65F81.5000909@oracle.com> On 14/03/2016 4:34 PM, sangheon wrote: > Hi David, > > On 03/13/2016 05:49 PM, David Holmes wrote: >> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: >>> >>> >>> On 3/10/2016 12:42 PM, Kim Barrett wrote: >>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>>>> Background: >>>>>>> >>>>>>> After the backport of >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>>>> _workers to null in 8u. >>>>>>> >>>>>>> As there is no condition to handle such scenario in >>>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>>>> >>>>>>> The similar condition is already implemented for following scenarios >>>>>>> >>>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>>>> >>>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>>>> >>>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fix: >>>>>>> >>>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp file >>>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>>>> >>>>>>> Thanks for the base patch from Jon. >>>>>>> >>>>>>> Due to this patch it makes some of the test cases absolute. They >>>>>>> have been removed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>>>> This existing code looks wrong: >>>>>> >>>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>>>> 1677 if (ParallelGCThreads == 0) { >>>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>>>> >>>>>> Line 1678 seems to do the same as 1675 - is >>>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected to >>>>>> return a different value on the second call ?? >>>>> No, Abstract_VM_Version::parallel_worker_threads() won't return a >>>>> different >>>>> value for a second call. It's harmless but would be cleaner deleting >>>>> 1675,1676. >>> >>> I retract this suggestion to delete 1675-1676. I'll 99.99% sure that it >>> would be >>> OK, but argument processing being what it is and this being an update >>> fix, >>> leave those lines in. I've been surprised before. >> >> Okay on being conservative here. But I repeat my earlier statement: >> >> That aside I'm confused by the fix as we have: >> >> ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, >> >> so it seems odd to report an error for setting a value that is already >> the default ?? > A flag's value set by default(FLAG_IS_DEFAULT) is different from set by > command-line(FLAG_SET_CMDLINE) when we process that flag. > Usually a flag that has a default value of '0' means 'will be decided > ergonomically'. Is this a well-defined convention? I thought that when zero means "use the default" (ie ergonomics or whatever) that it always means that regardless of whether it is set explicitly or not! Thanks, David > > From above example, > 1675 FLAG_SET_DEFAULT(ParallelGCThreads, > 1676 Abstract_VM_Version::parallel_worker_threads()); > 1677 if (ParallelGCThreads == 0) { > 1678 FLAG_SET_DEFAULT(ParallelGCThreads, > 1679 Abstract_VM_Version::parallel_worker_threads()); > > line1676, parallel_worker_threads() is checking whether the flag is a > default value or not. > And use the value if it is not 'set-by-default'. > > unsigned int Abstract_VM_Version::parallel_worker_threads() { > if (!_parallel_worker_threads_initialized) { > if (FLAG_IS_DEFAULT(ParallelGCThreads)) { > _parallel_worker_threads = > VM_Version::calc_parallel_worker_threads(); > } else { > _parallel_worker_threads = ParallelGCThreads; > } > _parallel_worker_threads_initialized = true; > } > return _parallel_worker_threads; > } > > Thanks, > Sangheon > > >> >> David >> ----- >> >>>> The retry setting to parallel_worker_threads() again code dates back >>>> to the initial G1 checkin. Hard to know what was intended. >>>> >>>> The current jdk9 code does not have that: it looks like >>>> >>>> FLAG_SET_DEFAULT(ParallelGCThreads, >>>> Abstract_VM_Version::parallel_worker_threads()); >>>> if (ParallelGCThreads == 0) { >>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >>>> for ParallelGCThreads should not be 0."); >>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >>>> combined with -XX:ParallelGCThreads=0", NULL); >>>> } >>>> >>>> This proposed change is for jdk8u-something, correct? >>>> >>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >>>> seen above. Making use of that decision, a cleanup pass was made that >>>> eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend >>>> it?s 1 or do some other special thing? code. The backport of 8017462 >>>> to 8u72 (i.e. 8149347) looks like it might not have taken that into >>>> account. For example, >>>> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 >>>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb >>>> 17 13:42:03 2016 +0000 >>>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb >>>> 18 20:30:45 2016 +0000 >>>> @@ -3991,8 +3991,15 @@ >>>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >>>> - uint active_workers = >>>> (G1CollectedHeap::use_parallel_gc_threads() ? >>>> - workers()->active_workers() : 1); >>>> + uint active_workers = >>>> AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), >>>> + >>>> workers()->active_workers(), >>>> + >>>> Threads::number_of_non_daemon_threads()); >>>> >>>> Note the conditionalization on use_parallel_gc_threads(). >>>> >>>> It might be that the simplest thing to do for 8u backporting is indeed >>>> to backport prevention of ParallelGCThreads == 0, as suggested in the >>>> proposed patch. >>> >>> I agree although I'll also respond to Thomas next. >>> >>> Jon >>> >>>> >>>> >>>> >>> > From sangheon.kim at oracle.com Mon Mar 14 07:10:18 2016 From: sangheon.kim at oracle.com (sangheon) Date: Mon, 14 Mar 2016 00:10:18 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E65F81.5000909@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> Message-ID: <56E663DA.1060806@oracle.com> On 03/13/2016 11:51 PM, David Holmes wrote: > > > On 14/03/2016 4:34 PM, sangheon wrote: >> Hi David, >> >> On 03/13/2016 05:49 PM, David Holmes wrote: >>> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: >>>> >>>> >>>> On 3/10/2016 12:42 PM, Kim Barrett wrote: >>>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>>>>> Background: >>>>>>>> >>>>>>>> After the backport of >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>>>>> _workers to null in 8u. >>>>>>>> >>>>>>>> As there is no condition to handle such scenario in >>>>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>>>>> >>>>>>>> The similar condition is already implemented for following >>>>>>>> scenarios >>>>>>>> >>>>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fix: >>>>>>>> >>>>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp >>>>>>>> file >>>>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>>>>> >>>>>>>> Thanks for the base patch from Jon. >>>>>>>> >>>>>>>> Due to this patch it makes some of the test cases absolute. They >>>>>>>> have been removed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>>>>> This existing code looks wrong: >>>>>>> >>>>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>>>>> 1677 if (ParallelGCThreads == 0) { >>>>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>>>>> >>>>>>> Line 1678 seems to do the same as 1675 - is >>>>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected to >>>>>>> return a different value on the second call ?? >>>>>> No, Abstract_VM_Version::parallel_worker_threads() won't return a >>>>>> different >>>>>> value for a second call. It's harmless but would be cleaner >>>>>> deleting >>>>>> 1675,1676. >>>> >>>> I retract this suggestion to delete 1675-1676. I'll 99.99% sure >>>> that it >>>> would be >>>> OK, but argument processing being what it is and this being an update >>>> fix, >>>> leave those lines in. I've been surprised before. >>> >>> Okay on being conservative here. But I repeat my earlier statement: >>> >>> That aside I'm confused by the fix as we have: >>> >>> ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, >>> >>> so it seems odd to report an error for setting a value that is already >>> the default ?? >> A flag's value set by default(FLAG_IS_DEFAULT) is different from set by >> command-line(FLAG_SET_CMDLINE) when we process that flag. >> Usually a flag that has a default value of '0' means 'will be decided >> ergonomically'. > > Is this a well-defined convention? It is hard to say. :) I was explaining how the related codes are working. I think if we need to pick some value to mean that it will be decided ergonomically, using '0' would be consistent for all flags. But it would be better to add that explanation on its description. Thanks, Sangheon > I thought that when zero means "use the default" (ie ergonomics or > whatever) that it always means that regardless of whether it is set > explicitly or not! > > Thanks, > David > > >> >> From above example, >> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1676 Abstract_VM_Version::parallel_worker_threads()); >> 1677 if (ParallelGCThreads == 0) { >> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1679 Abstract_VM_Version::parallel_worker_threads()); >> >> line1676, parallel_worker_threads() is checking whether the flag is a >> default value or not. >> And use the value if it is not 'set-by-default'. >> >> unsigned int Abstract_VM_Version::parallel_worker_threads() { >> if (!_parallel_worker_threads_initialized) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >> _parallel_worker_threads = >> VM_Version::calc_parallel_worker_threads(); >> } else { >> _parallel_worker_threads = ParallelGCThreads; >> } >> _parallel_worker_threads_initialized = true; >> } >> return _parallel_worker_threads; >> } >> >> Thanks, >> Sangheon >> >> >>> >>> David >>> ----- >>> >>>>> The retry setting to parallel_worker_threads() again code dates back >>>>> to the initial G1 checkin. Hard to know what was intended. >>>>> >>>>> The current jdk9 code does not have that: it looks like >>>>> >>>>> FLAG_SET_DEFAULT(ParallelGCThreads, >>>>> Abstract_VM_Version::parallel_worker_threads()); >>>>> if (ParallelGCThreads == 0) { >>>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >>>>> for ParallelGCThreads should not be 0."); >>>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >>>>> combined with -XX:ParallelGCThreads=0", NULL); >>>>> } >>>>> >>>>> This proposed change is for jdk8u-something, correct? >>>>> >>>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >>>>> seen above. Making use of that decision, a cleanup pass was made >>>>> that >>>>> eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend >>>>> it?s 1 or do some other special thing? code. The backport of 8017462 >>>>> to 8u72 (i.e. 8149347) looks like it might not have taken that into >>>>> account. For example, >>>>> >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 >>>>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb >>>>> 17 13:42:03 2016 +0000 >>>>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb >>>>> 18 20:30:45 2016 +0000 >>>>> @@ -3991,8 +3991,15 @@ >>>>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >>>>> - uint active_workers = >>>>> (G1CollectedHeap::use_parallel_gc_threads() ? >>>>> - workers()->active_workers() : 1); >>>>> + uint active_workers = >>>>> AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), >>>>> + >>>>> workers()->active_workers(), >>>>> + >>>>> Threads::number_of_non_daemon_threads()); >>>>> >>>>> Note the conditionalization on use_parallel_gc_threads(). >>>>> >>>>> It might be that the simplest thing to do for 8u backporting is >>>>> indeed >>>>> to backport prevention of ParallelGCThreads == 0, as suggested in the >>>>> proposed patch. >>>> >>>> I agree although I'll also respond to Thomas next. >>>> >>>> Jon >>>> >>>>> >>>>> >>>>> >>>> >> From robbin.ehn at oracle.com Mon Mar 14 08:30:14 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 14 Mar 2016 09:30:14 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E61C9A.2080001@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> <56E14EC2.6010204@oracle.com> <56E2D5EC.8000505@oracle.com> <56E61C9A.2080001@oracle.com> Message-ID: <56E67696.6000204@oracle.com> Thanks David! Will update accordingly. /Robbin On 03/14/2016 03:06 AM, David Holmes wrote: > On 12/03/2016 12:27 AM, Robbin Ehn wrote: >> Hi, please review this updated changeset. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8151264/v2/webrev/ > > Thanks for the updates! > > Three minor nits in src/share/vm/logging/logConfiguration.hpp > > + // JavaMain thread may call this callback if there is an early > registration > > "JavaMain" is not a defined thing in the VM. I presume this means the > main Java thread that created the VM so "The main Java thread may call ..." > > + // else the attach listener JavaThread, started via diagonstic > command, will be executing thread. > > diagonstic -> diagnostic > > + // The main purpose if this callback is to see if a loglevel have > been changed. > > purpose if -> purpose of > > No need to see new webrev. > > Thanks, > David > >> Thanks! >> >> /Robbin >> >> On 03/10/2016 11:38 AM, Robbin Ehn wrote: >>> Thanks David for looking at this. >>> >>> On 03/10/2016 11:19 AM, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> On 9/03/2016 7:02 PM, Robbin Ehn wrote: >>>>> >>>>> Hi, please review this minor change. >>>> >>>> A notification mechanism is not so minor - what are the programming >>>> rules for the callbacks? which threads might execute them? Are there >>>> any >>>> obvious deadlock/livelock potentials? Do we need to unregister a >>>> callback? >>>> >>>> At a minimum there should be some comments regarding the nature of the >>>> callback and what it can and can't do. >>> >>> Yes, I will document it better. >>> >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >>>>> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ >>>> >>>> Some minor nits: >>>> >>>> src/share/vm/logging/log.cpp >>>> >>>> Copyright needs 2016 added. >>>> >>>> --- >>>> >>>> src/share/vm/logging/logConfiguration.cpp >>>> >>>> + assert(cb != NULL, "Should not initialize register NULL as >>>> listener."); >>>> >>>> "initialize register" doesn't make grammatical sense - delete >>>> "initialize" >>>> >>>> + for (size_t i=0;i<_n_listener_callbacks;i++) { >>>> >>>> Style nits: spaces around operators and after ; >>>> >>>> --- >>>> >>>> src/share/vm/logging/logConfiguration.hpp >>>> >>>> + // After any configuration change this method should be called >>>> by in >>>> scope of LogConfigurationLock >>>> >>>> Delete 'by' - or may I suggest: >>>> >>>> // This should be called after any configuration change while still >>>> holding ConfigurationLock >>>> >>> >>> Yes, thanks! >>> >>> /Robbin >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Tested with a new internal vm test (included). >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin From marcus.larsson at oracle.com Mon Mar 14 08:43:48 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Mar 2016 09:43:48 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E2D5EC.8000505@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> <56E14EC2.6010204@oracle.com> <56E2D5EC.8000505@oracle.com> Message-ID: <56E679C4.9090706@oracle.com> Hi, On 03/11/2016 03:27 PM, Robbin Ehn wrote: > Hi, please review this updated changeset. > > Webrev: http://cr.openjdk.java.net/~rehn/8151264/v2/webrev/ Looks good. Just one comment: Right now listeners are referred to as both "config listeners" and "update listeners" in different places. Would be good to use only one name for them to prevent confusion. Thanks, Marcus > > Thanks! > > /Robbin > > On 03/10/2016 11:38 AM, Robbin Ehn wrote: >> Thanks David for looking at this. >> >> On 03/10/2016 11:19 AM, David Holmes wrote: >>> Hi Robbin, >>> >>> On 9/03/2016 7:02 PM, Robbin Ehn wrote: >>>> >>>> Hi, please review this minor change. >>> >>> A notification mechanism is not so minor - what are the programming >>> rules for the callbacks? which threads might execute them? Are there >>> any >>> obvious deadlock/livelock potentials? Do we need to unregister a >>> callback? >>> >>> At a minimum there should be some comments regarding the nature of the >>> callback and what it can and can't do. >> >> Yes, I will document it better. >> >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >>>> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ >>> >>> Some minor nits: >>> >>> src/share/vm/logging/log.cpp >>> >>> Copyright needs 2016 added. >>> >>> --- >>> >>> src/share/vm/logging/logConfiguration.cpp >>> >>> + assert(cb != NULL, "Should not initialize register NULL as >>> listener."); >>> >>> "initialize register" doesn't make grammatical sense - delete >>> "initialize" >>> >>> + for (size_t i=0;i<_n_listener_callbacks;i++) { >>> >>> Style nits: spaces around operators and after ; >>> >>> --- >>> >>> src/share/vm/logging/logConfiguration.hpp >>> >>> + // After any configuration change this method should be called >>> by in >>> scope of LogConfigurationLock >>> >>> Delete 'by' - or may I suggest: >>> >>> // This should be called after any configuration change while still >>> holding ConfigurationLock >>> >> >> Yes, thanks! >> >> /Robbin >> >>> Thanks, >>> David >>> ----- >>> >>>> Tested with a new internal vm test (included). >>>> >>>> Thanks! >>>> >>>> /Robbin From cheleswer.sahu at oracle.com Mon Mar 14 09:15:11 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Mon, 14 Mar 2016 02:15:11 -0700 (PDT) Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <56E6189A.1010409@oracle.com> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> <56E6189A.1010409@oracle.com> Message-ID: <9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default> Thanks David. I have created change-set against hs-rt which is identical to jdk9/dev. Copyright year is already updated in hs-rt file. Just for reference I have uploaded the latest change-set in the below link. http://cr.openjdk.java.net/~csahu/8151509/webrev.02/ Thanks , Cheleswer -----Original Message----- From: David Holmes Sent: Monday, March 14, 2016 7:19 AM To: Cheleswer Sahu; Dmitry Dmitriev; Thomas St?fe Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly On 11/03/2016 9:38 PM, Cheleswer Sahu wrote: > Thanks Dmitry and Thomas for reviews. After adding space I will request for the push. Consider this Reviewed. But this needs to pushed to hs-rt and currently the webrev is against jdk9/dev. Thanks, David > > > Regards, > > Cheleswer > > > > From: Dmitry Dmitriev > Sent: Friday, March 11, 2016 5:00 PM > To: Cheleswer Sahu; Thomas St?fe > Cc: serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer > is not updated correctly > > > > Hi Cheleswer, > > Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. > > Thanks, > Dmitry > > > > On 11.03.2016 12:31, Cheleswer Sahu wrote: > > Hi Thomas, Dmitry, > > > > Thanks for your review comments. My answers are below for your review > comments > > > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > > > >>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will not able to read the data, it will return lesser number of bytes, which contains the partial data of ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. > > > > 2) Just interesting, do you really need to set memory to 0 by memset? > >>> I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. > > > > For rest of the comments I have made correction in the code. The new > webrev is available in the below location > > HYPERLINK > "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.open > jdk.java.net/~csahu/8151509/webrev.01/ > > > > > > Regards, > > Cheleswer > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Thursday, March 10, 2016 7:39 PM > To: Dmitry Dmitriev > Cc: Cheleswer Sahu; HYPERLINK > "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk > .java.net; HYPERLINK > "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openj > dk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer > is not updated correctly > > > > (Sorry, pressed Send button too early) > > Just wanted to add that > > 1873 if( 0 != ret % sizeof(prmap_t)){ > 1874 break; > 1875 } > > may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: > > Hi Cheleswer, > > > > thanks for fixing this. > > > > Some more issues: > > > > - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); > > > > Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. > > > > - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, > ",p->pr_vaddr, p->pr_size/1024); > > > > Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. > > (But I know this coding was there before) > > > > Beside those points, I think both points of Dmitry are valid. > > > > Also, I find > > > > > > Kind Regards, Thomas > > > > On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: > > Hi Cheleswer, > > Looks good, but I have questions/comments about other code in this function: > 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". > 2) Just interesting, do you really need to set memory to 0 by memset? > > Thanks, > Dmitry > > > On 10.03.2016 13:43, Cheleswer Sahu wrote: > > > Hi, > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. > > Webrev link: HYPERLINK > "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.n > et/~csahu/8151509/ > > Bug Brief: > > In check_addr0(), pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. > > Regards, > > Cheleswer > > > > > > > > > From robbin.ehn at oracle.com Mon Mar 14 09:24:39 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 14 Mar 2016 10:24:39 +0100 Subject: RFR(s): 8151264: Add a notification mechanism for UL configuration changes In-Reply-To: <56E679C4.9090706@oracle.com> References: <56DFE68E.3070506@oracle.com> <56E14A30.4000601@oracle.com> <56E14EC2.6010204@oracle.com> <56E2D5EC.8000505@oracle.com> <56E679C4.9090706@oracle.com> Message-ID: <56E68357.3010005@oracle.com> Thanks Marcus, I'll update before push. (no webrev) /Robbin On 03/14/2016 09:43 AM, Marcus Larsson wrote: > Hi, > > On 03/11/2016 03:27 PM, Robbin Ehn wrote: >> Hi, please review this updated changeset. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8151264/v2/webrev/ > > Looks good. Just one comment: Right now listeners are referred to as > both "config listeners" and "update listeners" in different places. > Would be good to use only one name for them to prevent confusion. > > Thanks, > Marcus > >> >> Thanks! >> >> /Robbin >> >> On 03/10/2016 11:38 AM, Robbin Ehn wrote: >>> Thanks David for looking at this. >>> >>> On 03/10/2016 11:19 AM, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> On 9/03/2016 7:02 PM, Robbin Ehn wrote: >>>>> >>>>> Hi, please review this minor change. >>>> >>>> A notification mechanism is not so minor - what are the programming >>>> rules for the callbacks? which threads might execute them? Are there >>>> any >>>> obvious deadlock/livelock potentials? Do we need to unregister a >>>> callback? >>>> >>>> At a minimum there should be some comments regarding the nature of the >>>> callback and what it can and can't do. >>> >>> Yes, I will document it better. >>> >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151264/ >>>>> Webrev: http://cr.openjdk.java.net/~rehn/8151264/webrev/ >>>> >>>> Some minor nits: >>>> >>>> src/share/vm/logging/log.cpp >>>> >>>> Copyright needs 2016 added. >>>> >>>> --- >>>> >>>> src/share/vm/logging/logConfiguration.cpp >>>> >>>> + assert(cb != NULL, "Should not initialize register NULL as >>>> listener."); >>>> >>>> "initialize register" doesn't make grammatical sense - delete >>>> "initialize" >>>> >>>> + for (size_t i=0;i<_n_listener_callbacks;i++) { >>>> >>>> Style nits: spaces around operators and after ; >>>> >>>> --- >>>> >>>> src/share/vm/logging/logConfiguration.hpp >>>> >>>> + // After any configuration change this method should be called >>>> by in >>>> scope of LogConfigurationLock >>>> >>>> Delete 'by' - or may I suggest: >>>> >>>> // This should be called after any configuration change while still >>>> holding ConfigurationLock >>>> >>> >>> Yes, thanks! >>> >>> /Robbin >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Tested with a new internal vm test (included). >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin > From marcus.larsson at oracle.com Mon Mar 14 10:29:56 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Mar 2016 11:29:56 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E54911.9090807@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com> <56E54911.9090807@oracle.com> Message-ID: <56E692A4.6010204@oracle.com> Hi, Thanks for looking at this! On 03/13/2016 12:03 PM, Dmitry Samersoff wrote: > Marcus, > > 1. os_posix/os_windows.cpp > > Windows version is expensive and change access time of a log file. > > So it's better to create os::get_mtime() that uses stat() for both, > windows and posix and LogFileOutput::calc_mtime_diff(). > > Also it saves a bit of compiler power unrolling loop. This is similar to my first approach but I ran into problems with it because st_mtime is a struct timespec on posix and a time_t on windows. From the start I wanted better precision than seconds, which is why I wanted to use CompareFileTime(). Given that we can not depend on any particular precision, perhaps it's better to just use stat() on windows as well, like you say. > > 2. log.cpp > > size_t number_of_lines_with_substring_in_file() > > When you plan to use it ? Current implementation is rather expensive, > but if you plan to run it manually only, I'm OK with it. It's used for testing only. > > 3. logFileOutput.cpp > > 82. > Please, change file_exists to can_be_rotated() and check that log output > is a *regular file* and you have a write access to it. I guess it would be useful to give an error in the case someone specifies logging to something that's not a regular file. Checking for write permissions shouldn't be necessary here though. If any of the required operations fail because of lacking permissions we'll notice that at that time. > > 87. > Please, don't use floating point math. Just allocate 10 extra bytes, it > fit all possible file length value. I can use a fixed size for the allocations, but we will still want to figure out how many numbers should be used so that we can use the appropriate amount of padding. Logging with 10 files in rotation should use log.0 to log.9, not log.0000000 to log.0000009. > > 93. > if we have log.01, log.03 etc this function creates log.02 instead of > log.04. Yes, that's intentional. > > Sorry! I'm not follow logic of ll.118 > What happens if some log parsing tool change log file mtime? We'll always prefer to overwrite the file that hasn't been modified for the longest time. > > Please, limit the number of old logs (FileCountOption) to some > reasonable value (e.g. 999) and use binary search to find the name of a > next file. I can limit it, but I'm not sure we should make the effort of binary searching for the file name. It's a one time search during startup and I would expect most people to use around 10 files. > > Also please check full log file name against MAX_PATH constant. Is it really necessary? Won't fopen() just fail and return the appropriate error for this? Thanks, Marcus > > -Dmitry > > > > > On 2016-03-11 17:39, Marcus Larsson wrote: >> Hi, >> >> On 2016-03-11 15:35, Bengt Rutisson wrote: >>> Hi Marcus, >>> >>> On 2016-03-11 15:21, Marcus Larsson wrote: >>>> Third time's the charm. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>> I had a quick look at the code changes. It is not really my area of >>> the code, so I'll leave to someone else to formally review it. >>> >>> However, I downloaded the patch a played a bit with the logging. This >>> is much more like the way I would like it! Thanks! >>> >>> So, from a functional perspective this looks good to me. >>> >> Thanks for the feedback! >> >> Marcus >> >>> Thanks, >>> Bengt >>> >>>> This patch makes log file rotation the default. Default thresholds >>>> are 5 rotated files with a target size of 20MiB. Truncating behavior >>>> can be achieved by setting filecount to 0 >>>> (-Xlog::myfile.log::filecount=0). >>>> >>>> If a log file already exists during log file initialization it will >>>> be rotated. If any of the target file names (file.0 to file.4 in the >>>> default case) are available, that filename will be used for the >>>> existing log. If all names are taken the VM will attempt to overwrite >>>> the oldest file. >>>> >>>> This should prevent unlimited log file creations and avoid accidental >>>> loss of log files from previous runs. The default thresholds (5 >>>> files, 20MiB each) is just a suggestion. If you think it should be >>>> higher/lower let me know. >>>> >>>> Tested with included internal VM tests through RBT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> After some offline discussions I'm withdrawing this patch. I will >>>>> instead investigate if I can achieve similar behavior using log >>>>> rotation as the default. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>>> Hi again, >>>>>> >>>>>> Taking a different approach to this. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>>> >>>>>> Existing files will now by default be renamed/archived with a .X >>>>>> suffix where X is the lowest number such that the resulting file >>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>>>> controlling this behavior has been added as well. It can be set to >>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>>> >>>>>> Tested with included jtreg test through JPRT. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following patch to make sure UL truncates >>>>>>> existing log files before writing to them. Since files are opened >>>>>>> in append mode, truncation isn't done automatically, so instead >>>>>>> the patch adds an attempt to remove the log file before opening it. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>>> >>>>>>> Testing: >>>>>>> Included test through JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus > From marcus.larsson at oracle.com Mon Mar 14 10:34:16 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Mar 2016 11:34:16 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2E95B.8050500@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2E95B.8050500@oracle.com> Message-ID: <56E693A8.8010108@oracle.com> Hi, On 03/11/2016 04:50 PM, Robbin Ehn wrote: > Hi Marcus, > > Two small things. > > src/share/vm/runtime/os.hpp: > + static int compare_file_modified_times(const char* file1, const > char* file2); > Is this so generic that we should have it os.[h,c]pp? > E.g. if we want to compare ctime, etc.. ? I didn't want to add a bunch of unused functionality for this so I kept it simple. If we need ctime or atime at a later point I think we should just refactor this or add it separately. > > On 03/11/2016 03:21 PM, Marcus Larsson wrote: >> Third time's the charm. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >> >> This patch makes log file rotation the default. Default thresholds are 5 >> rotated files with a target size of 20MiB. Truncating behavior can be >> achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). > > src/share/vm/logging/logFileOutput.hpp: > + static const size_t DefaultRotationFileSize = 2097152; // 20MiB > Missing a 0 here, I prefer to write this as 20*1024*1024 Great catch! I'll change this to use the M constant, making it 20*M. > >> >> If a log file already exists during log file initialization it will be >> rotated. If any of the target file names (file.0 to file.4 in the >> default case) are available, that filename will be used for the existing >> log. If all names are taken the VM will attempt to overwrite the oldest >> file. >> >> This should prevent unlimited log file creations and avoid accidental >> loss of log files from previous runs. The default thresholds (5 files, >> 20MiB each) is just a suggestion. If you think it should be higher/lower >> let me know. >> >> Tested with included internal VM tests through RBT. > > I also functional tested this and it works as intended. > There is an issue regarding removing the current log file. > Discussed in side-channel it will be handled outside this CS since it > not directly related. > > Otherwise looks good! Thanks for looking at it! Marcus > > /Robbin > >> >> Thanks, >> Marcus >> >> On 2016-03-01 15:05, Marcus Larsson wrote: >>> Hi, >>> >>> After some offline discussions I'm withdrawing this patch. I will >>> instead investigate if I can achieve similar behavior using log >>> rotation as the default. >>> >>> Thanks, >>> Marcus >>> >>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Taking a different approach to this. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>> >>>> Existing files will now by default be renamed/archived with a .X >>>> suffix where X is the lowest number such that the resulting file name >>>> is available (jvm.log becomes jvm.log.0). A mode option for >>>> controlling this behavior has been added as well. It can be set to >>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>> >>>> Tested with included jtreg test through JPRT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to make sure UL truncates existing >>>>> log files before writing to them. Since files are opened in append >>>>> mode, truncation isn't done automatically, so instead the patch adds >>>>> an attempt to remove the log file before opening it. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>> >>>>> Testing: >>>>> Included test through JPRT >>>>> >>>>> Thanks, >>>>> Marcus >>>> >>> >> From marcus.larsson at oracle.com Mon Mar 14 10:52:41 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Mar 2016 11:52:41 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> Message-ID: <56E697F9.7020301@oracle.com> Hi, On 03/11/2016 05:40 PM, Gerard Ziemski wrote: > hi Marcus, > > I?m still going through the webrev, but I thought I would report my feedback so far. Thanks for looking at this! > > ------------------------------------------------ > #1 File src/os/posix/vm/os_posix.cpp > > How about instead of: > > +int os::compare_file_modified_times(const char* file1, const char* file2) { > + struct stat st[2]; > + struct timespec filetime[2]; > + > + for (int i = 0; i < 2; i++) { > + const char* file = (i == 0 ? file1 : file2); > + int ret = os::stat(file, &st[i]); > + assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno)); > +#ifdef __APPLE__ > + filetime[i] = st[i].st_mtimespec; > +#else > + filetime[i] = st[i].st_mtim; > +#endif > + } > + > + int diff = filetime[0].tv_sec - filetime[1].tv_sec; > + if (diff == 0) { > + return filetime[0].tv_nsec - filetime[1].tv_nsec; > + } > + return diff; > +} > > we have something like this, which doesn?t use arrays or a loop mimicking inline function: > > static inline struct timespec get_timespec(const char* file) { > struct stat st; > int ret = stat(file, &st); > assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno)); > #ifdef __APPLE__ > return st.st_mtimespec; > #else > return st.st_mtim; > #endif > } > > int compare_file_modified_times(const char* file1, const char* file2) { > struct timespec filetime1 = get_timespec(file1); > struct timespec filetime2 = get_timespec(file2); > int diff = filetime1.tv_sec - filetime2.tv_sec; > if (diff == 0) { > return filetime1.tv_nsec - filetime2.tv_nsec; > } > return diff; > } > > Similarly we should use static inline function instead of a loop in src/os/windows/vm/os_windows.cpp Good suggestions, will update. > > ----------------------------------------------- > #2 File src/share/vm/logging/log.cpp > > Doesn?t this function produce an error or at least a warning on a product build without asserts? > > +static void delete_file(const char* filename) { > + if (!file_exists(filename)) { > + return; > + } > + int ret = remove(filename); > + assert(ret == 0, "failed to remove file '%s': %s", filename, strerror(errno)); > +} I haven't run in to any problems with this. I'm guessing I should've failed to build in JPRT if this was a problem, given that we treat warnings as errors. > > ----------------------------------------------- > #3 File src/share/vm/logging/log.cpp > > The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with: > > char buf[16]; > > and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard") Yeah I'm aware of this limitation. It's only used in the test though, where I'm hoping it won't be a problem. Would a comment about this be enough? > > ----------------------------------------------- > #4 File src/share/vm/logging/log.cpp > > Should we clarify that we are rounding the results of log10 down by explicitly using floor and explicitly casting it to uint? > > static uint number_of_digits_new(uint number) { > double d = static_cast(number); > uint res = 1 + static_cast(floor(log10(d))); > return res; > } > > cheers Seems like a good idea to me. Thanks, Marcus > > >> On Mar 11, 2016, at 8:21 AM, Marcus Larsson wrote: >> >> Third time's the charm. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >> >> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >> >> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >> >> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >> >> Tested with included internal VM tests through RBT. >> >> Thanks, >> Marcus >> >> On 2016-03-01 15:05, Marcus Larsson wrote: >>> Hi, >>> >>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>> >>> Thanks, >>> Marcus >>> >>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Taking a different approach to this. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>> >>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>> >>>> Tested with included jtreg test through JPRT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>> >>>>> Testing: >>>>> Included test through JPRT >>>>> >>>>> Thanks, >>>>> Marcus From david.holmes at oracle.com Mon Mar 14 12:20:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Mar 2016 22:20:46 +1000 Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly In-Reply-To: <9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default> References: <56E16C85.30102@oracle.com> <6472a6fc-3197-4f42-927a-2b0ab0663a60@default> <56E2AC28.4040306@oracle.com> <56E6189A.1010409@oracle.com> <9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default> Message-ID: <56E6AC9E.8070605@oracle.com> On 14/03/2016 7:15 PM, Cheleswer Sahu wrote: > Thanks David. > I have created change-set against hs-rt which is identical to jdk9/dev. Copyright year is already updated in hs-rt file. Just for reference I have uploaded the latest change-set in the below link. > http://cr.openjdk.java.net/~csahu/8151509/webrev.02/ Looks good. Thanks, David > Thanks , > Cheleswer > > -----Original Message----- > From: David Holmes > Sent: Monday, March 14, 2016 7:19 AM > To: Cheleswer Sahu; Dmitry Dmitriev; Thomas St?fe > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly > > On 11/03/2016 9:38 PM, Cheleswer Sahu wrote: >> Thanks Dmitry and Thomas for reviews. After adding space I will request for the push. > > Consider this Reviewed. > > But this needs to pushed to hs-rt and currently the webrev is against jdk9/dev. > > Thanks, > David > >> >> >> Regards, >> >> Cheleswer >> >> >> >> From: Dmitry Dmitriev >> Sent: Friday, March 11, 2016 5:00 PM >> To: Cheleswer Sahu; Thomas St?fe >> Cc: serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer >> is not updated correctly >> >> >> >> Hi Cheleswer, >> >> Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that. >> >> Thanks, >> Dmitry >> >> >> >> On 11.03.2016 12:31, Cheleswer Sahu wrote: >> >> Hi Thomas, Dmitry, >> >> >> >> Thanks for your review comments. My answers are below for your review >> comments >> >> >> >> 1873 if( 0 != ret % sizeof(prmap_t)){ >> 1874 break; >> 1875 } >> >> >> >> >>>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will not able to read the data, it will return lesser number of bytes, which contains the partial data of ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. >> >> >> >> 2) Just interesting, do you really need to set memory to 0 by memset? >> >>>> I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code. >> >> >> >> For rest of the comments I have made correction in the code. The new >> webrev is available in the below location >> >> HYPERLINK >> "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.open >> jdk.java.net/~csahu/8151509/webrev.01/ >> >> >> >> >> >> Regards, >> >> Cheleswer >> >> >> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> Sent: Thursday, March 10, 2016 7:39 PM >> To: Dmitry Dmitriev >> Cc: Cheleswer Sahu; HYPERLINK >> "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk >> .java.net; HYPERLINK >> "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openj >> dk.java.net >> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer >> is not updated correctly >> >> >> >> (Sorry, pressed Send button too early) >> >> Just wanted to add that >> >> 1873 if( 0 != ret % sizeof(prmap_t)){ >> 1874 break; >> 1875 } >> >> may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record. >> >> Kind Regards, Thomas >> >> >> >> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe wrote: >> >> Hi Cheleswer, >> >> >> >> thanks for fixing this. >> >> >> >> Some more issues: >> >> >> >> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1); >> >> >> >> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary. >> >> >> >> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, >> ",p->pr_vaddr, p->pr_size/1024); >> >> >> >> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024. >> >> (But I know this coding was there before) >> >> >> >> Beside those points, I think both points of Dmitry are valid. >> >> >> >> Also, I find >> >> >> >> >> >> Kind Regards, Thomas >> >> >> >> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev wrote: >> >> Hi Cheleswer, >> >> Looks good, but I have questions/comments about other code in this function: >> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {". >> 2) Just interesting, do you really need to set memory to 0 by memset? >> >> Thanks, >> Dmitry >> >> >> On 10.03.2016 13:43, Cheleswer Sahu wrote: >> >> >> Hi, >> >> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. >> >> Webrev link: HYPERLINK >> "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.n >> et/~csahu/8151509/ >> >> Bug Brief: >> >> In check_addr0(), pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer. >> >> Regards, >> >> Cheleswer >> >> >> >> >> >> >> >> >> From robbin.ehn at oracle.com Mon Mar 14 13:34:42 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 14 Mar 2016 14:34:42 +0100 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <56E65E62.8040003@oracle.com> References: <56E65E62.8040003@oracle.com> Message-ID: <56E6BDF2.2010201@oracle.com> Hi David, On 03/14/2016 07:46 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 > Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ This looks good to me. /Robbin > > This isn't a fix per-se but some additional diagnostic code to try and > detect the conditions where the bug might manifest. The basic failure > mode was: > > # Internal Error > (/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950), > pid=27906, tid=13248 > # assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: > Must be VMThread or JavaThread > > with a stack showing in part: > > #34 0xf6623ec0 in report_vm_error ( > file=0xf71b6140 > "/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp", > line=3901, > error_msg=0xf71b62e0 "assert(thread->is_VM_thread() || > thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be > VMThread or JavaThread") > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218 > > #35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc, > context=0xc1b58d4c) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901 > > #36 > #37 0xf776b430 in __kernel_vsyscall () > #38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0 > #39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879 > > #40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg= out>) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367 > > #41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800, > __in_chrg=) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611 > > #42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800, > __in_chrg=) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655 > > #43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724 > > #44 0xf6f74e12 in JavaThread::run (this=0xc20cd800) > at > /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698 > > #45 0xf6d238ec in java_start (thread=0xc20cd800) > > What appears to be happening is that the thread has blocked SR_signum > (SIGUSR2) at some point (though there is no code that does this), and > the signal has become pending on the thread due to the event sampling > logic. The thread terminates, executing well into the destructor until > it gets to os::free_thread which restores the original signal mask for > the thread - that signal mask has SR_signum unblocked and so the signal > is delivered immediately and we enter the SR_handler. For some reason > this triggers the assertion failure - though why exactly is unclear as > we have not released the thread memory as yet, nor done anything that > should invalidate that call. Whatever the reason the state of the thread > causes secondary failures in the error reporting code as well. > > Attempts to reproduce this bug have been unsuccessful (so maybe we had a > random memory stomp on the thread state - who knows.) > > So what I am doing is simply adding an additional assertion to try and > catch, during regular testing, any occurrence of SR_signum being > blocked while a thread is terminating. > > In addition a couple of minor cleanups in the signal related code: > - strictly speaking SR_handler needs to use > Thread::current_or_null_safe() because it needs ot use library-based TLS > in a signal context. > - sigsets should (POSIX recommendation) be explicitly emptied/filled > before being set via pthread_sigmask > - change 0 to NULL in call to pthread_sigmask > > Testing: - JPRT, original failing testcase > > Thanks, > David From dmitry.samersoff at oracle.com Mon Mar 14 15:06:45 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 14 Mar 2016 18:06:45 +0300 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E692A4.6010204@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com> <56E54911.9090807@oracle.com> <56E692A4.6010204@oracle.com> Message-ID: <56E6D385.4000708@oracle.com> Marcus, 1. Most of log analyzing tools utilize the fact that filesystem returns files in alphabetical order or uses scandir()/alphasort() So good log rotation strategy is log, log.001, log.002, log.003 etc where "log" is current one and log.MAX_COUNT is the oldest one. To save startup time we can declare that log.001 is the oldest one, and log.MAX_COUNT is the newest one but log.002 that is more recent than log.001 and log.003 seems not obvious to me. Also it's very common that log producer and log analyzer resides on a different machines (e.g. with NFS share) and log file mtime could be unrelated to the age of VM events in this log. So we shouldn't use log mtime for any decision. 2. rename() can cause a burden in complicated environment, so it's better to check most common cases (permissions, PATH_MAX, etc) explicitly, as early as possible, to give meaningful error message to a user. See also below. On 2016-03-14 13:29, Marcus Larsson wrote: > Hi, > > Thanks for looking at this! > > On 03/13/2016 12:03 PM, Dmitry Samersoff wrote: >> Marcus, >> >> 1. os_posix/os_windows.cpp >> >> Windows version is expensive and change access time of a log file. >> >> So it's better to create os::get_mtime() that uses stat() for both, >> windows and posix and LogFileOutput::calc_mtime_diff(). >> >> Also it saves a bit of compiler power unrolling loop. > > This is similar to my first approach but I ran into problems with it > because st_mtime is a struct timespec on posix and a time_t on windows. > From the start I wanted better precision than seconds, which is why I > wanted to use CompareFileTime(). Given that we can not depend on any > particular precision, perhaps it's better to just use stat() on windows > as well, like you say. OK. >> 2. log.cpp >> >> size_t number_of_lines_with_substring_in_file() >> >> When you plan to use it ? Current implementation is rather expensive, >> but if you plan to run it manually only, I'm OK with it. > > It's used for testing only. If you plan to use it in jprt or nightly - please change it. >> 3. logFileOutput.cpp >> >> 82. >> Please, change file_exists to can_be_rotated() and check that log output >> is a *regular file* and you have a write access to it. > > I guess it would be useful to give an error in the case someone > specifies logging to something that's not a regular file. Checking for > write permissions shouldn't be necessary here though. If any of the > required operations fail because of lacking permissions we'll notice > that at that time. Logging to /dev/tape or /dev/console is perfectly valid usecase but we should detect it and don't attempt to rotate or truncate device ever if sysadmin enable rotation by mistake. Also common sysadmin mistake is a log pointing to directory or presence of log.NNN directory - we should detect it as well. One more case when we shouldn't rotate - log is symlink >> 87. >> Please, don't use floating point math. Just allocate 10 extra bytes, it >> fit all possible file length value. > > I can use a fixed size for the allocations, but we will still want to > figure out how many numbers should be used so that we can use the > appropriate amount of padding. Logging with 10 files in rotation should > use log.0 to log.9, not log.0000000 to log.0000009. It's OK to always write log.001 etc or use something like: return (num < 10) ? 1 : (num < 100) ? 2 : 5; >> 93. >> if we have log.01, log.03 etc this function creates log.02 instead of >> log.04. > > Yes, that's intentional. log.01 and log.03 both containing older data than log.02 seems not obvious for me. Could we always use largest possible number? >> >> Sorry! I'm not follow logic of ll.118 >> What happens if some log parsing tool change log file mtime? > > We'll always prefer to overwrite the file that hasn't been modified for > the longest time. Log file mtime can be unrelated to the age of VM events in this file (think sysadmin do: vi log.003, :wq) so we shouldn't rely on mtime. >> Please, limit the number of old logs (FileCountOption) to some >> reasonable value (e.g. 999) and use binary search to find the name of a >> next file. > > I can limit it, but I'm not sure we should make the effort of binary > searching for the file name. It's a one time search during startup and I > would expect most people to use around 10 files. OK, as soon as DefaultRotationFileCount is less than 10 >> Also please check full log file name against MAX_PATH constant. > > Is it really necessary? Won't fopen() just fail and return the > appropriate error for this? rename errors is not always obvious. see comments above. -Dmitry > > Thanks, > Marcus > >> >> -Dmitry >> >> >> >> >> On 2016-03-11 17:39, Marcus Larsson wrote: >>> Hi, >>> >>> On 2016-03-11 15:35, Bengt Rutisson wrote: >>>> Hi Marcus, >>>> >>>> On 2016-03-11 15:21, Marcus Larsson wrote: >>>>> Third time's the charm. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>>> I had a quick look at the code changes. It is not really my area of >>>> the code, so I'll leave to someone else to formally review it. >>>> >>>> However, I downloaded the patch a played a bit with the logging. This >>>> is much more like the way I would like it! Thanks! >>>> >>>> So, from a functional perspective this looks good to me. >>>> >>> Thanks for the feedback! >>> >>> Marcus >>> >>>> Thanks, >>>> Bengt >>>> >>>>> This patch makes log file rotation the default. Default thresholds >>>>> are 5 rotated files with a target size of 20MiB. Truncating behavior >>>>> can be achieved by setting filecount to 0 >>>>> (-Xlog::myfile.log::filecount=0). >>>>> >>>>> If a log file already exists during log file initialization it will >>>>> be rotated. If any of the target file names (file.0 to file.4 in the >>>>> default case) are available, that filename will be used for the >>>>> existing log. If all names are taken the VM will attempt to overwrite >>>>> the oldest file. >>>>> >>>>> This should prevent unlimited log file creations and avoid accidental >>>>> loss of log files from previous runs. The default thresholds (5 >>>>> files, 20MiB each) is just a suggestion. If you think it should be >>>>> higher/lower let me know. >>>>> >>>>> Tested with included internal VM tests through RBT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> After some offline discussions I'm withdrawing this patch. I will >>>>>> instead investigate if I can achieve similar behavior using log >>>>>> rotation as the default. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>>>> Hi again, >>>>>>> >>>>>>> Taking a different approach to this. >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>>>> >>>>>>> Existing files will now by default be renamed/archived with a .X >>>>>>> suffix where X is the lowest number such that the resulting file >>>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>>>>> controlling this behavior has been added as well. It can be set to >>>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>>>> >>>>>>> Tested with included jtreg test through JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the following patch to make sure UL truncates >>>>>>>> existing log files before writing to them. Since files are opened >>>>>>>> in append mode, truncation isn't done automatically, so instead >>>>>>>> the patch adds an attempt to remove the log file before opening it. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>>>> >>>>>>>> Testing: >>>>>>>> Included test through JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >> > -- 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 thomas.schatzl at oracle.com Mon Mar 14 15:16:06 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Mar 2016 16:16:06 +0100 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E2EB60.6080507@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <1457642805.2363.5.camel@oracle.com> <56E2EB60.6080507@oracle.com> Message-ID: <1457968566.2280.62.camel@oracle.com> Hi Jon, On Fri, 2016-03-11 at 07:59 -0800, Jon Masamitsu wrote: > > On 3/10/2016 12:46 PM, Thomas Schatzl wrote: > > Hi, > > > > On Thu, 2016-03-10 at 15:42 -0500, Kim Barrett wrote: > > > > On Mar 10, 2016, at 12:21 PM, Jon Masamitsu < > > > > jon.masamitsu at oracle.com> wrote: > > > > > > > > > > > > > > [...] > > > The retry setting to parallel_worker_threads() again code dates > > > back > > > to the initial G1 checkin. Hard to know what was intended. > > > > > > The current jdk9 code does not have that: it looks like > > > > > > FLAG_SET_DEFAULT(ParallelGCThreads, > > > Abstract_VM_Version::parallel_worker_threads()); > > > if (ParallelGCThreads == 0) { > > > assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default > > > value > > > for ParallelGCThreads should not be 0."); > > > vm_exit_during_initialization("The flag -XX:+UseG1GC can not > > > be > > > combined with -XX:ParallelGCThreads=0", NULL); > > > } > > > > > > This proposed change is for jdk8u-something, correct? > > > > > > In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can > > > be > > > seen above. Making use of that decision, a cleanup pass was made > > > that eliminated a whole bunch of ?if (ParallelGCThreads == 0) > > > then > > > pretend it?s 1 or do some other special thing? code. The > > > backport of > > > 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken > > > that into account. For example, > > just some historical note: in 8u, ParallelGCThreads == 0 means "use > > the > > VM thread, single threaded", and ParallelGCThreads == 1 means use a > > single worker thread. > > By "VM thread, single threaded" I believe you mean that we used the > serial version (no threading code) and let the VM execute it. I > recall this being the case with some ParNew code. I am not too well-versed into parnew, but actually we used the same code. We could do that because we encapsulated parallel work into these AbstractGangTasks. The code typically looks like the following: SomeTask cl; if (ParallelGCThreads != 0) { workers()->run_task(&cl); } else { cl.do_work(0); } (Actually sometimes there is a copy&paste in the else-path...) > > > In jdk9 we removed that option to use the vm thread in a single > > threaded way. > > > > We did not backport that change because of potential performance > > impact > > (whatever that might be). > > This can be fixed while leaving the ParallelGCThreads == 0 as an > option for G1. > In the 8u it is no longer an option for ParNew nor ParallelGC (both > prohibit > ParallelGCThreads == 0 in the argument processing). > > How about we make G1 like the other collectors in 8u and prohibit > ParallelGCThreads == 0. That would be the simplest and most > consistent thing to do (in my opinion). Fine with me. What's your suggestion on how to achieve this? Backport the jdk9 change that removed that, or hack it in for jdk8? Thanks, Thomas From rachel.protacio at oracle.com Mon Mar 14 18:23:39 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 14 Mar 2016 14:23:39 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging Message-ID: <56E701AB.6060705@oracle.com> Hi, Please review this change, converting -XX:+TraceClearedExceptions to -Xlog:exceptions=debug. (This change replaces the one I sent out earlier that was going to delete the option.) Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ Passes JPRT; if you'd like to see additional testing, please let me know. Thank you, Rachel From jon.masamitsu at oracle.com Mon Mar 14 18:32:01 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 14 Mar 2016 11:32:01 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <1457968566.2280.62.camel@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <1457642805.2363.5.camel@oracle.com> <56E2EB60.6080507@oracle.com> <1457968566.2280.62.camel@oracle.com> Message-ID: <56E703A1.1020609@oracle.com> On 03/14/2016 08:16 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2016-03-11 at 07:59 -0800, Jon Masamitsu wrote: >> On 3/10/2016 12:46 PM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2016-03-10 at 15:42 -0500, Kim Barrett wrote: >>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu < >>>>> jon.masamitsu at oracle.com> wrote: >>>>> >>>>> >>>>> >>> [...] >>>> The retry setting to parallel_worker_threads() again code dates >>>> back >>>> to the initial G1 checkin. Hard to know what was intended. >>>> >>>> The current jdk9 code does not have that: it looks like >>>> >>>> FLAG_SET_DEFAULT(ParallelGCThreads, >>>> Abstract_VM_Version::parallel_worker_threads()); >>>> if (ParallelGCThreads == 0) { >>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default >>>> value >>>> for ParallelGCThreads should not be 0."); >>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not >>>> be >>>> combined with -XX:ParallelGCThreads=0", NULL); >>>> } >>>> >>>> This proposed change is for jdk8u-something, correct? >>>> >>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can >>>> be >>>> seen above. Making use of that decision, a cleanup pass was made >>>> that eliminated a whole bunch of ?if (ParallelGCThreads == 0) >>>> then >>>> pretend it?s 1 or do some other special thing? code. The >>>> backport of >>>> 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken >>>> that into account. For example, >>> just some historical note: in 8u, ParallelGCThreads == 0 means "use >>> the >>> VM thread, single threaded", and ParallelGCThreads == 1 means use a >>> single worker thread. >> By "VM thread, single threaded" I believe you mean that we used the >> serial version (no threading code) and let the VM execute it. I >> recall this being the case with some ParNew code. > I am not too well-versed into parnew, but actually we used the same > code. We could do that because we encapsulated parallel work into these > AbstractGangTasks. > > The code typically looks like the following: > > SomeTask cl; > if (ParallelGCThreads != 0) { > workers()->run_task(&cl); > } else { > cl.do_work(0); > } > > (Actually sometimes there is a copy&paste in the else-path...) > >>> In jdk9 we removed that option to use the vm thread in a single >>> threaded way. >>> >>> We did not backport that change because of potential performance >>> impact >>> (whatever that might be). >> This can be fixed while leaving the ParallelGCThreads == 0 as an >> option for G1. >> In the 8u it is no longer an option for ParNew nor ParallelGC (both >> prohibit >> ParallelGCThreads == 0 in the argument processing). >> >> How about we make G1 like the other collectors in 8u and prohibit >> ParallelGCThreads == 0. That would be the simplest and most >> consistent thing to do (in my opinion). > Fine with me. What's your suggestion on how to achieve this? Backport > the jdk9 change that removed that, or hack it in for jdk8? Hack it into jdk8. The latest change that I've seen that will do that is in the argument processing for G1. --- a/src/share/vm/runtime/arguments.cpp Wed Mar 09 19:51:23 2016 +0300 +++ b/src/share/vm/runtime/arguments.cpp Mon Mar 14 13:49:33 2016 +0000 @@ -1675,9 +1675,8 @@ FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); if (ParallelGCThreads == 0) { - FLAG_SET_DEFAULT(ParallelGCThreads, - Abstract_VM_Version::parallel_worker_threads()); - } + vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); + } Jon > > Thanks, > Thomas From max.ockner at oracle.com Mon Mar 14 18:48:29 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 14 Mar 2016 14:48:29 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E701AB.6060705@oracle.com> References: <56E701AB.6060705@oracle.com> Message-ID: <56E7077D.4090205@oracle.com> Rachel, I'm a bit confused to only see two files changed here. Did you leave some files out? Did you add the tag to logTag.hpp in another fix? Is there a test? Thanks, Max On 3/14/2016 2:23 PM, Rachel Protacio wrote: > Hi, > > Please review this change, converting -XX:+TraceClearedExceptions to > -Xlog:exceptions=debug. (This change replaces the one I sent out > earlier that was going to delete the option.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ > > Passes JPRT; if you'd like to see additional testing, please let me know. > > Thank you, > Rachel From jon.masamitsu at oracle.com Mon Mar 14 18:41:13 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 14 Mar 2016 11:41:13 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E65F81.5000909@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> Message-ID: <56E705C9.2010605@oracle.com> On 03/13/2016 11:51 PM, David Holmes wrote: > > > On 14/03/2016 4:34 PM, sangheon wrote: >> Hi David, >> >> On 03/13/2016 05:49 PM, David Holmes wrote: >>> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: >>>> >>>> >>>> On 3/10/2016 12:42 PM, Kim Barrett wrote: >>>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>>>>> Background: >>>>>>>> >>>>>>>> After the backport of >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>>>>> _workers to null in 8u. >>>>>>>> >>>>>>>> As there is no condition to handle such scenario in >>>>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>>>>> >>>>>>>> The similar condition is already implemented for following >>>>>>>> scenarios >>>>>>>> >>>>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fix: >>>>>>>> >>>>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp >>>>>>>> file >>>>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>>>>> >>>>>>>> Thanks for the base patch from Jon. >>>>>>>> >>>>>>>> Due to this patch it makes some of the test cases absolute. They >>>>>>>> have been removed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>>>>> This existing code looks wrong: >>>>>>> >>>>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>>>>> 1677 if (ParallelGCThreads == 0) { >>>>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>>>>> >>>>>>> Line 1678 seems to do the same as 1675 - is >>>>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected to >>>>>>> return a different value on the second call ?? >>>>>> No, Abstract_VM_Version::parallel_worker_threads() won't return a >>>>>> different >>>>>> value for a second call. It's harmless but would be cleaner >>>>>> deleting >>>>>> 1675,1676. >>>> >>>> I retract this suggestion to delete 1675-1676. I'll 99.99% sure >>>> that it >>>> would be >>>> OK, but argument processing being what it is and this being an update >>>> fix, >>>> leave those lines in. I've been surprised before. >>> >>> Okay on being conservative here. But I repeat my earlier statement: >>> >>> That aside I'm confused by the fix as we have: >>> >>> ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, 0, >>> >>> so it seems odd to report an error for setting a value that is already >>> the default ?? >> A flag's value set by default(FLAG_IS_DEFAULT) is different from set by >> command-line(FLAG_SET_CMDLINE) when we process that flag. >> Usually a flag that has a default value of '0' means 'will be decided >> ergonomically'. > > Is this a well-defined convention? I thought that when zero means "use > the default" (ie ergonomics or whatever) that it always means that > regardless of whether it is set explicitly or not! It's not a well defined convention. It is something that happened in one of the GC's and then was imitated or not in others. If there is a code path for ParallelGCThreads==0 (that's not calculate me ergonomically), then explicit setting on the command line of ParallelGCThreads to 0 executes that code path. That exception has been removed in jdk9. Jon > > Thanks, > David > > >> >> From above example, >> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1676 Abstract_VM_Version::parallel_worker_threads()); >> 1677 if (ParallelGCThreads == 0) { >> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >> 1679 Abstract_VM_Version::parallel_worker_threads()); >> >> line1676, parallel_worker_threads() is checking whether the flag is a >> default value or not. >> And use the value if it is not 'set-by-default'. >> >> unsigned int Abstract_VM_Version::parallel_worker_threads() { >> if (!_parallel_worker_threads_initialized) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >> _parallel_worker_threads = >> VM_Version::calc_parallel_worker_threads(); >> } else { >> _parallel_worker_threads = ParallelGCThreads; >> } >> _parallel_worker_threads_initialized = true; >> } >> return _parallel_worker_threads; >> } >> >> Thanks, >> Sangheon >> >> >>> >>> David >>> ----- >>> >>>>> The retry setting to parallel_worker_threads() again code dates back >>>>> to the initial G1 checkin. Hard to know what was intended. >>>>> >>>>> The current jdk9 code does not have that: it looks like >>>>> >>>>> FLAG_SET_DEFAULT(ParallelGCThreads, >>>>> Abstract_VM_Version::parallel_worker_threads()); >>>>> if (ParallelGCThreads == 0) { >>>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value >>>>> for ParallelGCThreads should not be 0."); >>>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be >>>>> combined with -XX:ParallelGCThreads=0", NULL); >>>>> } >>>>> >>>>> This proposed change is for jdk8u-something, correct? >>>>> >>>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be >>>>> seen above. Making use of that decision, a cleanup pass was made >>>>> that >>>>> eliminated a whole bunch of ?if (ParallelGCThreads == 0) then pretend >>>>> it?s 1 or do some other special thing? code. The backport of 8017462 >>>>> to 8u72 (i.e. 8149347) looks like it might not have taken that into >>>>> account. For example, >>>>> >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6c57a16d0238 >>>>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed Feb >>>>> 17 13:42:03 2016 +0000 >>>>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu Feb >>>>> 18 20:30:45 2016 +0000 >>>>> @@ -3991,8 +3991,15 @@ >>>>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >>>>> - uint active_workers = >>>>> (G1CollectedHeap::use_parallel_gc_threads() ? >>>>> - workers()->active_workers() : 1); >>>>> + uint active_workers = >>>>> AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(), >>>>> + >>>>> workers()->active_workers(), >>>>> + >>>>> Threads::number_of_non_daemon_threads()); >>>>> >>>>> Note the conditionalization on use_parallel_gc_threads(). >>>>> >>>>> It might be that the simplest thing to do for 8u backporting is >>>>> indeed >>>>> to backport prevention of ParallelGCThreads == 0, as suggested in the >>>>> proposed patch. >>>> >>>> I agree although I'll also respond to Thomas next. >>>> >>>> Jon >>>> >>>>> >>>>> >>>>> >>>> >> From rachel.protacio at oracle.com Mon Mar 14 18:56:41 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 14 Mar 2016 14:56:41 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E7077D.4090205@oracle.com> References: <56E701AB.6060705@oracle.com> <56E7077D.4090205@oracle.com> Message-ID: <56E70969.3070007@oracle.com> Hi, Sorry for the confusion. I have previously converted TraceExceptions to Xlog:exceptions=info, so this change is merely adding the statement that was previously with TraceClearedExceptions into the "exceptions" tag, under the debug level. logging/ExceptionsTest.java tests the exceptions tag as a whole, and I did not add to it since this portion of code did not seem simple to trigger for the sake of a logging test. But of course I'm happy to add a case if someone has a specific avenue in mind. Rachel On 3/14/2016 2:48 PM, Max Ockner wrote: > Rachel, > I'm a bit confused to only see two files changed here. Did you leave > some files out? Did you add the tag to logTag.hpp in another fix? Is > there a test? > Thanks, > Max > > On 3/14/2016 2:23 PM, Rachel Protacio wrote: >> Hi, >> >> Please review this change, converting -XX:+TraceClearedExceptions to >> -Xlog:exceptions=debug. (This change replaces the one I sent out >> earlier that was going to delete the option.) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ >> >> Passes JPRT; if you'd like to see additional testing, please let me >> know. >> >> Thank you, >> Rachel > From david.holmes at oracle.com Mon Mar 14 21:14:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 07:14:58 +1000 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E701AB.6060705@oracle.com> References: <56E701AB.6060705@oracle.com> Message-ID: <56E729D2.5040402@oracle.com> Hi Rachel, On 15/03/2016 4:23 AM, Rachel Protacio wrote: > Hi, > > Please review this change, converting -XX:+TraceClearedExceptions to > -Xlog:exceptions=debug. (This change replaces the one I sent out earlier > that was going to delete the option.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ Looks good. > Passes JPRT; if you'd like to see additional testing, please let me know. I don't see any need to add this into a testcase (I think it would be difficult to trigger). Thanks, David > Thank you, > Rachel From david.holmes at oracle.com Tue Mar 15 00:29:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 10:29:10 +1000 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <56E6BDF2.2010201@oracle.com> References: <56E65E62.8040003@oracle.com> <56E6BDF2.2010201@oracle.com> Message-ID: <56E75756.8060200@oracle.com> Thanks Robbin. Can I have a Reviewer too please. David On 14/03/2016 11:34 PM, Robbin Ehn wrote: > Hi David, > > On 03/14/2016 07:46 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 >> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ > > This looks good to me. > > /Robbin > >> >> This isn't a fix per-se but some additional diagnostic code to try and >> detect the conditions where the bug might manifest. The basic failure >> mode was: >> >> # Internal Error >> (/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950), >> >> pid=27906, tid=13248 >> # assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: >> Must be VMThread or JavaThread >> >> with a stack showing in part: >> >> #34 0xf6623ec0 in report_vm_error ( >> file=0xf71b6140 >> "/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp", >> >> line=3901, >> error_msg=0xf71b62e0 "assert(thread->is_VM_thread() || >> thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be >> VMThread or JavaThread") >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218 >> >> >> #35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc, >> context=0xc1b58d4c) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901 >> >> >> #36 >> #37 0xf776b430 in __kernel_vsyscall () >> #38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0 >> #39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879 >> >> >> #40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg=> out>) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367 >> >> >> #41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800, >> __in_chrg=) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611 >> >> >> #42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800, >> __in_chrg=) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655 >> >> >> #43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724 >> >> >> #44 0xf6f74e12 in JavaThread::run (this=0xc20cd800) >> at >> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698 >> >> >> #45 0xf6d238ec in java_start (thread=0xc20cd800) >> >> What appears to be happening is that the thread has blocked SR_signum >> (SIGUSR2) at some point (though there is no code that does this), and >> the signal has become pending on the thread due to the event sampling >> logic. The thread terminates, executing well into the destructor until >> it gets to os::free_thread which restores the original signal mask for >> the thread - that signal mask has SR_signum unblocked and so the signal >> is delivered immediately and we enter the SR_handler. For some reason >> this triggers the assertion failure - though why exactly is unclear as >> we have not released the thread memory as yet, nor done anything that >> should invalidate that call. Whatever the reason the state of the thread >> causes secondary failures in the error reporting code as well. >> >> Attempts to reproduce this bug have been unsuccessful (so maybe we had a >> random memory stomp on the thread state - who knows.) >> >> So what I am doing is simply adding an additional assertion to try and >> catch, during regular testing, any occurrence of SR_signum being >> blocked while a thread is terminating. >> >> In addition a couple of minor cleanups in the signal related code: >> - strictly speaking SR_handler needs to use >> Thread::current_or_null_safe() because it needs ot use library-based TLS >> in a signal context. >> - sigsets should (POSIX recommendation) be explicitly emptied/filled >> before being set via pthread_sigmask >> - change 0 to NULL in call to pthread_sigmask >> >> Testing: - JPRT, original failing testcase >> >> Thanks, >> David From coleen.phillimore at oracle.com Tue Mar 15 01:35:01 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 14 Mar 2016 21:35:01 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E701AB.6060705@oracle.com> References: <56E701AB.6060705@oracle.com> Message-ID: <56E766C5.3040204@oracle.com> http://cr.openjdk.java.net/~rprotacio/8150085.02/src/share/vm/utilities/exceptions.cpp.udiff.html It looks like this could be one if statement rather than two, and checking _pending_exception != NULL is faster than testing log_is_enabled(). If you make this change, I don't need to see another webrev. thanks, Coleen On 3/14/16 2:23 PM, Rachel Protacio wrote: > Hi, > > Please review this change, converting -XX:+TraceClearedExceptions to > -Xlog:exceptions=debug. (This change replaces the one I sent out > earlier that was going to delete the option.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ > > Passes JPRT; if you'd like to see additional testing, please let me know. > > Thank you, > Rachel From david.holmes at oracle.com Tue Mar 15 06:24:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 16:24:58 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris Message-ID: <56E7AABA.4000707@oracle.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8151322 Webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev/ As of Solaris 11.3 pthread_set_name_np has been implemented: http://docs.oracle.com/cd/E53394_01/html/E54766/pthread-setname-np-3c.html#scrolltoc https://blogs.oracle.com/observatory/entry/named_threads So we can now implement os::set_native_thread_name using dynamic lookup as done on Linux. The only difference is we have 31 characters to play with instead of 16. Testing: - JPRT (only 11.2 systems) - Manually on 11.3 - see examples in bug report Thanks, David From kim.barrett at oracle.com Tue Mar 15 06:34:16 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Mar 2016 02:34:16 -0400 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <56E65E62.8040003@oracle.com> References: <56E65E62.8040003@oracle.com> Message-ID: <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com> > On Mar 14, 2016, at 2:46 AM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 > Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ > > This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was: Changes look good. Good cleanup with the sigemptyset calls. Pedantic is a good thing when dealing with POSIX. Since this isn?t an actual fix, should the change be associated with a different bug number? Or are you treating this as the moral equivalent of resolving as not reproducible? From david.holmes at oracle.com Tue Mar 15 06:43:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 16:43:01 +1000 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com> References: <56E65E62.8040003@oracle.com> <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com> Message-ID: <56E7AEF5.3070507@oracle.com> Hi Kim, On 15/03/2016 4:34 PM, Kim Barrett wrote: >> On Mar 14, 2016, at 2:46 AM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 >> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ >> >> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was: > > Changes look good. > > Good cleanup with the sigemptyset calls. Pedantic is a good thing when dealing with POSIX. Thanks for the Review. > Since this isn?t an actual fix, should the change be associated with a different bug number? > Or are you treating this as the moral equivalent of resolving as not reproducible? I toyed with creating a subtask for this change and leaving the original open, but realistically I think it may turn out to be "not reproducible". I can be swayed if you think a new subtask would be better? Thanks, David From kim.barrett at oracle.com Tue Mar 15 06:48:52 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Mar 2016 02:48:52 -0400 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <56E7AEF5.3070507@oracle.com> References: <56E65E62.8040003@oracle.com> <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com> <56E7AEF5.3070507@oracle.com> Message-ID: <92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com> > On Mar 15, 2016, at 2:43 AM, David Holmes wrote: > > Hi Kim, > > On 15/03/2016 4:34 PM, Kim Barrett wrote: >>> On Mar 14, 2016, at 2:46 AM, David Holmes wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ >>> >>> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was: >> >> Changes look good. >> >> Good cleanup with the sigemptyset calls. Pedantic is a good thing when dealing with POSIX. > > Thanks for the Review. > >> Since this isn?t an actual fix, should the change be associated with a different bug number? >> Or are you treating this as the moral equivalent of resolving as not reproducible? > > I toyed with creating a subtask for this change and leaving the original open, but realistically I think it may turn out to be "not reproducible". I can be swayed if you think a new subtask would be better? Just making sure I understood your intent. It doesn?t look like there?s so much information in this one that creating a new one with a reference would be a big problem if it ever shows up again. Go ahead as is. From david.holmes at oracle.com Tue Mar 15 07:07:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 17:07:06 +1000 Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not VMThread or JavaThread In-Reply-To: <92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com> References: <56E65E62.8040003@oracle.com> <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com> <56E7AEF5.3070507@oracle.com> <92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com> Message-ID: <56E7B49A.5000304@oracle.com> Thanks Kim - pushing now. In a way this does "fix" the original problem as we should no longer get to that particular assert :) Robbin: you don't have an OpenJDK user name yet! So I couldn't give you reviewing credit. :( David ----- On 15/03/2016 4:48 PM, Kim Barrett wrote: >> On Mar 15, 2016, at 2:43 AM, David Holmes wrote: >> >> Hi Kim, >> >> On 15/03/2016 4:34 PM, Kim Barrett wrote: >>>> On Mar 14, 2016, at 2:46 AM, David Holmes wrote: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165 >>>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/ >>>> >>>> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was: >>> >>> Changes look good. >>> >>> Good cleanup with the sigemptyset calls. Pedantic is a good thing when dealing with POSIX. >> >> Thanks for the Review. >> >>> Since this isn?t an actual fix, should the change be associated with a different bug number? >>> Or are you treating this as the moral equivalent of resolving as not reproducible? >> >> I toyed with creating a subtask for this change and leaving the original open, but realistically I think it may turn out to be "not reproducible". I can be swayed if you think a new subtask would be better? > > Just making sure I understood your intent. It doesn?t look like there?s so much information in this one that creating a new one with a reference would be a big problem if it ever shows up again. Go ahead as is. > > From marcus.larsson at oracle.com Tue Mar 15 09:17:33 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Mar 2016 10:17:33 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E6D385.4000708@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com> <56E54911.9090807@oracle.com> <56E692A4.6010204@oracle.com> <56E6D385.4000708@oracle.com> Message-ID: <56E7D32D.1010408@oracle.com> On 03/14/2016 04:06 PM, Dmitry Samersoff wrote: > Marcus, > > 1. > Most of log analyzing tools utilize the fact that filesystem returns > files in alphabetical order or uses scandir()/alphasort() > > So good log rotation strategy is log, log.001, log.002, log.003 etc > where "log" is current one and log.MAX_COUNT is the oldest one. The current log rotation scheme keeps the current log file as just "log", and when rotating it will move this log to "log.X", where X is initially 1 and increases at each rotation. It will simply overwrite the file if it already exists. When X reaches the file-count, it wraps around and starts over from 1 again. There's no guarantee that the highest number is the oldest/youngest file. This patch doesn't change the rotation scheme, it only makes rotation the default, with the addition of a smarter choice of initial X value, namely either the next unused X or the oldest X based on mtime if all X:es are in use. It's a best-effort to prevent accidental overwriting of your logs, but it doesn't guarantee anything. > > To save startup time we can declare that log.001 is the oldest one, and > log.MAX_COUNT is the newest one but log.002 that is more recent than > log.001 and log.003 seems not obvious to me. This is a different rotation scheme and would require rotating every log file at each rotation in order to keep the invariant. I'm not against changing the current scheme, but I think it's outside the scope of this change and would prefer to do it separately in that case. > > Also it's very common that log producer and log analyzer resides on a > different machines (e.g. with NFS share) and log file mtime could be > unrelated to the age of VM events in this log. So we shouldn't use log > mtime for any decision. The mtime is just our best guess in the case we don't know which file to delete. > > 2. > rename() can cause a burden in complicated environment, so it's better > to check most common cases (permissions, PATH_MAX, etc) explicitly, as > early as possible, to give meaningful error message to a user. I see. I wanted to avoid the complexity, but if you feel it is important I'll add some checks for these things. > > See also below. > > On 2016-03-14 13:29, Marcus Larsson wrote: >> Hi, >> >> Thanks for looking at this! >> >> On 03/13/2016 12:03 PM, Dmitry Samersoff wrote: >>> Marcus, >>> >>> 1. os_posix/os_windows.cpp >>> >>> Windows version is expensive and change access time of a log file. >>> >>> So it's better to create os::get_mtime() that uses stat() for both, >>> windows and posix and LogFileOutput::calc_mtime_diff(). >>> >>> Also it saves a bit of compiler power unrolling loop. >> This is similar to my first approach but I ran into problems with it >> because st_mtime is a struct timespec on posix and a time_t on windows. >> From the start I wanted better precision than seconds, which is why I >> wanted to use CompareFileTime(). Given that we can not depend on any >> particular precision, perhaps it's better to just use stat() on windows >> as well, like you say. > OK. > >>> 2. log.cpp >>> >>> size_t number_of_lines_with_substring_in_file() >>> >>> When you plan to use it ? Current implementation is rather expensive, >>> but if you plan to run it manually only, I'm OK with it. >> It's used for testing only. > If you plan to use it in jprt or nightly - please change it. It's part of the internal vm tests, so it should be in both. I don't see the problem though. It's used once to verify a very small log file. The test completes in a matter of milliseconds, and I don't think we should worry about it. > >>> 3. logFileOutput.cpp >>> >>> 82. >>> Please, change file_exists to can_be_rotated() and check that log output >>> is a *regular file* and you have a write access to it. >> I guess it would be useful to give an error in the case someone >> specifies logging to something that's not a regular file. Checking for >> write permissions shouldn't be necessary here though. If any of the >> required operations fail because of lacking permissions we'll notice >> that at that time. > Logging to /dev/tape or /dev/console is perfectly valid usecase but we > should detect it and don't attempt to rotate or truncate device ever if > sysadmin enable rotation by mistake. > > Also common sysadmin mistake is a log pointing to directory or presence > of log.NNN directory - we should detect it as well. > > One more case when we shouldn't rotate - log is symlink > > >>> 87. >>> Please, don't use floating point math. Just allocate 10 extra bytes, it >>> fit all possible file length value. >> I can use a fixed size for the allocations, but we will still want to >> figure out how many numbers should be used so that we can use the >> appropriate amount of padding. Logging with 10 files in rotation should >> use log.0 to log.9, not log.0000000 to log.0000009. > It's OK to always write log.001 etc or use something like: > > return (num < 10) ? 1 : (num < 100) ? 2 : 5; Ok. > >>> 93. >>> if we have log.01, log.03 etc this function creates log.02 instead of >>> log.04. >> Yes, that's intentional. > log.01 and log.03 both containing older data than log.02 seems not > obvious for me. > > Could we always use largest possible number? Like I said, this is the current rotation scheme, and I would prefer to not change it with this patch. Thanks, Marcus > >>> Sorry! I'm not follow logic of ll.118 >>> What happens if some log parsing tool change log file mtime? >> We'll always prefer to overwrite the file that hasn't been modified for >> the longest time. > Log file mtime can be unrelated to the age of VM events in this file > (think sysadmin do: vi log.003, :wq) so we shouldn't rely on mtime. > >>> Please, limit the number of old logs (FileCountOption) to some >>> reasonable value (e.g. 999) and use binary search to find the name of a >>> next file. >> I can limit it, but I'm not sure we should make the effort of binary >> searching for the file name. It's a one time search during startup and I >> would expect most people to use around 10 files. > OK, as soon as DefaultRotationFileCount is less than 10 > >>> Also please check full log file name against MAX_PATH constant. >> Is it really necessary? Won't fopen() just fail and return the >> appropriate error for this? > rename errors is not always obvious. see comments above. > > -Dmitry > >> Thanks, >> Marcus >> >>> -Dmitry >>> >>> >>> >>> >>> On 2016-03-11 17:39, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 2016-03-11 15:35, Bengt Rutisson wrote: >>>>> Hi Marcus, >>>>> >>>>> On 2016-03-11 15:21, Marcus Larsson wrote: >>>>>> Third time's the charm. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>>>> I had a quick look at the code changes. It is not really my area of >>>>> the code, so I'll leave to someone else to formally review it. >>>>> >>>>> However, I downloaded the patch a played a bit with the logging. This >>>>> is much more like the way I would like it! Thanks! >>>>> >>>>> So, from a functional perspective this looks good to me. >>>>> >>>> Thanks for the feedback! >>>> >>>> Marcus >>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> This patch makes log file rotation the default. Default thresholds >>>>>> are 5 rotated files with a target size of 20MiB. Truncating behavior >>>>>> can be achieved by setting filecount to 0 >>>>>> (-Xlog::myfile.log::filecount=0). >>>>>> >>>>>> If a log file already exists during log file initialization it will >>>>>> be rotated. If any of the target file names (file.0 to file.4 in the >>>>>> default case) are available, that filename will be used for the >>>>>> existing log. If all names are taken the VM will attempt to overwrite >>>>>> the oldest file. >>>>>> >>>>>> This should prevent unlimited log file creations and avoid accidental >>>>>> loss of log files from previous runs. The default thresholds (5 >>>>>> files, 20MiB each) is just a suggestion. If you think it should be >>>>>> higher/lower let me know. >>>>>> >>>>>> Tested with included internal VM tests through RBT. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> After some offline discussions I'm withdrawing this patch. I will >>>>>>> instead investigate if I can achieve similar behavior using log >>>>>>> rotation as the default. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Taking a different approach to this. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>>>>> >>>>>>>> Existing files will now by default be renamed/archived with a .X >>>>>>>> suffix where X is the lowest number such that the resulting file >>>>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>>>>>> controlling this behavior has been added as well. It can be set to >>>>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>>>>> >>>>>>>> Tested with included jtreg test through JPRT. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the following patch to make sure UL truncates >>>>>>>>> existing log files before writing to them. Since files are opened >>>>>>>>> in append mode, truncation isn't done automatically, so instead >>>>>>>>> the patch adds an attempt to remove the log file before opening it. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>>>>> >>>>>>>>> Issue: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Included test through JPRT >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus > From thomas.stuefe at gmail.com Tue Mar 15 10:07:59 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Mar 2016 11:07:59 +0100 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56E63348.2010607@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> Message-ID: Hi David, sorry, I will have not the time to work on this this week. If the patch is acceptable to you in this form, I'd say we commit it, otherwise I'll take it up again some time later. About the suggested changes: - Merging both APIs into one, like suggested, is fine for me and I would do this in a follow-up. - Handling unknown errno values: I do not like the idea of a fallback to ::strerror(). Writing the API comment on that one would be weird: "Is almost threadsafe", "will probably return a static constant string"... :) I would suggest either using the solution as it is now - only honouring POSIX errno values or returning "Unknown", or to expand them with OS specific lists, either in the OS independent form ("#ifdef EBLUB handle(EBLUB) #endif") or by expanding os::strerror() with platform dependend os::strerror_pd(). I am pretty unemotional about either option but would prefer avoiding ::strerror() altogether. Kind Regards, Thomas On Mon, Mar 14, 2016 at 4:43 AM, David Holmes wrote: > On 12/03/2016 6:22 PM, Thomas St?fe wrote: > >> Hi David, >> >> thanks again for your review. Here the new version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ >> >> And the diff to the last version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt >> >> I fixed the indention, copyright comments and the typo. >> > > All looks good - thanks. > > Further comments inline. >> > > Ditto :) > > >> On Fri, Mar 11, 2016 at 8:04 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> Thanks for persevering with this. Sorry for the delayed response. >> >> On 10/03/2016 2:58 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please take a look at this next version of the fix. >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ >> >> I am the first to admit that this is quite ugly :(, but it is a >> pragmatic solution. >> >> Some details: >> >> - I added os::strerror() as a drop-in replacement for >> ::strerror() - it >> returns the text as before, but does not localize and does not >> handle >> unknown error values; so it can be implemented using a simple >> static >> string table and is always safe to use. >> >> >> Ok. But I don't think we need os::lasterror() if we have this. A >> follow up clean-up is okay for that though. >> >> >> I would love to keep this functionality, because I like printing out the >> short concise errno values, and there are a number of logging changes >> coming at least for AIX. It also does not cost much, as the large string >> table is already there. >> >> If the second API does not suit you, would it be accepable for you if I >> hide this functionality behind a second parameter in strerror, >> defaulting to false, like I did in my first version? E.g. >> os::strerror(int e, bool short_name=false); ? >> > > That was what I was thinking of yes. :) > > But talking about clean-up, could we get rid of os::lasterror() ? I >> think that function is a bad idea, and it fortunately is only called in >> two places, both just need strerror() and no Win32 error handling anyway. >> > > Sounds good. lasterror() is a fragile API as it is too easy to introduce > unexpected system calls between the call to lasterror and the action you > want to check for the error. > > I also would like to remove os::get_last_error(). It returns errno on >> *nix, win32 error on Windows. Both are different things, plus there is >> also an errno on Windows The return value of this function is useless >> without knowing what the returned error number actually is, so it is not >> of much use. >> > > Simplifying and streamlining all this sounds good. > > Also it does seem to handle unknown error values. >> >> - I added os::errno_name() for those cases where one would want >> the >> literalized errno value (e.g. "EINVAL") instead of the full text. >> >> >> Ok. For the unknown case can it return the numeric value that it was >> passed? >> >> >> I would like to avoid this. This would make the function more complicated. >> >> I'd need to keep this thread-safe, so I either would have to allocate >> thread local storage for the return string somehow or, alternatively, >> keep a fixed string table a la [][] {"unknown (0)", "unknown(1)"} for >> the first n values or so. >> > > Okay. I was thinking this would be simpler but of course we have to > convert to a string. > > I note that linux defines ~133 errno values, and you have entries for ~75 > - are they all the POSIX ones? > > I'm wondering whether we should have a fallback strategy for an unknown > (platform-specific) error by using the platform strerror even though not > thread-safe (the window of exposure is vastly reduced) ? > > Also, ::strerror() behaves not consistently for the EINVAL case on all >> platforms anyway - on Linux and Bsd, it returns the numerical value, but >> on Solaris, Windows and AIX, it just returns "Unknown". Many callsites I >> saw take this already into account and print out the numerical errno >> value in addition to the error string. >> > > I doubt those callsites are not taking into account unknown values - I > think you will find they originally only reported the numerical value and > were then augmented to also print the strerror message. > > Thanks, > David > > - I fixed all callsites in the hotspot which used ::strerror to use >> os::strerror, or, in some few cases (mostly my own coding for >> AIX), >> os::errno_name(). >> >> >> Bit subjective but okay - I personally don't care either way. :) >> >> - To avoid including os.hpp in debug.hpp, I moved the >> implemntation of >> assert_status to debug.cpp >> >> >> Okay ... did the include cause a problem? >> >> >> os.hpp is a large beast. I wanted to keep it out of debug.hpp, to not >> force this include upon anyone who includes debug.hpp just to get >> assert(). I also try to avoid calling system apis in header files. >> >> >> >> General minor comments: >> >> src/os/posix/vm/os_posix.cpp >> >> Indentation of wrapped call needs fixing >> >> >> Fixed >> >> --- >> >> src/share/vm/runtime/os.hpp >> >> Typo: >> >> + // sugested in the POSIX standard. >> >> -> suggested >> >> >> Fixed >> >> --- >> >> src/share/vm/utilities/vmError.cpp >> >> Good catch on the code that potentially reports the wrong error >> using get_last_error! Even the simple print_cr(..., strerror(errno), >> errno) could in fact print non-matching values if strerror itself >> caused an error (unlikely of course :) ). >> >> >> Thanks :) >> >> >> Please check all copyright years - attachListener_solaris.cpp was >> updated to 2015 instead of 2016 :) Also note correct format for two >> year copyrights - in src/share/vm/logging/logFileOutput.cpp you have: >> >> Copyright (c) 2015,2016 Oracle >> >> but it should be: >> >> Copyright (c) 2015, 2016, Oracle >> >> Fixed >> >> Thanks, >> David >> >> >> Thanks! >> >> Thomas >> >> >> Kind Regards, Thomas >> >> >> >> >> On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore >> > >> > >> >> wrote: >> >> >> This latest version seems okay (or at least better than the >> other >> workarounds). >> >> thanks, >> Coleen >> >> >> On 3/1/16 12:30 AM, David Holmes wrote: >> >> Hi Thomas, >> >> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> >> Hi David, >> >> On Mon, Feb 29, 2016 at 4:44 AM, David Holmes >> > > > >> > >> >> > >>> wrote: >> >> Hi Thomas, >> >> On 27/02/2016 2:05 AM, Thomas St?fe wrote: >> >> Hi, >> >> please take a look at this proposed fix: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8148425 >> Webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >> >> This adds a replacement function >> os::strerror() as >> a drop-in for >> strerror(), which has a number of issues. >> >> strerror() is unsafe to use and may cause >> (and has >> caused) >> crashes in >> multithreaded scenarios. It is also not >> ideal for >> log files >> because of the >> implicit localization of the error messages. >> >> For details please see the discussion >> under the bug >> report. >> >> >> I just came across strerror_l, which is >> required to be >> thread-safe. >> Is that a possible alternative? (I'm not sure >> how >> locale's are >> obtained). >> >> >> Sorry, I think this API is glibc only. At least I >> cannot >> find this in >> our AIX headers, nor on Solaris. >> >> >> It is a POSIX API: >> >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >> >> added in 2006 but part of POSIX.1-2008. But as per >> Dalibor's >> link not necessarily available: >> >> "This function is missing on some platforms: glibc >> 2.3.6, Mac OS >> X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix >> 3.1.8, AIX >> 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2011-11, >> Cygwin, >> mingw, MSVC 9, Interix 3.5, BeOS. " >> >> Pity. >> >> >> Otherwise what you have seems okay - though I do >> dislike having to >> duplicate all that details already buried in >> the system >> headers/library. Not sure we need to the long >> text at >> the VM level - >> which would simplify things a bit. >> >> >> I agree, I dislike this too. Like everyone else in >> this >> thread. But I >> think this is a pragmatic solution. >> >> I am a bit stuck here - should we really get rid of >> the long >> text >> feature? There are some callsites of strerror() in >> the >> hotspot where >> arguably the long text is better suited: >> - in assert_status() (see debug.hpp) - this ends up >> in the >> header of >> error files, if this suddenly changes to a >> literalized >> errno, people may >> be upset >> >> >> I added assert_status purely to expand on what the >> failing >> status was :) I'm happy to see EINVAL in that context >> rather >> than "invalid argument" (or whatever) :) >> >> - when failing to write a heap dump file - see >> services/heapDumper.cpp. >> Which ends as printout on the command line, I think. >> >> >> Maybe ... if it is an error the user can fix. >> >> The safe option would be to provide both variants >> (short and >> long text). >> Or, provide the safe, short variant for all logging >> calls - when >> "EINVAL" is enough, and let users continue to use >> strerror() >> for those >> few cases where the long text is needed. >> >> What do you think? >> >> >> Trying to decide what makes me least unhappy. :) Given >> you've >> already done the work I guess having long and short >> forms is okay. >> >> Thanks, >> David >> >> Thanks, Thomas >> >> Thanks, >> David >> >> >> Please note that I did not yet change any >> call >> sites, although >> all call >> sites in the os namespace should already >> use the >> new function. I >> wanted to >> see whether there would be any general >> objections. >> >> Kind Regards, Thomas >> >> >> >> >> >> From staffan.larsen at oracle.com Tue Mar 15 10:16:04 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Mar 2016 11:16:04 +0100 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E7AABA.4000707@oracle.com> References: <56E7AABA.4000707@oracle.com> Message-ID: <3F101AFF-E9C4-4969-BADE-3020F8EB10A8@oracle.com> Why do you assign the result to an unused variable: L452: const int rc = Solaris::_pthread_setname_np(pthread_self(), but); Otherwise: Looks good! Thanks, /Staffan > On 15 mars 2016, at 07:24, David Holmes wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8151322 > > Webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev/ > > As of Solaris 11.3 pthread_set_name_np has been implemented: > > http://docs.oracle.com/cd/E53394_01/html/E54766/pthread-setname-np-3c.html#scrolltoc > > https://blogs.oracle.com/observatory/entry/named_threads > > So we can now implement os::set_native_thread_name using dynamic lookup as done on Linux. The only difference is we have 31 characters to play with instead of 16. > > Testing: - JPRT (only 11.2 systems) > - Manually on 11.3 - see examples in bug report > > Thanks, > David From david.holmes at oracle.com Tue Mar 15 10:35:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 20:35:09 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <3F101AFF-E9C4-4969-BADE-3020F8EB10A8@oracle.com> References: <56E7AABA.4000707@oracle.com> <3F101AFF-E9C4-4969-BADE-3020F8EB10A8@oracle.com> Message-ID: <56E7E55D.8@oracle.com> On 15/03/2016 8:16 PM, Staffan Larsen wrote: > Why do you assign the result to an unused variable: > > L452: const int rc = Solaris::_pthread_setname_np(pthread_self(), but); Oops! - the linux version has a following assert that uses it - but I'll remove it from this version. > Otherwise: Looks good! Thanks for the review Staffan! David > Thanks, > /Staffan > >> On 15 mars 2016, at 07:24, David Holmes wrote: >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8151322 >> >> Webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev/ >> >> As of Solaris 11.3 pthread_set_name_np has been implemented: >> >> http://docs.oracle.com/cd/E53394_01/html/E54766/pthread-setname-np-3c.html#scrolltoc >> >> https://blogs.oracle.com/observatory/entry/named_threads >> >> So we can now implement os::set_native_thread_name using dynamic lookup as done on Linux. The only difference is we have 31 characters to play with instead of 16. >> >> Testing: - JPRT (only 11.2 systems) >> - Manually on 11.3 - see examples in bug report >> >> Thanks, >> David > From david.holmes at oracle.com Tue Mar 15 12:31:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Mar 2016 22:31:23 +1000 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> Message-ID: <56E8009B.7070009@oracle.com> Hi Thomas, On 15/03/2016 8:07 PM, Thomas St?fe wrote: > Hi David, > > sorry, I will have not the time to work on this this week. If the patch > is acceptable to you in this form, I'd say we commit it, otherwise I'll > take it up again some time later. If Coleen is okay with this as-is I'll commit it in the morning. > About the suggested changes: > > - Merging both APIs into one, like suggested, is fine for me and I would > do this in a follow-up. Sure. > - Handling unknown errno values: I do not like the idea of a fallback to > ::strerror(). Writing the API comment on that one would be weird: "Is > almost threadsafe", "will probably return a static constant string"... > :) I would suggest either using the solution as it is now - only > honouring POSIX errno values or returning "Unknown", or to expand them > with OS specific lists, either in the OS independent form ("#ifdef EBLUB > handle(EBLUB) #endif") or by expanding os::strerror() with platform > dependend os::strerror_pd(). > > I am pretty unemotional about either option but would prefer avoiding > ::strerror() altogether. A follow up on this okay. I'm unsure how best to handle it. Given how rarely we encounter errors I'm probably over-thinking it. ;) Thanks, David > Kind Regards, Thomas > > > > On Mon, Mar 14, 2016 at 4:43 AM, David Holmes > wrote: > > On 12/03/2016 6:22 PM, Thomas St?fe wrote: > > Hi David, > > thanks again for your review. Here the new version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ > > And the diff to the last version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt > > I fixed the indention, copyright comments and the typo. > > > All looks good - thanks. > > Further comments inline. > > > Ditto :) > > > On Fri, Mar 11, 2016 at 8:04 AM, David Holmes > > >> wrote: > > Hi Thomas, > > Thanks for persevering with this. Sorry for the delayed > response. > > On 10/03/2016 2:58 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at this next version of the fix. > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ > > I am the first to admit that this is quite ugly :(, but > it is a > pragmatic solution. > > Some details: > > - I added os::strerror() as a drop-in replacement for > ::strerror() - it > returns the text as before, but does not localize and > does not > handle > unknown error values; so it can be implemented using a > simple static > string table and is always safe to use. > > > Ok. But I don't think we need os::lasterror() if we have > this. A > follow up clean-up is okay for that though. > > > I would love to keep this functionality, because I like printing > out the > short concise errno values, and there are a number of logging > changes > coming at least for AIX. It also does not cost much, as the > large string > table is already there. > > If the second API does not suit you, would it be accepable for > you if I > hide this functionality behind a second parameter in strerror, > defaulting to false, like I did in my first version? E.g. > os::strerror(int e, bool short_name=false); ? > > > That was what I was thinking of yes. :) > > But talking about clean-up, could we get rid of os::lasterror() ? I > think that function is a bad idea, and it fortunately is only > called in > two places, both just need strerror() and no Win32 error > handling anyway. > > > Sounds good. lasterror() is a fragile API as it is too easy to > introduce unexpected system calls between the call to lasterror and > the action you want to check for the error. > > I also would like to remove os::get_last_error(). It returns > errno on > *nix, win32 error on Windows. Both are different things, plus > there is > also an errno on Windows The return value of this function is > useless > without knowing what the returned error number actually is, so > it is not > of much use. > > > Simplifying and streamlining all this sounds good. > > Also it does seem to handle unknown error values. > > - I added os::errno_name() for those cases where one > would want the > literalized errno value (e.g. "EINVAL") instead of the > full text. > > > Ok. For the unknown case can it return the numeric value > that it was > passed? > > > I would like to avoid this. This would make the function more > complicated. > > I'd need to keep this thread-safe, so I either would have to > allocate > thread local storage for the return string somehow or, > alternatively, > keep a fixed string table a la [][] {"unknown (0)", > "unknown(1)"} for > the first n values or so. > > > Okay. I was thinking this would be simpler but of course we have to > convert to a string. > > I note that linux defines ~133 errno values, and you have entries > for ~75 - are they all the POSIX ones? > > I'm wondering whether we should have a fallback strategy for an > unknown (platform-specific) error by using the platform strerror > even though not thread-safe (the window of exposure is vastly reduced) ? > > Also, ::strerror() behaves not consistently for the EINVAL case > on all > platforms anyway - on Linux and Bsd, it returns the numerical > value, but > on Solaris, Windows and AIX, it just returns "Unknown". Many > callsites I > saw take this already into account and print out the numerical errno > value in addition to the error string. > > > I doubt those callsites are not taking into account unknown values - > I think you will find they originally only reported the numerical > value and were then augmented to also print the strerror message. > > Thanks, > David > > - I fixed all callsites in the hotspot which used > ::strerror to use > os::strerror, or, in some few cases (mostly my own > coding for AIX), > os::errno_name(). > > > Bit subjective but okay - I personally don't care either > way. :) > > - To avoid including os.hpp in debug.hpp, I moved the > implemntation of > assert_status to debug.cpp > > > Okay ... did the include cause a problem? > > > os.hpp is a large beast. I wanted to keep it out of debug.hpp, > to not > force this include upon anyone who includes debug.hpp just to get > assert(). I also try to avoid calling system apis in header files. > > > > General minor comments: > > src/os/posix/vm/os_posix.cpp > > Indentation of wrapped call needs fixing > > > Fixed > > --- > > src/share/vm/runtime/os.hpp > > Typo: > > + // sugested in the POSIX standard. > > -> suggested > > > Fixed > > --- > > src/share/vm/utilities/vmError.cpp > > Good catch on the code that potentially reports the wrong error > using get_last_error! Even the simple print_cr(..., > strerror(errno), > errno) could in fact print non-matching values if strerror > itself > caused an error (unlikely of course :) ). > > > Thanks :) > > > Please check all copyright years - > attachListener_solaris.cpp was > updated to 2015 instead of 2016 :) Also note correct format > for two > year copyrights - in src/share/vm/logging/logFileOutput.cpp > you have: > > Copyright (c) 2015,2016 Oracle > > but it should be: > > Copyright (c) 2015, 2016, Oracle > > Fixed > > Thanks, > David > > > Thanks! > > Thomas > > > Kind Regards, Thomas > > > > > On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore > > > > > > >>> wrote: > > > This latest version seems okay (or at least better > than the > other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas St?fe wrote: > > Hi David, > > On Mon, Feb 29, 2016 at 4:44 AM, David Holmes > > > > > >> > > > > > > >>>> wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, Thomas St?fe > wrote: > > Hi, > > please take a look at this > proposed fix: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > This adds a replacement function > os::strerror() as > a drop-in for > strerror(), which has a number of > issues. > > strerror() is unsafe to use and > may cause > (and has > caused) > crashes in > multithreaded scenarios. It is > also not > ideal for > log files > because of the > implicit localization of the > error messages. > > For details please see the discussion > under the bug > report. > > > I just came across strerror_l, which is > required to be > thread-safe. > Is that a possible alternative? (I'm > not sure how > locale's are > obtained). > > > Sorry, I think this API is glibc only. At > least I > cannot > find this in > our AIX headers, nor on Solaris. > > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of POSIX.1-2008. But as per > Dalibor's > link not necessarily available: > > "This function is missing on some platforms: glibc > 2.3.6, Mac OS > X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, > Minix > 3.1.8, AIX > 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 > 2011-11, > Cygwin, > mingw, MSVC 9, Interix 3.5, BeOS. " > > Pity. > > > Otherwise what you have seems okay - > though I do > dislike having to > duplicate all that details already > buried in > the system > headers/library. Not sure we need to > the long > text at > the VM level - > which would simplify things a bit. > > > I agree, I dislike this too. Like everyone > else in this > thread. But I > think this is a pragmatic solution. > > I am a bit stuck here - should we really > get rid of > the long > text > feature? There are some callsites of > strerror() in the > hotspot where > arguably the long text is better suited: > - in assert_status() (see debug.hpp) - > this ends up > in the > header of > error files, if this suddenly changes to a > literalized > errno, people may > be upset > > > I added assert_status purely to expand on what > the failing > status was :) I'm happy to see EINVAL in that > context > rather > than "invalid argument" (or whatever) :) > > - when failing to write a heap dump file - see > services/heapDumper.cpp. > Which ends as printout on the command > line, I think. > > > Maybe ... if it is an error the user can fix. > > The safe option would be to provide both > variants > (short and > long text). > Or, provide the safe, short variant for > all logging > calls - when > "EINVAL" is enough, and let users continue > to use > strerror() > for those > few cases where the long text is needed. > > What do you think? > > > Trying to decide what makes me least unhappy. > :) Given > you've > already done the work I guess having long and > short > forms is okay. > > Thanks, > David > > Thanks, Thomas > > Thanks, > David > > > Please note that I did not yet > change any call > sites, although > all call > sites in the os namespace should > already > use the > new function. I > wanted to > see whether there would be any > general > objections. > > Kind Regards, Thomas > > > > > > From max.ockner at oracle.com Tue Mar 15 12:46:26 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 15 Mar 2016 08:46:26 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E70969.3070007@oracle.com> References: <56E701AB.6060705@oracle.com> <56E7077D.4090205@oracle.com> <56E70969.3070007@oracle.com> Message-ID: <56E80422.4020005@oracle.com> Looks good to me. Max On 3/14/2016 2:56 PM, Rachel Protacio wrote: > Hi, > > Sorry for the confusion. I have previously converted TraceExceptions > to Xlog:exceptions=info, so this change is merely adding the statement > that was previously with TraceClearedExceptions into the "exceptions" > tag, under the debug level. logging/ExceptionsTest.java tests the > exceptions tag as a whole, and I did not add to it since this portion > of code did not seem simple to trigger for the sake of a logging test. > But of course I'm happy to add a case if someone has a specific avenue > in mind. > > Rachel > > On 3/14/2016 2:48 PM, Max Ockner wrote: >> Rachel, >> I'm a bit confused to only see two files changed here. Did you leave >> some files out? Did you add the tag to logTag.hpp in another fix? Is >> there a test? >> Thanks, >> Max >> >> On 3/14/2016 2:23 PM, Rachel Protacio wrote: >>> Hi, >>> >>> Please review this change, converting -XX:+TraceClearedExceptions to >>> -Xlog:exceptions=debug. (This change replaces the one I sent out >>> earlier that was going to delete the option.) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ >>> >>> Passes JPRT; if you'd like to see additional testing, please let me >>> know. >>> >>> Thank you, >>> Rachel >> > From fairoz.matte at oracle.com Tue Mar 15 13:37:40 2016 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Tue, 15 Mar 2016 06:37:40 -0700 (PDT) Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E705C9.2010605@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> Message-ID: <7b553bec-baa7-447d-8b99-98980f910274@default> Hi Jon, David, Sangheon, Kim and Thomas, Thanks for your review comments. Patch is modified to incorporate the changes @@ -1675,9 +1675,8 @@ FLAG_SET_DEFAULT(ParallelGCThreads, Abstract_VM_Version::parallel_worker_threads()); if (ParallelGCThreads == 0) { - FLAG_SET_DEFAULT(ParallelGCThreads, - Abstract_VM_Version::parallel_worker_threads()); - } + vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); + } Find below is the details Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ Thanks, Fairoz > -----Original Message----- > From: Jon Masamitsu > Sent: Tuesday, March 15, 2016 12:11 AM > To: David Holmes; sangheon; Kim Barrett > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8150518: G1 GC crashes at > G1CollectedHeap::do_collection_pause_at_safepoint(double) > > > > On 03/13/2016 11:51 PM, David Holmes wrote: > > > > > > On 14/03/2016 4:34 PM, sangheon wrote: > >> Hi David, > >> > >> On 03/13/2016 05:49 PM, David Holmes wrote: > >>> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: > >>>> > >>>> > >>>> On 3/10/2016 12:42 PM, Kim Barrett wrote: > >>>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 03/09/2016 08:53 PM, David Holmes wrote: > >>>>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: > >>>>>>>> Background: > >>>>>>>> > >>>>>>>> After the backport of > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag > >>>>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the > >>>>>>>> _workers to null in 8u. > >>>>>>>> > >>>>>>>> As there is no condition to handle such scenario in > >>>>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. > >>>>>>>> > >>>>>>>> The similar condition is already implemented for following > >>>>>>>> scenarios > >>>>>>>> > >>>>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 > >>>>>>>> > >>>>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 > >>>>>>>> > >>>>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Fix: > >>>>>>>> > >>>>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp > >>>>>>>> file > >>>>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" > >>>>>>>> > >>>>>>>> Thanks for the base patch from Jon. > >>>>>>>> > >>>>>>>> Due to this patch it makes some of the test cases absolute. > >>>>>>>> They have been removed. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 > >>>>>>>> > >>>>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ > >>>>>>> This existing code looks wrong: > >>>>>>> > >>>>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, > >>>>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); > >>>>>>> 1677 if (ParallelGCThreads == 0) { > >>>>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, > >>>>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); > >>>>>>> > >>>>>>> Line 1678 seems to do the same as 1675 - is > >>>>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected > >>>>>>> to return a different value on the second call ?? > >>>>>> No, Abstract_VM_Version::parallel_worker_threads() won't return > a > >>>>>> different value for a second call. It's harmless but would be > >>>>>> cleaner deleting 1675,1676. > >>>> > >>>> I retract this suggestion to delete 1675-1676. I'll 99.99% sure > >>>> that it would be OK, but argument processing being what it is and > >>>> this being an update fix, leave those lines in. I've been > >>>> surprised before. > >>> > >>> Okay on being conservative here. But I repeat my earlier statement: > >>> > >>> That aside I'm confused by the fix as we have: > >>> > >>> ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, > >>> 0, > >>> > >>> so it seems odd to report an error for setting a value that is > >>> already the default ?? > >> A flag's value set by default(FLAG_IS_DEFAULT) is different from set > >> by > >> command-line(FLAG_SET_CMDLINE) when we process that flag. > >> Usually a flag that has a default value of '0' means 'will be > decided > >> ergonomically'. > > > > Is this a well-defined convention? I thought that when zero means > "use > > the default" (ie ergonomics or whatever) that it always means that > > regardless of whether it is set explicitly or not! > > It's not a well defined convention. It is something that happened in > one of the GC's and then was imitated or not in others. If there is a > code path for > ParallelGCThreads==0 (that's not calculate me ergonomically), then > explicit setting on the command line of ParallelGCThreads to 0 executes > that code path. That exception has been removed in jdk9. > > Jon > > > > > > Thanks, > > David > > > > > >> > >> From above example, > >> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, > >> 1676 Abstract_VM_Version::parallel_worker_threads()); > >> 1677 if (ParallelGCThreads == 0) { > >> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, > >> 1679 Abstract_VM_Version::parallel_worker_threads()); > >> > >> line1676, parallel_worker_threads() is checking whether the flag is > a > >> default value or not. > >> And use the value if it is not 'set-by-default'. > >> > >> unsigned int Abstract_VM_Version::parallel_worker_threads() { > >> if (!_parallel_worker_threads_initialized) { > >> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { > >> _parallel_worker_threads = > >> VM_Version::calc_parallel_worker_threads(); > >> } else { > >> _parallel_worker_threads = ParallelGCThreads; > >> } > >> _parallel_worker_threads_initialized = true; > >> } > >> return _parallel_worker_threads; > >> } > >> > >> Thanks, > >> Sangheon > >> > >> > >>> > >>> David > >>> ----- > >>> > >>>>> The retry setting to parallel_worker_threads() again code dates > >>>>> back to the initial G1 checkin. Hard to know what was intended. > >>>>> > >>>>> The current jdk9 code does not have that: it looks like > >>>>> > >>>>> FLAG_SET_DEFAULT(ParallelGCThreads, > >>>>> Abstract_VM_Version::parallel_worker_threads()); > >>>>> if (ParallelGCThreads == 0) { > >>>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default > >>>>> value for ParallelGCThreads should not be 0."); > >>>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not > >>>>> be combined with -XX:ParallelGCThreads=0", NULL); > >>>>> } > >>>>> > >>>>> This proposed change is for jdk8u-something, correct? > >>>>> > >>>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can > >>>>> be seen above. Making use of that decision, a cleanup pass was > >>>>> made that eliminated a whole bunch of "if (ParallelGCThreads == > 0) > >>>>> then pretend it's 1 or do some other special thing" code. The > >>>>> backport of 8017462 to 8u72 (i.e. 8149347) looks like it might > not > >>>>> have taken that into account. For example, > >>>>> > >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u- > dev/hotspot/rev/6c57a16d023 > >>>>> 8 > >>>>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed > >>>>> Feb > >>>>> 17 13:42:03 2016 +0000 > >>>>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu > >>>>> +++ Feb > >>>>> 18 20:30:45 2016 +0000 > >>>>> @@ -3991,8 +3991,15 @@ > >>>>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); > >>>>> - uint active_workers = > >>>>> (G1CollectedHeap::use_parallel_gc_threads() ? > >>>>> - workers()->active_workers() : 1); > >>>>> + uint active_workers = > >>>>> AdaptiveSizePolicy::calc_active_workers(workers()- > >total_workers() > >>>>> , > >>>>> + > >>>>> workers()->active_workers(), > >>>>> + > >>>>> Threads::number_of_non_daemon_threads()); > >>>>> > >>>>> Note the conditionalization on use_parallel_gc_threads(). > >>>>> > >>>>> It might be that the simplest thing to do for 8u backporting is > >>>>> indeed to backport prevention of ParallelGCThreads == 0, as > >>>>> suggested in the proposed patch. > >>>> > >>>> I agree although I'll also respond to Thomas next. > >>>> > >>>> Jon > >>>> > >>>>> > >>>>> > >>>>> > >>>> > >> > From gerard.ziemski at oracle.com Tue Mar 15 14:14:32 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 15 Mar 2016 09:14:32 -0500 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E7AABA.4000707@oracle.com> References: <56E7AABA.4000707@oracle.com> Message-ID: <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> Thanks for fixing this. I do have one concern: #1 File src/os/solaris/vm/os_solaris.cpp 4425 // retrieve entry point for pthread_setname_np 4426 Solaris::_pthread_setname_np = 4427 (int(*)(pthread_t, const char*))dlsym(RTLD_DEFAULT, "pthread_setname_np?); According to ?man dlsym? RTLD_DEFAULT can be expensive, i.e.: "If dlsym() is called with the special handle RTLD_DEFAULT, then all mach-o images in the process (except those loaded with dlopen(xxx, RTLD_LOCAL)) are searched in the order they were loaded. This can be a costly search and should be avoided." Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? cheers > On Mar 15, 2016, at 1:24 AM, David Holmes wrote: > > RFE: https://bugs.openjdk.java.net/browse/JDK-8151322 > > Webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev/ > > As of Solaris 11.3 pthread_set_name_np has been implemented: > > http://docs.oracle.com/cd/E53394_01/html/E54766/pthread-setname-np-3c.html#scrolltoc > > https://blogs.oracle.com/observatory/entry/named_threads > > So we can now implement os::set_native_thread_name using dynamic lookup as done on Linux. The only difference is we have 31 characters to play with instead of 16. > > Testing: - JPRT (only 11.2 systems) > - Manually on 11.3 - see examples in bug report > > Thanks, > David From rachel.protacio at oracle.com Tue Mar 15 14:54:19 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 15 Mar 2016 10:54:19 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E80422.4020005@oracle.com> References: <56E701AB.6060705@oracle.com> <56E7077D.4090205@oracle.com> <56E70969.3070007@oracle.com> <56E80422.4020005@oracle.com> Message-ID: <56E8221B.9090100@oracle.com> Thanks, Max! Rachel On 3/15/2016 8:46 AM, Max Ockner wrote: > Looks good to me. > Max > > On 3/14/2016 2:56 PM, Rachel Protacio wrote: >> Hi, >> >> Sorry for the confusion. I have previously converted TraceExceptions >> to Xlog:exceptions=info, so this change is merely adding the >> statement that was previously with TraceClearedExceptions into the >> "exceptions" tag, under the debug level. logging/ExceptionsTest.java >> tests the exceptions tag as a whole, and I did not add to it since >> this portion of code did not seem simple to trigger for the sake of a >> logging test. But of course I'm happy to add a case if someone has a >> specific avenue in mind. >> >> Rachel >> >> On 3/14/2016 2:48 PM, Max Ockner wrote: >>> Rachel, >>> I'm a bit confused to only see two files changed here. Did you leave >>> some files out? Did you add the tag to logTag.hpp in another fix? Is >>> there a test? >>> Thanks, >>> Max >>> >>> On 3/14/2016 2:23 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Please review this change, converting -XX:+TraceClearedExceptions >>>> to -Xlog:exceptions=debug. (This change replaces the one I sent out >>>> earlier that was going to delete the option.) >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ >>>> >>>> Passes JPRT; if you'd like to see additional testing, please let me >>>> know. >>>> >>>> Thank you, >>>> Rachel >>> >> > From rachel.protacio at oracle.com Tue Mar 15 14:54:51 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 15 Mar 2016 10:54:51 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E729D2.5040402@oracle.com> References: <56E701AB.6060705@oracle.com> <56E729D2.5040402@oracle.com> Message-ID: <56E8223A.7090408@oracle.com> Thank you, David! Rachel On 3/14/2016 5:14 PM, David Holmes wrote: > Hi Rachel, > > On 15/03/2016 4:23 AM, Rachel Protacio wrote: >> Hi, >> >> Please review this change, converting -XX:+TraceClearedExceptions to >> -Xlog:exceptions=debug. (This change replaces the one I sent out earlier >> that was going to delete the option.) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ > > Looks good. > >> Passes JPRT; if you'd like to see additional testing, please let me >> know. > > I don't see any need to add this into a testcase (I think it would be > difficult to trigger). > > Thanks, > David > >> Thank you, >> Rachel From max.ockner at oracle.com Tue Mar 15 15:00:13 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 15 Mar 2016 11:00:13 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E0F836.70301@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> Message-ID: <56E8237D.8070908@oracle.com> Hello again, new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ - added resource marks back in - reverted to using outputStreams instead of log_info macro I ran into an issue with the outputStream eating its output when I removed " ]\n" from the end of some of the messages, solved by changing "out->print" to "out->print_cr". I thought about writing a log_info_rm which evaluates to a code block instead of a function, but I think one of the benefits of the current macros is that they allow two variable argument lists in the same expression. Returning a write function is important for handling the format string and its variable length argument list of format %substitutions. Thanks, Max On 3/9/2016 11:29 PM, David Holmes wrote: > On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >> >> >> >> Why did you take out the ResourceMarks at line 130, 160, 231 and 244, >> 297, 308 and 357? > > Yes these should all be of the form: > > if (log_is_enabled(...)) { > ResourceMark rm; > // log stuff > } > >> Unfortunately, we really need log_info_rm(tag)("String") call because >> all those places need a ResourceMark. >> >> Anytime we call name()->as_C_string() there needs to be a ResourceMark >> in the scope of the call. > > Which means that a log_info_rm() call wouldn't help because we'd still > be calling as_C_string in the caller. :( > > David > >> >> Coleen >> >> On 3/9/16 3:47 PM, Max Ockner wrote: >>> Hello again, >>> >>> Please review this change. TraceLoaderConstraints has been converted >>> to Unified Logging and can be accessed using >>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added >>> to the logging alias table. >>> >>> There are 0 lines of output for java -version, and ~10 lines from >>> LoaderConstraintsTest.java >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>> >>> Testing: jtreg runtime. Added new test which triggers logging for >>> loaderconstraints by forcing class unloading. No other references to >>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>> noncolo tests. >>> >>> Thanks, >>> Max >> From coleen.phillimore at oracle.com Tue Mar 15 15:02:37 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Mar 2016 11:02:37 -0400 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56E8009B.7070009@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> <56E8009B.7070009@oracle.com> Message-ID: <56E8240D.5000006@oracle.com> This looks fine to me, as-is. On 3/15/16 8:31 AM, David Holmes wrote: > Hi Thomas, > > On 15/03/2016 8:07 PM, Thomas St?fe wrote: >> Hi David, >> >> sorry, I will have not the time to work on this this week. If the patch >> is acceptable to you in this form, I'd say we commit it, otherwise I'll >> take it up again some time later. > > If Coleen is okay with this as-is I'll commit it in the morning. > >> About the suggested changes: >> >> - Merging both APIs into one, like suggested, is fine for me and I would >> do this in a follow-up. > > Sure. > >> - Handling unknown errno values: I do not like the idea of a fallback to >> ::strerror(). Writing the API comment on that one would be weird: "Is >> almost threadsafe", "will probably return a static constant string"... >> :) I would suggest either using the solution as it is now - only >> honouring POSIX errno values or returning "Unknown", or to expand them >> with OS specific lists, either in the OS independent form ("#ifdef EBLUB >> handle(EBLUB) #endif") or by expanding os::strerror() with platform >> dependend os::strerror_pd(). >> >> I am pretty unemotional about either option but would prefer avoiding >> ::strerror() altogether. > > A follow up on this okay. I'm unsure how best to handle it. Given how > rarely we encounter errors I'm probably over-thinking it. ;) > Yeah, I think you're over-thinking it. The two APIs with comments make sense to me, and something returning Unknown isn't a big deal in real life. Thanks for the change and thanks for sponsoring this, David. Coleen > Thanks, > David > >> Kind Regards, Thomas >> >> >> >> On Mon, Mar 14, 2016 at 4:43 AM, David Holmes > > wrote: >> >> On 12/03/2016 6:22 PM, Thomas St?fe wrote: >> >> Hi David, >> >> thanks again for your review. Here the new version: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ >> >> And the diff to the last version: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt >> >> I fixed the indention, copyright comments and the typo. >> >> >> All looks good - thanks. >> >> Further comments inline. >> >> >> Ditto :) >> >> >> On Fri, Mar 11, 2016 at 8:04 AM, David Holmes >> >> > >> wrote: >> >> Hi Thomas, >> >> Thanks for persevering with this. Sorry for the delayed >> response. >> >> On 10/03/2016 2:58 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please take a look at this next version of the fix. >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ >> >> I am the first to admit that this is quite ugly :(, but >> it is a >> pragmatic solution. >> >> Some details: >> >> - I added os::strerror() as a drop-in replacement for >> ::strerror() - it >> returns the text as before, but does not localize and >> does not >> handle >> unknown error values; so it can be implemented using a >> simple static >> string table and is always safe to use. >> >> >> Ok. But I don't think we need os::lasterror() if we have >> this. A >> follow up clean-up is okay for that though. >> >> >> I would love to keep this functionality, because I like printing >> out the >> short concise errno values, and there are a number of logging >> changes >> coming at least for AIX. It also does not cost much, as the >> large string >> table is already there. >> >> If the second API does not suit you, would it be accepable for >> you if I >> hide this functionality behind a second parameter in strerror, >> defaulting to false, like I did in my first version? E.g. >> os::strerror(int e, bool short_name=false); ? >> >> >> That was what I was thinking of yes. :) >> >> But talking about clean-up, could we get rid of >> os::lasterror() ? I >> think that function is a bad idea, and it fortunately is only >> called in >> two places, both just need strerror() and no Win32 error >> handling anyway. >> >> >> Sounds good. lasterror() is a fragile API as it is too easy to >> introduce unexpected system calls between the call to lasterror and >> the action you want to check for the error. >> >> I also would like to remove os::get_last_error(). It returns >> errno on >> *nix, win32 error on Windows. Both are different things, plus >> there is >> also an errno on Windows The return value of this function is >> useless >> without knowing what the returned error number actually is, so >> it is not >> of much use. >> >> >> Simplifying and streamlining all this sounds good. >> >> Also it does seem to handle unknown error values. >> >> - I added os::errno_name() for those cases where one >> would want the >> literalized errno value (e.g. "EINVAL") instead of the >> full text. >> >> >> Ok. For the unknown case can it return the numeric value >> that it was >> passed? >> >> >> I would like to avoid this. This would make the function more >> complicated. >> >> I'd need to keep this thread-safe, so I either would have to >> allocate >> thread local storage for the return string somehow or, >> alternatively, >> keep a fixed string table a la [][] {"unknown (0)", >> "unknown(1)"} for >> the first n values or so. >> >> >> Okay. I was thinking this would be simpler but of course we have to >> convert to a string. >> >> I note that linux defines ~133 errno values, and you have entries >> for ~75 - are they all the POSIX ones? >> >> I'm wondering whether we should have a fallback strategy for an >> unknown (platform-specific) error by using the platform strerror >> even though not thread-safe (the window of exposure is vastly >> reduced) ? >> >> Also, ::strerror() behaves not consistently for the EINVAL case >> on all >> platforms anyway - on Linux and Bsd, it returns the numerical >> value, but >> on Solaris, Windows and AIX, it just returns "Unknown". Many >> callsites I >> saw take this already into account and print out the >> numerical errno >> value in addition to the error string. >> >> >> I doubt those callsites are not taking into account unknown values - >> I think you will find they originally only reported the numerical >> value and were then augmented to also print the strerror message. >> >> Thanks, >> David >> >> - I fixed all callsites in the hotspot which used >> ::strerror to use >> os::strerror, or, in some few cases (mostly my own >> coding for AIX), >> os::errno_name(). >> >> >> Bit subjective but okay - I personally don't care either >> way. :) >> >> - To avoid including os.hpp in debug.hpp, I moved the >> implemntation of >> assert_status to debug.cpp >> >> >> Okay ... did the include cause a problem? >> >> >> os.hpp is a large beast. I wanted to keep it out of debug.hpp, >> to not >> force this include upon anyone who includes debug.hpp just to >> get >> assert(). I also try to avoid calling system apis in header >> files. >> >> >> >> General minor comments: >> >> src/os/posix/vm/os_posix.cpp >> >> Indentation of wrapped call needs fixing >> >> >> Fixed >> >> --- >> >> src/share/vm/runtime/os.hpp >> >> Typo: >> >> + // sugested in the POSIX standard. >> >> -> suggested >> >> >> Fixed >> >> --- >> >> src/share/vm/utilities/vmError.cpp >> >> Good catch on the code that potentially reports the >> wrong error >> using get_last_error! Even the simple print_cr(..., >> strerror(errno), >> errno) could in fact print non-matching values if strerror >> itself >> caused an error (unlikely of course :) ). >> >> >> Thanks :) >> >> >> Please check all copyright years - >> attachListener_solaris.cpp was >> updated to 2015 instead of 2016 :) Also note correct format >> for two >> year copyrights - in src/share/vm/logging/logFileOutput.cpp >> you have: >> >> Copyright (c) 2015,2016 Oracle >> >> but it should be: >> >> Copyright (c) 2015, 2016, Oracle >> >> Fixed >> >> Thanks, >> David >> >> >> Thanks! >> >> Thomas >> >> >> Kind Regards, Thomas >> >> >> >> >> On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore >> > >> > > >> > >> >> > >>> wrote: >> >> >> This latest version seems okay (or at least better >> than the >> other >> workarounds). >> >> thanks, >> Coleen >> >> >> On 3/1/16 12:30 AM, David Holmes wrote: >> >> Hi Thomas, >> >> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >> >> Hi David, >> >> On Mon, Feb 29, 2016 at 4:44 AM, David >> Holmes >> > >> > > >> >> > >> >> > >> > > >> >> > >> > >>>> wrote: >> >> Hi Thomas, >> >> On 27/02/2016 2:05 AM, Thomas St?fe >> wrote: >> >> Hi, >> >> please take a look at this >> proposed fix: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8148425 >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >> >> This adds a replacement function >> os::strerror() as >> a drop-in for >> strerror(), which has a number of >> issues. >> >> strerror() is unsafe to use and >> may cause >> (and has >> caused) >> crashes in >> multithreaded scenarios. It is >> also not >> ideal for >> log files >> because of the >> implicit localization of the >> error messages. >> >> For details please see the >> discussion >> under the bug >> report. >> >> >> I just came across strerror_l, >> which is >> required to be >> thread-safe. >> Is that a possible alternative? (I'm >> not sure how >> locale's are >> obtained). >> >> >> Sorry, I think this API is glibc only. At >> least I >> cannot >> find this in >> our AIX headers, nor on Solaris. >> >> >> It is a POSIX API: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >> >> added in 2006 but part of POSIX.1-2008. But >> as per >> Dalibor's >> link not necessarily available: >> >> "This function is missing on some >> platforms: glibc >> 2.3.6, Mac OS >> X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, >> Minix >> 3.1.8, AIX >> 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 >> 2011-11, >> Cygwin, >> mingw, MSVC 9, Interix 3.5, BeOS. " >> >> Pity. >> >> >> Otherwise what you have seems okay - >> though I do >> dislike having to >> duplicate all that details already >> buried in >> the system >> headers/library. Not sure we need to >> the long >> text at >> the VM level - >> which would simplify things a bit. >> >> >> I agree, I dislike this too. Like everyone >> else in this >> thread. But I >> think this is a pragmatic solution. >> >> I am a bit stuck here - should we really >> get rid of >> the long >> text >> feature? There are some callsites of >> strerror() in the >> hotspot where >> arguably the long text is better suited: >> - in assert_status() (see debug.hpp) - >> this ends up >> in the >> header of >> error files, if this suddenly changes to a >> literalized >> errno, people may >> be upset >> >> >> I added assert_status purely to expand on what >> the failing >> status was :) I'm happy to see EINVAL in that >> context >> rather >> than "invalid argument" (or whatever) :) >> >> - when failing to write a heap dump >> file - see >> services/heapDumper.cpp. >> Which ends as printout on the command >> line, I think. >> >> >> Maybe ... if it is an error the user can fix. >> >> The safe option would be to provide both >> variants >> (short and >> long text). >> Or, provide the safe, short variant for >> all logging >> calls - when >> "EINVAL" is enough, and let users continue >> to use >> strerror() >> for those >> few cases where the long text is needed. >> >> What do you think? >> >> >> Trying to decide what makes me least unhappy. >> :) Given >> you've >> already done the work I guess having long and >> short >> forms is okay. >> >> Thanks, >> David >> >> Thanks, Thomas >> >> Thanks, >> David >> >> >> Please note that I did not yet >> change any call >> sites, although >> all call >> sites in the os namespace should >> already >> use the >> new function. I >> wanted to >> see whether there would be any >> general >> objections. >> >> Kind Regards, Thomas >> >> >> >> >> >> From thomas.stuefe at gmail.com Tue Mar 15 16:02:31 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Mar 2016 17:02:31 +0100 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: <56E8240D.5000006@oracle.com> References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> <56E8009B.7070009@oracle.com> <56E8240D.5000006@oracle.com> Message-ID: Coleen, David, thank you both! I will do a follow up change later when there is more time. Kind regards, Thomas On Tue, Mar 15, 2016 at 4:02 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > This looks fine to me, as-is. > > On 3/15/16 8:31 AM, David Holmes wrote: > >> Hi Thomas, >> >> On 15/03/2016 8:07 PM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> sorry, I will have not the time to work on this this week. If the patch >>> is acceptable to you in this form, I'd say we commit it, otherwise I'll >>> take it up again some time later. >>> >> >> If Coleen is okay with this as-is I'll commit it in the morning. >> >> About the suggested changes: >>> >>> - Merging both APIs into one, like suggested, is fine for me and I would >>> do this in a follow-up. >>> >> >> Sure. >> >> - Handling unknown errno values: I do not like the idea of a fallback to >>> ::strerror(). Writing the API comment on that one would be weird: "Is >>> almost threadsafe", "will probably return a static constant string"... >>> :) I would suggest either using the solution as it is now - only >>> honouring POSIX errno values or returning "Unknown", or to expand them >>> with OS specific lists, either in the OS independent form ("#ifdef EBLUB >>> handle(EBLUB) #endif") or by expanding os::strerror() with platform >>> dependend os::strerror_pd(). >>> >>> I am pretty unemotional about either option but would prefer avoiding >>> ::strerror() altogether. >>> >> >> A follow up on this okay. I'm unsure how best to handle it. Given how >> rarely we encounter errors I'm probably over-thinking it. ;) >> >> > Yeah, I think you're over-thinking it. The two APIs with comments make > sense to me, and something returning Unknown isn't a big deal in real life. > > Thanks for the change and thanks for sponsoring this, David. > > Coleen > > > Thanks, >> David >> >> Kind Regards, Thomas >>> >>> >>> >>> On Mon, Mar 14, 2016 at 4:43 AM, David Holmes >> > wrote: >>> >>> On 12/03/2016 6:22 PM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> thanks again for your review. Here the new version: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ >>> >>> And the diff to the last version: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt >>> >>> I fixed the indention, copyright comments and the typo. >>> >>> >>> All looks good - thanks. >>> >>> Further comments inline. >>> >>> >>> Ditto :) >>> >>> >>> On Fri, Mar 11, 2016 at 8:04 AM, David Holmes >>> >>> >> >> wrote: >>> >>> Hi Thomas, >>> >>> Thanks for persevering with this. Sorry for the delayed >>> response. >>> >>> On 10/03/2016 2:58 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> please take a look at this next version of the fix. >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ >>> >>> I am the first to admit that this is quite ugly :(, but >>> it is a >>> pragmatic solution. >>> >>> Some details: >>> >>> - I added os::strerror() as a drop-in replacement for >>> ::strerror() - it >>> returns the text as before, but does not localize and >>> does not >>> handle >>> unknown error values; so it can be implemented using a >>> simple static >>> string table and is always safe to use. >>> >>> >>> Ok. But I don't think we need os::lasterror() if we have >>> this. A >>> follow up clean-up is okay for that though. >>> >>> >>> I would love to keep this functionality, because I like printing >>> out the >>> short concise errno values, and there are a number of logging >>> changes >>> coming at least for AIX. It also does not cost much, as the >>> large string >>> table is already there. >>> >>> If the second API does not suit you, would it be accepable for >>> you if I >>> hide this functionality behind a second parameter in strerror, >>> defaulting to false, like I did in my first version? E.g. >>> os::strerror(int e, bool short_name=false); ? >>> >>> >>> That was what I was thinking of yes. :) >>> >>> But talking about clean-up, could we get rid of os::lasterror() >>> ? I >>> think that function is a bad idea, and it fortunately is only >>> called in >>> two places, both just need strerror() and no Win32 error >>> handling anyway. >>> >>> >>> Sounds good. lasterror() is a fragile API as it is too easy to >>> introduce unexpected system calls between the call to lasterror and >>> the action you want to check for the error. >>> >>> I also would like to remove os::get_last_error(). It returns >>> errno on >>> *nix, win32 error on Windows. Both are different things, plus >>> there is >>> also an errno on Windows The return value of this function is >>> useless >>> without knowing what the returned error number actually is, so >>> it is not >>> of much use. >>> >>> >>> Simplifying and streamlining all this sounds good. >>> >>> Also it does seem to handle unknown error values. >>> >>> - I added os::errno_name() for those cases where one >>> would want the >>> literalized errno value (e.g. "EINVAL") instead of the >>> full text. >>> >>> >>> Ok. For the unknown case can it return the numeric value >>> that it was >>> passed? >>> >>> >>> I would like to avoid this. This would make the function more >>> complicated. >>> >>> I'd need to keep this thread-safe, so I either would have to >>> allocate >>> thread local storage for the return string somehow or, >>> alternatively, >>> keep a fixed string table a la [][] {"unknown (0)", >>> "unknown(1)"} for >>> the first n values or so. >>> >>> >>> Okay. I was thinking this would be simpler but of course we have to >>> convert to a string. >>> >>> I note that linux defines ~133 errno values, and you have entries >>> for ~75 - are they all the POSIX ones? >>> >>> I'm wondering whether we should have a fallback strategy for an >>> unknown (platform-specific) error by using the platform strerror >>> even though not thread-safe (the window of exposure is vastly >>> reduced) ? >>> >>> Also, ::strerror() behaves not consistently for the EINVAL case >>> on all >>> platforms anyway - on Linux and Bsd, it returns the numerical >>> value, but >>> on Solaris, Windows and AIX, it just returns "Unknown". Many >>> callsites I >>> saw take this already into account and print out the numerical >>> errno >>> value in addition to the error string. >>> >>> >>> I doubt those callsites are not taking into account unknown values - >>> I think you will find they originally only reported the numerical >>> value and were then augmented to also print the strerror message. >>> >>> Thanks, >>> David >>> >>> - I fixed all callsites in the hotspot which used >>> ::strerror to use >>> os::strerror, or, in some few cases (mostly my own >>> coding for AIX), >>> os::errno_name(). >>> >>> >>> Bit subjective but okay - I personally don't care either >>> way. :) >>> >>> - To avoid including os.hpp in debug.hpp, I moved the >>> implemntation of >>> assert_status to debug.cpp >>> >>> >>> Okay ... did the include cause a problem? >>> >>> >>> os.hpp is a large beast. I wanted to keep it out of debug.hpp, >>> to not >>> force this include upon anyone who includes debug.hpp just to get >>> assert(). I also try to avoid calling system apis in header >>> files. >>> >>> >>> >>> General minor comments: >>> >>> src/os/posix/vm/os_posix.cpp >>> >>> Indentation of wrapped call needs fixing >>> >>> >>> Fixed >>> >>> --- >>> >>> src/share/vm/runtime/os.hpp >>> >>> Typo: >>> >>> + // sugested in the POSIX standard. >>> >>> -> suggested >>> >>> >>> Fixed >>> >>> --- >>> >>> src/share/vm/utilities/vmError.cpp >>> >>> Good catch on the code that potentially reports the wrong >>> error >>> using get_last_error! Even the simple print_cr(..., >>> strerror(errno), >>> errno) could in fact print non-matching values if strerror >>> itself >>> caused an error (unlikely of course :) ). >>> >>> >>> Thanks :) >>> >>> >>> Please check all copyright years - >>> attachListener_solaris.cpp was >>> updated to 2015 instead of 2016 :) Also note correct format >>> for two >>> year copyrights - in src/share/vm/logging/logFileOutput.cpp >>> you have: >>> >>> Copyright (c) 2015,2016 Oracle >>> >>> but it should be: >>> >>> Copyright (c) 2015, 2016, Oracle >>> >>> Fixed >>> >>> Thanks, >>> David >>> >>> >>> Thanks! >>> >>> Thomas >>> >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> On Tue, Mar 8, 2016 at 11:01 PM, Coleen Phillimore >>> >> >>> >> > >>> >> >>> >>> >> >>> wrote: >>> >>> >>> This latest version seems okay (or at least better >>> than the >>> other >>> workarounds). >>> >>> thanks, >>> Coleen >>> >>> >>> On 3/1/16 12:30 AM, David Holmes wrote: >>> >>> Hi Thomas, >>> >>> On 1/03/2016 3:23 AM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> On Mon, Feb 29, 2016 at 4:44 AM, David >>> Holmes >>> >> >>> >> > >>> >>> >> >> >>> >> >>> >> > >>> >>> >> >>> >> >>>> wrote: >>> >>> Hi Thomas, >>> >>> On 27/02/2016 2:05 AM, Thomas St?fe >>> wrote: >>> >>> Hi, >>> >>> please take a look at this >>> proposed fix: >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8148425 >>> Webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ >>> >>> This adds a replacement function >>> os::strerror() as >>> a drop-in for >>> strerror(), which has a number of >>> issues. >>> >>> strerror() is unsafe to use and >>> may cause >>> (and has >>> caused) >>> crashes in >>> multithreaded scenarios. It is >>> also not >>> ideal for >>> log files >>> because of the >>> implicit localization of the >>> error messages. >>> >>> For details please see the >>> discussion >>> under the bug >>> report. >>> >>> >>> I just came across strerror_l, which >>> is >>> required to be >>> thread-safe. >>> Is that a possible alternative? (I'm >>> not sure how >>> locale's are >>> obtained). >>> >>> >>> Sorry, I think this API is glibc only. At >>> least I >>> cannot >>> find this in >>> our AIX headers, nor on Solaris. >>> >>> >>> It is a POSIX API: >>> >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html >>> >>> added in 2006 but part of POSIX.1-2008. But as >>> per >>> Dalibor's >>> link not necessarily available: >>> >>> "This function is missing on some platforms: >>> glibc >>> 2.3.6, Mac OS >>> X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, >>> Minix >>> 3.1.8, AIX >>> 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 >>> 2011-11, >>> Cygwin, >>> mingw, MSVC 9, Interix 3.5, BeOS. " >>> >>> Pity. >>> >>> >>> Otherwise what you have seems okay - >>> though I do >>> dislike having to >>> duplicate all that details already >>> buried in >>> the system >>> headers/library. Not sure we need to >>> the long >>> text at >>> the VM level - >>> which would simplify things a bit. >>> >>> >>> I agree, I dislike this too. Like everyone >>> else in this >>> thread. But I >>> think this is a pragmatic solution. >>> >>> I am a bit stuck here - should we really >>> get rid of >>> the long >>> text >>> feature? There are some callsites of >>> strerror() in the >>> hotspot where >>> arguably the long text is better suited: >>> - in assert_status() (see debug.hpp) - >>> this ends up >>> in the >>> header of >>> error files, if this suddenly changes to a >>> literalized >>> errno, people may >>> be upset >>> >>> >>> I added assert_status purely to expand on what >>> the failing >>> status was :) I'm happy to see EINVAL in that >>> context >>> rather >>> than "invalid argument" (or whatever) :) >>> >>> - when failing to write a heap dump file - >>> see >>> services/heapDumper.cpp. >>> Which ends as printout on the command >>> line, I think. >>> >>> >>> Maybe ... if it is an error the user can fix. >>> >>> The safe option would be to provide both >>> variants >>> (short and >>> long text). >>> Or, provide the safe, short variant for >>> all logging >>> calls - when >>> "EINVAL" is enough, and let users continue >>> to use >>> strerror() >>> for those >>> few cases where the long text is needed. >>> >>> What do you think? >>> >>> >>> Trying to decide what makes me least unhappy. >>> :) Given >>> you've >>> already done the work I guess having long and >>> short >>> forms is okay. >>> >>> Thanks, >>> David >>> >>> Thanks, Thomas >>> >>> Thanks, >>> David >>> >>> >>> Please note that I did not yet >>> change any call >>> sites, although >>> all call >>> sites in the os namespace should >>> already >>> use the >>> new function. I >>> wanted to >>> see whether there would be any >>> general >>> objections. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> >>> >>> > From gerard.ziemski at oracle.com Tue Mar 15 16:28:30 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 15 Mar 2016 11:28:30 -0500 Subject: RFR (M): 8142510: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <56E32EA5.6050602@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <56E32EA5.6050602@oracle.com> Message-ID: <0EB22C80-0C96-4ECA-8CCD-FD9D0EFB13D9@oracle.com> hi Dmitry, Thank you very much for the review. Please see my answers inline: > On Mar 11, 2016, at 2:46 PM, Dmitry Dmitriev wrote: > > Hi Gerard, > > Few comments, otherwise looks good. Thank you for doing that! > 1) src/share/vm/runtime/globals.cpp > I think that it's unnecessary to declare string_length and range_string as static in create_range_str function. The intention is to reuse the buffer and only allocate more memory if absolutely necessary. The ?static? designation allows us to cache the buffer between calls. > > 2) src/share/vm/runtime/commandLineFlagConstraintList.cpp > New function CommandLineFlagConstraintList::find looks very similar to the existing one CommandLineFlagConstraintList::find_if_needs_check. I think that you can remove duplicated logic by refactoring CommandLineFlagConstraintList::find_if_needs_check as follows: > CommandLineFlagConstraint* CommandLineFlagConstraintList::find_if_needs_check(const char* name) { > CommandLineFlagConstraint* found = find(name); > if ((found != NULL) && > (found->type() > _validating_type)) { > *** Please add appropriate comment here, why found is set back to NULL *** > found = NULL; > } > return found; > } > A good suggestion. I will update and post 2nd webrev shortly. cheers > Thanks, > Dmitry > > On 09.03.2016 20:33, Gerard Ziemski wrote: >> hi all, >> >> Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) >> >> bug https://bugs.openjdk.java.net/browse/JDK-8142510 >> webrev http://cr.openjdk.java.net/~gziemski/8142510_rev0 >> >> tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation >> >> >> cheers > From coleen.phillimore at oracle.com Tue Mar 15 16:48:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Mar 2016 12:48:24 -0400 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> <56E8009B.7070009@oracle.com> <56E8240D.5000006@oracle.com> Message-ID: <56E83CD8.5010801@oracle.com> On 3/15/16 12:02 PM, Thomas St?fe wrote: > Coleen, David, > > thank you both! > > I will do a follow up change later when there is more time. Hi Thomas, Feature complete for jdk9 is coming soon and we'll stop wanting to sponsor RFEs, unless they are high priority by some definition. The date for Hotspot is May 12 to allow for integration and testing. Also with Jigsaw integrating soon, we're trying to limit the changes that it needs to merge with. I think the Jigsaw changes were sent to the OpenJDK last week. thanks, Coleen > > Kind regards, Thomas > > > > On Tue, Mar 15, 2016 at 4:02 PM, Coleen Phillimore > > > wrote: > > > This looks fine to me, as-is. > > On 3/15/16 8:31 AM, David Holmes wrote: > > Hi Thomas, > > On 15/03/2016 8:07 PM, Thomas St?fe wrote: > > Hi David, > > sorry, I will have not the time to work on this this week. > If the patch > is acceptable to you in this form, I'd say we commit it, > otherwise I'll > take it up again some time later. > > > If Coleen is okay with this as-is I'll commit it in the morning. > > About the suggested changes: > > - Merging both APIs into one, like suggested, is fine for > me and I would > do this in a follow-up. > > > Sure. > > - Handling unknown errno values: I do not like the idea of > a fallback to > ::strerror(). Writing the API comment on that one would be > weird: "Is > almost threadsafe", "will probably return a static > constant string"... > :) I would suggest either using the solution as it is now > - only > honouring POSIX errno values or returning "Unknown", or to > expand them > with OS specific lists, either in the OS independent form > ("#ifdef EBLUB > handle(EBLUB) #endif") or by expanding os::strerror() with > platform > dependend os::strerror_pd(). > > I am pretty unemotional about either option but would > prefer avoiding > ::strerror() altogether. > > > A follow up on this okay. I'm unsure how best to handle it. > Given how rarely we encounter errors I'm probably > over-thinking it. ;) > > > Yeah, I think you're over-thinking it. The two APIs with comments > make sense to me, and something returning Unknown isn't a big deal > in real life. > > Thanks for the change and thanks for sponsoring this, David. > > Coleen > > > Thanks, > David > > Kind Regards, Thomas > > > > On Mon, Mar 14, 2016 at 4:43 AM, David Holmes > > >> wrote: > > On 12/03/2016 6:22 PM, Thomas St?fe wrote: > > Hi David, > > thanks again for your review. Here the new version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ > > > And the diff to the last version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt > > > I fixed the indention, copyright comments and the > typo. > > > All looks good - thanks. > > Further comments inline. > > > Ditto :) > > > On Fri, Mar 11, 2016 at 8:04 AM, David Holmes > > > > > >>> wrote: > > Hi Thomas, > > Thanks for persevering with this. Sorry for > the delayed > response. > > On 10/03/2016 2:58 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at this next version > of the fix. > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ > > > I am the first to admit that this is > quite ugly :(, but > it is a > pragmatic solution. > > Some details: > > - I added os::strerror() as a drop-in > replacement for > ::strerror() - it > returns the text as before, but does not > localize and > does not > handle > unknown error values; so it can be > implemented using a > simple static > string table and is always safe to use. > > > Ok. But I don't think we need os::lasterror() > if we have > this. A > follow up clean-up is okay for that though. > > > I would love to keep this functionality, because I > like printing > out the > short concise errno values, and there are a number > of logging > changes > coming at least for AIX. It also does not cost > much, as the > large string > table is already there. > > If the second API does not suit you, would it be > accepable for > you if I > hide this functionality behind a second parameter > in strerror, > defaulting to false, like I did in my first > version? E.g. > os::strerror(int e, bool short_name=false); ? > > > That was what I was thinking of yes. :) > > But talking about clean-up, could we get rid of > os::lasterror() ? I > think that function is a bad idea, and it > fortunately is only > called in > two places, both just need strerror() and no Win32 > error > handling anyway. > > > Sounds good. lasterror() is a fragile API as it is too > easy to > introduce unexpected system calls between the call to > lasterror and > the action you want to check for the error. > > I also would like to remove os::get_last_error(). > It returns > errno on > *nix, win32 error on Windows. Both are different > things, plus > there is > also an errno on Windows The return value of this > function is > useless > without knowing what the returned error number > actually is, so > it is not > of much use. > > > Simplifying and streamlining all this sounds good. > > Also it does seem to handle unknown error values. > > - I added os::errno_name() for those > cases where one > would want the > literalized errno value (e.g. "EINVAL") > instead of the > full text. > > > Ok. For the unknown case can it return the > numeric value > that it was > passed? > > > I would like to avoid this. This would make the > function more > complicated. > > I'd need to keep this thread-safe, so I either > would have to > allocate > thread local storage for the return string somehow or, > alternatively, > keep a fixed string table a la [][] {"unknown (0)", > "unknown(1)"} for > the first n values or so. > > > Okay. I was thinking this would be simpler but of > course we have to > convert to a string. > > I note that linux defines ~133 errno values, and you > have entries > for ~75 - are they all the POSIX ones? > > I'm wondering whether we should have a fallback > strategy for an > unknown (platform-specific) error by using the > platform strerror > even though not thread-safe (the window of exposure is > vastly reduced) ? > > Also, ::strerror() behaves not consistently for > the EINVAL case > on all > platforms anyway - on Linux and Bsd, it returns > the numerical > value, but > on Solaris, Windows and AIX, it just returns > "Unknown". Many > callsites I > saw take this already into account and print out > the numerical errno > value in addition to the error string. > > > I doubt those callsites are not taking into account > unknown values - > I think you will find they originally only reported > the numerical > value and were then augmented to also print the > strerror message. > > Thanks, > David > > - I fixed all callsites in the hotspot > which used > ::strerror to use > os::strerror, or, in some few cases > (mostly my own > coding for AIX), > os::errno_name(). > > > Bit subjective but okay - I personally don't > care either > way. :) > > - To avoid including os.hpp in debug.hpp, > I moved the > implemntation of > assert_status to debug.cpp > > > Okay ... did the include cause a problem? > > > os.hpp is a large beast. I wanted to keep it out > of debug.hpp, > to not > force this include upon anyone who includes > debug.hpp just to get > assert(). I also try to avoid calling system apis > in header files. > > > > General minor comments: > > src/os/posix/vm/os_posix.cpp > > Indentation of wrapped call needs fixing > > > Fixed > > --- > > src/share/vm/runtime/os.hpp > > Typo: > > + // sugested in the POSIX standard. > > -> suggested > > > Fixed > > --- > > src/share/vm/utilities/vmError.cpp > > Good catch on the code that potentially > reports the wrong error > using get_last_error! Even the simple > print_cr(..., > strerror(errno), > errno) could in fact print non-matching > values if strerror > itself > caused an error (unlikely of course :) ). > > > Thanks :) > > > Please check all copyright years - > attachListener_solaris.cpp was > updated to 2015 instead of 2016 :) Also note > correct format > for two > year copyrights - in > src/share/vm/logging/logFileOutput.cpp > you have: > > Copyright (c) 2015,2016 Oracle > > but it should be: > > Copyright (c) 2015, 2016, Oracle > > Fixed > > Thanks, > David > > > Thanks! > > Thomas > > > Kind Regards, Thomas > > > > > On Tue, Mar 8, 2016 at 11:01 PM, Coleen > Phillimore > > > > > >> > > > > > > >>>> wrote: > > > This latest version seems okay (or > at least better > than the > other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas > St?fe wrote: > > Hi David, > > On Mon, Feb 29, 2016 at 4:44 > AM, David Holmes > > > > > >> > > > > > >>> > > > > > > >> > > > > > > > >>>>> wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, > Thomas St?fe > wrote: > > Hi, > > please take a look > at this > proposed fix: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > > This adds a > replacement function > os::strerror() as > a drop-in for > strerror(), which > has a number of > issues. > > strerror() is > unsafe to use and > may cause > (and has > caused) > crashes in > multithreaded > scenarios. It is > also not > ideal for > log files > because of the > implicit > localization of the > error messages. > > For details please > see the discussion > under the bug > report. > > > I just came across > strerror_l, which is > required to be > thread-safe. > Is that a possible > alternative? (I'm > not sure how > locale's are > obtained). > > > Sorry, I think this API is > glibc only. At > least I > cannot > find this in > our AIX headers, nor on Solaris. > > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of > POSIX.1-2008. But as per > Dalibor's > link not necessarily available: > > "This function is missing on > some platforms: glibc > 2.3.6, Mac OS > X 10.5, FreeBSD 6.0, NetBSD 5.0, > OpenBSD 3.8, > Minix > 3.1.8, AIX > 5.1, HP-UX 11, IRIX 6.5, OSF/1 > 5.1, Solaris 11 > 2011-11, > Cygwin, > mingw, MSVC 9, Interix 3.5, BeOS. " > > Pity. > > > Otherwise what you have > seems okay - > though I do > dislike having to > duplicate all that > details already > buried in > the system > headers/library. Not > sure we need to > the long > text at > the VM level - > which would simplify > things a bit. > > > I agree, I dislike this too. > Like everyone > else in this > thread. But I > think this is a pragmatic > solution. > > I am a bit stuck here - > should we really > get rid of > the long > text > feature? There are some > callsites of > strerror() in the > hotspot where > arguably the long text is > better suited: > - in assert_status() (see > debug.hpp) - > this ends up > in the > header of > error files, if this > suddenly changes to a > literalized > errno, people may > be upset > > > I added assert_status purely to > expand on what > the failing > status was :) I'm happy to see > EINVAL in that > context > rather > than "invalid argument" (or > whatever) :) > > - when failing to write a > heap dump file - see > services/heapDumper.cpp. > Which ends as printout on > the command > line, I think. > > > Maybe ... if it is an error the > user can fix. > > The safe option would be to > provide both > variants > (short and > long text). > Or, provide the safe, short > variant for > all logging > calls - when > "EINVAL" is enough, and let > users continue > to use > strerror() > for those > few cases where the long > text is needed. > > What do you think? > > > Trying to decide what makes me > least unhappy. > :) Given > you've > already done the work I guess > having long and > short > forms is okay. > > Thanks, > David > > Thanks, Thomas > > Thanks, > David > > > Please note that I > did not yet > change any call > sites, although > all call > sites in the os > namespace should > already > use the > new function. I > wanted to > see whether there > would be any > general > objections. > > Kind Regards, Thomas > > > > > > > > From max.ockner at oracle.com Tue Mar 15 17:45:17 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 15 Mar 2016 13:45:17 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. Message-ID: <56E84A2D.30304@oracle.com> Hello again everyone! Please review this change which adds better error messages for non-product flags that are now converted to Unified Logging. bug: https://bugs.openjdk.java.net/browse/JDK-8146632 webrev: http://cr.openjdk.java.net/~mockner/8146632/ Since these options have been removed, we want still want the vm to crash here, but now with an error message giving the correct command line option. The new message looks like this: > TraceClassInitialization has been removed. Please use -Xlog:classinit instead." The entire output looks like this: > TraceClassInitialization has been removed. Please use -Xlog:classinit instead. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. Tested with jtreg runtime tests. A new test checks for an appropriate error message for every develop flag that has so far been converted to logging. Thanks, Max From coleen.phillimore at oracle.com Tue Mar 15 18:56:09 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Mar 2016 14:56:09 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E84A2D.30304@oracle.com> References: <56E84A2D.30304@oracle.com> Message-ID: <56E85AC9.9020503@oracle.com> Max, I think this looks fine. Small nit (for which I don't need to see another webrev). Can you change #endif for the end of the #ifdef PRODUCT to #endif // PRODUCT This message is so much friendlier. Oh, and the vm doesn't crash, it just exits... Thanks! Coleen On 3/15/16 1:45 PM, Max Ockner wrote: > Hello again everyone! > > Please review this change which adds better error messages for > non-product flags that are now converted to Unified Logging. > > bug: https://bugs.openjdk.java.net/browse/JDK-8146632 > webrev: http://cr.openjdk.java.net/~mockner/8146632/ > > Since these options have been removed, we want still want the vm to > crash here, but now with an error message giving the correct command > line option. The new message looks like this: > > > TraceClassInitialization has been removed. Please use > -Xlog:classinit instead." > > The entire output looks like this: > > > TraceClassInitialization has been removed. Please use > -Xlog:classinit instead. > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. > > Tested with jtreg runtime tests. A new test checks for an appropriate > error message for every develop flag that has so far been converted to > logging. > > Thanks, > Max > > From rachel.protacio at oracle.com Tue Mar 15 19:46:40 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 15 Mar 2016 15:46:40 -0400 Subject: RFR (XS): 8150085: Convert TraceClearedExceptions to Unified Logging In-Reply-To: <56E766C5.3040204@oracle.com> References: <56E701AB.6060705@oracle.com> <56E766C5.3040204@oracle.com> Message-ID: <56E866A0.9000508@oracle.com> Good point. I'll fix that and commit. Thanks! Rachel On 3/14/2016 9:35 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~rprotacio/8150085.02/src/share/vm/utilities/exceptions.cpp.udiff.html > > > It looks like this could be one if statement rather than two, and > checking _pending_exception != NULL is faster than testing > log_is_enabled(). If you make this change, I don't need to see > another webrev. > > thanks, > Coleen > > > On 3/14/16 2:23 PM, Rachel Protacio wrote: >> Hi, >> >> Please review this change, converting -XX:+TraceClearedExceptions to >> -Xlog:exceptions=debug. (This change replaces the one I sent out >> earlier that was going to delete the option.) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150085 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8150085.02/ >> >> Passes JPRT; if you'd like to see additional testing, please let me >> know. >> >> Thank you, >> Rachel > From robbin.ehn at oracle.com Tue Mar 15 20:31:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Mar 2016 21:31:51 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly Message-ID: <56E87137.4080109@oracle.com> Hi, please review this enhancement. This adds support for multiple UL tags in TraceTime. Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ Tested with jprt hotspot and manually tested log output. Thanks! /Robbin From gerard.ziemski at oracle.com Tue Mar 15 20:46:42 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 15 Mar 2016 15:46:42 -0500 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E697F9.7020301@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56E697F9.7020301@oracle.com> Message-ID: <94EB6432-260A-4DA8-89A6-DA4CB717CEF7@oracle.com> hi Marcus, Sorry for getting back so late, but I got sick last Friday. > On Mar 14, 2016, at 5:52 AM, Marcus Larsson wrote: > >> >> ----------------------------------------------- >> #3 File src/share/vm/logging/log.cpp >> >> The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with: >> >> char buf[16]; >> >> and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard") > > Yeah I'm aware of this limitation. It's only used in the test though, where I'm hoping it won't be a problem. Would a comment about this be enough? It would be very unfortunate if the test failed because of some corner case involving this limitation. Since the code is not on a performance path, and only used in the test, couldn?t we use fseek(); rewind(); to find the buffer size we need, and then use NEW_C_HEAP_ARRAY() to allocate exactly as much memory as we need? cheers > Seems like a good idea to me. > > Thanks, > Marcus > >> >> >>> On Mar 11, 2016, at 8:21 AM, Marcus Larsson wrote: >>> >>> Third time's the charm. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>> >>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >>> >>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >>> >>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >>> >>> Tested with included internal VM tests through RBT. >>> >>> Thanks, >>> Marcus >>> >>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>> Hi, >>>> >>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>> Hi again, >>>>> >>>>> Taking a different approach to this. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>> >>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>> >>>>> Tested with included jtreg test through JPRT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>> >>>>>> Testing: >>>>>> Included test through JPRT >>>>>> >>>>>> Thanks, >>>>>> Marcus From david.holmes at oracle.com Tue Mar 15 21:31:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 07:31:34 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> Message-ID: <56E87F36.6070300@oracle.com> On 16/03/2016 12:14 AM, Gerard Ziemski wrote: > Thanks for fixing this. Thanks for the review. > > I do have one concern: > > #1 File src/os/solaris/vm/os_solaris.cpp > > 4425 // retrieve entry point for pthread_setname_np > 4426 Solaris::_pthread_setname_np = > 4427 (int(*)(pthread_t, const char*))dlsym(RTLD_DEFAULT, "pthread_setname_np?); > > According to ?man dlsym? RTLD_DEFAULT can be expensive, i.e.: > > "If dlsym() is called with the special handle RTLD_DEFAULT, then all mach-o images in the process (except those loaded with dlopen(xxx, > RTLD_LOCAL)) are searched in the order they were loaded. This can be a costly search and should be avoided." What platform is that for? OSX? I don't see any such warning on Solaris or Linux. But yes it does search the loaded libraries. > Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? Thanks, David > > cheers > >> On Mar 15, 2016, at 1:24 AM, David Holmes wrote: >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8151322 >> >> Webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev/ >> >> As of Solaris 11.3 pthread_set_name_np has been implemented: >> >> http://docs.oracle.com/cd/E53394_01/html/E54766/pthread-setname-np-3c.html#scrolltoc >> >> https://blogs.oracle.com/observatory/entry/named_threads >> >> So we can now implement os::set_native_thread_name using dynamic lookup as done on Linux. The only difference is we have 31 characters to play with instead of 16. >> >> Testing: - JPRT (only 11.2 systems) >> - Manually on 11.3 - see examples in bug report >> >> Thanks, >> David > From gerard.ziemski at oracle.com Tue Mar 15 21:49:34 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 15 Mar 2016 16:49:34 -0500 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E87F36.6070300@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> Message-ID: > On Mar 15, 2016, at 4:31 PM, David Holmes wrote: > >> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? > > AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. thanks From jon.masamitsu at oracle.com Tue Mar 15 22:23:41 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Mar 2016 15:23:41 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <7b553bec-baa7-447d-8b99-98980f910274@default> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> <7b553bec-baa7-447d-8b99-98980f910274@default> Message-ID: <56E88B6D.1000809@oracle.com> On 3/15/2016 6:37 AM, Fairoz Matte wrote: > Hi Jon, David, Sangheon, Kim and Thomas, > > Thanks for your review comments. > Patch is modified to incorporate the changes > @@ -1675,9 +1675,8 @@ > FLAG_SET_DEFAULT(ParallelGCThreads, > Abstract_VM_Version::parallel_worker_threads()); > if (ParallelGCThreads == 0) { > - FLAG_SET_DEFAULT(ParallelGCThreads, > - Abstract_VM_Version::parallel_worker_threads()); > - } > + vm_exit_during_initialization("The flag -XX:+UseG1GC can not be combined with -XX:ParallelGCThreads=0", NULL); > + } > > Find below is the details > Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 > Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ Looks good. Jon > > Thanks, > Fairoz > >> -----Original Message----- >> From: Jon Masamitsu >> Sent: Tuesday, March 15, 2016 12:11 AM >> To: David Holmes; sangheon; Kim Barrett >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR: 8150518: G1 GC crashes at >> G1CollectedHeap::do_collection_pause_at_safepoint(double) >> >> >> >> On 03/13/2016 11:51 PM, David Holmes wrote: >>> >>> On 14/03/2016 4:34 PM, sangheon wrote: >>>> Hi David, >>>> >>>> On 03/13/2016 05:49 PM, David Holmes wrote: >>>>> On 12/03/2016 1:44 AM, Jon Masamitsu wrote: >>>>>> >>>>>> On 3/10/2016 12:42 PM, Kim Barrett wrote: >>>>>>>> On Mar 10, 2016, at 12:21 PM, Jon Masamitsu >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 03/09/2016 08:53 PM, David Holmes wrote: >>>>>>>>> On 9/03/2016 9:33 PM, Fairoz Matte wrote: >>>>>>>>>> Background: >>>>>>>>>> >>>>>>>>>> After the backport of >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8017462, The flag >>>>>>>>>> -XX:+UseG1GC combined with -XX:ParallelGCThreads=0 makes the >>>>>>>>>> _workers to null in 8u. >>>>>>>>>> >>>>>>>>>> As there is no condition to handle such scenario in >>>>>>>>>> share/vm/memory/sharedHeap.cpp, which causes the crash. >>>>>>>>>> >>>>>>>>>> The similar condition is already implemented for following >>>>>>>>>> scenarios >>>>>>>>>> >>>>>>>>>> 1. -XX:+UseParallelGC -XX:ParallelGCThreads=0 >>>>>>>>>> >>>>>>>>>> 2. -XX:+UseParNewGC -XX:ParallelGCThreads=0 >>>>>>>>>> >>>>>>>>>> 3. -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Fix: >>>>>>>>>> >>>>>>>>>> Condition check is added in src/share/vm/runtime/arguments.cpp >>>>>>>>>> file >>>>>>>>>> to verify "-XX:+UseG1GC -XX:ParallelGCThreads=0" >>>>>>>>>> >>>>>>>>>> Thanks for the base patch from Jon. >>>>>>>>>> >>>>>>>>>> Due to this patch it makes some of the test cases absolute. >>>>>>>>>> They have been removed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8150518/webrev.00/ >>>>>>>>> This existing code looks wrong: >>>>>>>>> >>>>>>>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>>>>>>> 1677 if (ParallelGCThreads == 0) { >>>>>>>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>>>>>>> >>>>>>>>> Line 1678 seems to do the same as 1675 - is >>>>>>>>> Abstract_VM_Version::parallel_worker_threads() somehow expected >>>>>>>>> to return a different value on the second call ?? >>>>>>>> No, Abstract_VM_Version::parallel_worker_threads() won't return >> a >>>>>>>> different value for a second call. It's harmless but would be >>>>>>>> cleaner deleting 1675,1676. >>>>>> I retract this suggestion to delete 1675-1676. I'll 99.99% sure >>>>>> that it would be OK, but argument processing being what it is and >>>>>> this being an update fix, leave those lines in. I've been >>>>>> surprised before. >>>>> Okay on being conservative here. But I repeat my earlier statement: >>>>> >>>>> That aside I'm confused by the fix as we have: >>>>> >>>>> ./share/vm/runtime/globals.hpp: product(uintx, ParallelGCThreads, >>>>> 0, >>>>> >>>>> so it seems odd to report an error for setting a value that is >>>>> already the default ?? >>>> A flag's value set by default(FLAG_IS_DEFAULT) is different from set >>>> by >>>> command-line(FLAG_SET_CMDLINE) when we process that flag. >>>> Usually a flag that has a default value of '0' means 'will be >> decided >>>> ergonomically'. >>> Is this a well-defined convention? I thought that when zero means >> "use >>> the default" (ie ergonomics or whatever) that it always means that >>> regardless of whether it is set explicitly or not! >> It's not a well defined convention. It is something that happened in >> one of the GC's and then was imitated or not in others. If there is a >> code path for >> ParallelGCThreads==0 (that's not calculate me ergonomically), then >> explicit setting on the command line of ParallelGCThreads to 0 executes >> that code path. That exception has been removed in jdk9. >> >> Jon >> >> >>> Thanks, >>> David >>> >>> >>>> From above example, >>>> 1675 FLAG_SET_DEFAULT(ParallelGCThreads, >>>> 1676 Abstract_VM_Version::parallel_worker_threads()); >>>> 1677 if (ParallelGCThreads == 0) { >>>> 1678 FLAG_SET_DEFAULT(ParallelGCThreads, >>>> 1679 Abstract_VM_Version::parallel_worker_threads()); >>>> >>>> line1676, parallel_worker_threads() is checking whether the flag is >> a >>>> default value or not. >>>> And use the value if it is not 'set-by-default'. >>>> >>>> unsigned int Abstract_VM_Version::parallel_worker_threads() { >>>> if (!_parallel_worker_threads_initialized) { >>>> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>> _parallel_worker_threads = >>>> VM_Version::calc_parallel_worker_threads(); >>>> } else { >>>> _parallel_worker_threads = ParallelGCThreads; >>>> } >>>> _parallel_worker_threads_initialized = true; >>>> } >>>> return _parallel_worker_threads; >>>> } >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>>>> The retry setting to parallel_worker_threads() again code dates >>>>>>> back to the initial G1 checkin. Hard to know what was intended. >>>>>>> >>>>>>> The current jdk9 code does not have that: it looks like >>>>>>> >>>>>>> FLAG_SET_DEFAULT(ParallelGCThreads, >>>>>>> Abstract_VM_Version::parallel_worker_threads()); >>>>>>> if (ParallelGCThreads == 0) { >>>>>>> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default >>>>>>> value for ParallelGCThreads should not be 0."); >>>>>>> vm_exit_during_initialization("The flag -XX:+UseG1GC can not >>>>>>> be combined with -XX:ParallelGCThreads=0", NULL); >>>>>>> } >>>>>>> >>>>>>> This proposed change is for jdk8u-something, correct? >>>>>>> >>>>>>> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can >>>>>>> be seen above. Making use of that decision, a cleanup pass was >>>>>>> made that eliminated a whole bunch of "if (ParallelGCThreads == >> 0) >>>>>>> then pretend it's 1 or do some other special thing" code. The >>>>>>> backport of 8017462 to 8u72 (i.e. 8149347) looks like it might >> not >>>>>>> have taken that into account. For example, >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u- >> dev/hotspot/rev/6c57a16d023 >>>>>>> 8 >>>>>>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Wed >>>>>>> Feb >>>>>>> 17 13:42:03 2016 +0000 >>>>>>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Thu >>>>>>> +++ Feb >>>>>>> 18 20:30:45 2016 +0000 >>>>>>> @@ -3991,8 +3991,15 @@ >>>>>>> TraceCPUTime tcpu(G1Log::finer(), true, gclog_or_tty); >>>>>>> - uint active_workers = >>>>>>> (G1CollectedHeap::use_parallel_gc_threads() ? >>>>>>> - workers()->active_workers() : 1); >>>>>>> + uint active_workers = >>>>>>> AdaptiveSizePolicy::calc_active_workers(workers()- >>> total_workers() >>>>>>> , >>>>>>> + >>>>>>> workers()->active_workers(), >>>>>>> + >>>>>>> Threads::number_of_non_daemon_threads()); >>>>>>> >>>>>>> Note the conditionalization on use_parallel_gc_threads(). >>>>>>> >>>>>>> It might be that the simplest thing to do for 8u backporting is >>>>>>> indeed to backport prevention of ParallelGCThreads == 0, as >>>>>>> suggested in the proposed patch. >>>>>> I agree although I'll also respond to Thomas next. >>>>>> >>>>>> Jon >>>>>> >>>>>>> >>>>>>> From david.holmes at oracle.com Wed Mar 16 04:24:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 14:24:21 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> Message-ID: <56E8DFF5.608@oracle.com> cc'ing James as initial requestor for this. On 16/03/2016 7:49 AM, Gerard Ziemski wrote: > >> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >> >>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >> >> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? > > Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: https://bugs.openjdk.java.net/browse/JDK-8151953 to look at use of RTLD_DEFAULT in general. Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. Thanks, David ----- > > thanks > From david.holmes at oracle.com Wed Mar 16 05:14:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 15:14:20 +1000 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E87137.4080109@oracle.com> References: <56E87137.4080109@oracle.com> Message-ID: <56E8EBAC.3000603@oracle.com> Hi Robbin, Thanks for tackling this. :) On 16/03/2016 6:31 AM, Robbin Ehn wrote: > Hi, please review this enhancement. > > This adds support for multiple UL tags in TraceTime. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ > Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ Initial query: why do so many .cpp files now include the timerTrace.hpp file yet have no other changes? I'm still mulling over the verbosity of the new format. You may recall there was a lot of discussion about this last time round :) Thanks, David > Tested with jprt hotspot and manually tested log output. > > Thanks! > > /Robbin From david.holmes at oracle.com Wed Mar 16 05:27:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 15:27:26 +1000 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E8EBAC.3000603@oracle.com> References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com> Message-ID: <56E8EEBE.9040208@oracle.com> On 16/03/2016 3:14 PM, David Holmes wrote: > Hi Robbin, > > Thanks for tackling this. :) > > On 16/03/2016 6:31 AM, Robbin Ehn wrote: >> Hi, please review this enhancement. >> >> This adds support for multiple UL tags in TraceTime. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ > > Initial query: why do so many .cpp files now include the timerTrace.hpp > file yet have no other changes? Okay this is because they already implicitly include timer.hpp but now have to include the new timerTrace.hpp. Fair enough. Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was not put in in alphabetical order. > I'm still mulling over the verbosity of the new format. You may recall > there was a lot of discussion about this last time round :) Do we perhaps want to keep the wrapper classes in logTimer.hpp? Additional uses of TraceTime with UL can then either add their own wrappers or use the direct form you have added support for. Thanks, David > Thanks, > David > >> Tested with jprt hotspot and manually tested log output. >> >> Thanks! >> >> /Robbin From david.holmes at oracle.com Wed Mar 16 05:48:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 15:48:11 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E84A2D.30304@oracle.com> References: <56E84A2D.30304@oracle.com> Message-ID: <56E8F39B.3000402@oracle.com> Hi Max, On 16/03/2016 3:45 AM, Max Ockner wrote: > Hello again everyone! > > Please review this change which adds better error messages for > non-product flags that are now converted to Unified Logging. > > bug: https://bugs.openjdk.java.net/browse/JDK-8146632 > webrev: http://cr.openjdk.java.net/~mockner/8146632/ > > Since these options have been removed, we want still want the vm to > crash here, but now with an error message giving the correct command > line option. The new message looks like this: > > > TraceClassInitialization has been removed. Please use -Xlog:classinit > instead." > > The entire output looks like this: > > > TraceClassInitialization has been removed. Please use -Xlog:classinit > instead. > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. I'm concerned that this has introduced another variant of "flag deprecation". It begs the question as to when this new code should be removed. Maybe we need to add "replaced" as another type of flag change so we can report in 9 the flag has been replaced and then in 10 just report an "unknown option" error ? Thanks, David > Tested with jtreg runtime tests. A new test checks for an appropriate > error message for every develop flag that has so far been converted to > logging. > > Thanks, > Max > > From david.holmes at oracle.com Wed Mar 16 06:11:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 16:11:21 +1000 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E8237D.8070908@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> Message-ID: <56E8F909.9060705@oracle.com> Hi Max, tl;dr: you can push this as-is (modulo fixing copyright years) but I have some further queries/discussion points below. :) Meta question: should we consider using "classload, constraints" instead of "loaderconstraints" ? On 16/03/2016 1:00 AM, Max Ockner wrote: > Hello again, > > new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ > - added resource marks back in > - reverted to using outputStreams instead of log_info macro > > I ran into an issue with the outputStream eating its output when I > removed " ]\n" from the end of some of the messages, solved by changing > "out->print" to "out->print_cr". Aside: it is actually more efficient to have the \n in the string than to use the print_cr form. :) Nit: is there a reason to remove the initial capitals from the log messages? I find the capitals are a visual aid when trying to find the end of the decorators. Aside 2: I notice we have now removed the only example of a product_rw flag. I wonder if we should rip out product_rw support? (Separate RFE of course). I'm also wondering if our logging flags are visible/modifiable via the management tools like manageable/product_rw flags are? With regard to the test I'm not sure those "loaders" are going to continue to be valid once Jake has integrated. So you might want to try this on a Jake build before finalising it. Thanks, David > I thought about writing a log_info_rm which evaluates to a code block > instead of a function, but I think one of the benefits of the current > macros is that they allow two variable argument lists in the same > expression. Returning a write function is important for handling the > format string and its variable length argument list of format > %substitutions. > > Thanks, > Max > > > On 3/9/2016 11:29 PM, David Holmes wrote: >> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>> >>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>> >>> >>> >>> Why did you take out the ResourceMarks at line 130, 160, 231 and 244, >>> 297, 308 and 357? >> >> Yes these should all be of the form: >> >> if (log_is_enabled(...)) { >> ResourceMark rm; >> // log stuff >> } >> >>> Unfortunately, we really need log_info_rm(tag)("String") call because >>> all those places need a ResourceMark. >>> >>> Anytime we call name()->as_C_string() there needs to be a ResourceMark >>> in the scope of the call. >> >> Which means that a log_info_rm() call wouldn't help because we'd still >> be calling as_C_string in the caller. :( >> >> David >> >>> >>> Coleen >>> >>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>> Hello again, >>>> >>>> Please review this change. TraceLoaderConstraints has been converted >>>> to Unified Logging and can be accessed using >>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added >>>> to the logging alias table. >>>> >>>> There are 0 lines of output for java -version, and ~10 lines from >>>> LoaderConstraintsTest.java >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>> >>>> Testing: jtreg runtime. Added new test which triggers logging for >>>> loaderconstraints by forcing class unloading. No other references to >>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>> noncolo tests. >>>> >>>> Thanks, >>>> Max >>> > From robbin.ehn at oracle.com Wed Mar 16 06:53:52 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 16 Mar 2016 07:53:52 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E8EEBE.9040208@oracle.com> References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com> <56E8EEBE.9040208@oracle.com> Message-ID: <56E90300.1040200@oracle.com> Thanks David for looking at this! On 03/16/2016 06:27 AM, David Holmes wrote: > On 16/03/2016 3:14 PM, David Holmes wrote: >> Hi Robbin, >> >> Thanks for tackling this. :) >> >> On 16/03/2016 6:31 AM, Robbin Ehn wrote: >>> Hi, please review this enhancement. >>> >>> This adds support for multiple UL tags in TraceTime. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ >> >> Initial query: why do so many .cpp files now include the timerTrace.hpp >> file yet have no other changes? > > Okay this is because they already implicitly include timer.hpp but now > have to include the new timerTrace.hpp. Fair enough. > > Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was not > put in in alphabetical order. Thanks > >> I'm still mulling over the verbosity of the new format. You may recall >> there was a lot of discussion about this last time round :) > Yes :) It's as verbose as gcTraceTime (which might be to verbose). > Do we perhaps want to keep the wrapper classes in logTimer.hpp? > Additional uses of TraceTime with UL can then either add their own > wrappers or use the direct form you have added support for. Either way is fine by me. /Robbin > > Thanks, > David > >> Thanks, >> David >> >>> Tested with jprt hotspot and manually tested log output. >>> >>> Thanks! >>> >>> /Robbin From dmitry.dmitriev at oracle.com Wed Mar 16 08:47:52 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 16 Mar 2016 11:47:52 +0300 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E84A2D.30304@oracle.com> References: <56E84A2D.30304@oracle.com> Message-ID: <56E91DB8.1000009@oracle.com> Hi Max, If develop flag exist in removed_develop_logging_flags then flag search is performed second time. I think that is_removed_develop_logging_flag and removed_develop_logging_flag_name can be refactored. Actually, I think that we only need removed_develop_logging_flag_name function and is_removed_develop_logging_flag can be removed. E.g.: const char* Arguments::removed_develop_logging_flag_name(const char* name){ for (size_t i = 0; removed_develop_logging_flags[i].alias_name != NULL; i++) { const AliasedFlag& flag = removed_develop_logging_flags[i]; if (strcmp(flag.alias_name, name) == 0) { return flag.real_name; } } return NULL; } ... // Only make the obsolete check for valid arguments. if (arg_len <= BUFLEN) { // Construct a string which consists only of the argument name without '+', '-', or '='. char stripped_argname[BUFLEN+1]; strncpy(stripped_argname, argname, arg_len); stripped_argname[arg_len] = '\0'; // strncpy may not null terminate. const char* replacement; if (is_obsolete_flag(stripped_argname, &since)) { char version[256]; since.to_string(version, sizeof(version)); warning("Ignoring option %s; support was removed in %s", stripped_argname, version); return true; } #ifndef PRODUCT else if ((replacement = removed_develop_logging_flag_name(stripped_argname)) != NULL){ jio_fprintf(defaultStream::error_stream(), "%s has been removed. Please use %s instead.\n", stripped_argname, replacement); return false; #endif } What you think about that? Thanks, Dmitry On 15.03.2016 20:45, Max Ockner wrote: > Hello again everyone! > > Please review this change which adds better error messages for > non-product flags that are now converted to Unified Logging. > > bug: https://bugs.openjdk.java.net/browse/JDK-8146632 > webrev: http://cr.openjdk.java.net/~mockner/8146632/ > > Since these options have been removed, we want still want the vm to > crash here, but now with an error message giving the correct command > line option. The new message looks like this: > > > TraceClassInitialization has been removed. Please use > -Xlog:classinit instead." > > The entire output looks like this: > > > TraceClassInitialization has been removed. Please use > -Xlog:classinit instead. > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. > > Tested with jtreg runtime tests. A new test checks for an appropriate > error message for every develop flag that has so far been converted to > logging. > > Thanks, > Max > > From david.holmes at oracle.com Wed Mar 16 09:40:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Mar 2016 19:40:03 +1000 Subject: RFR(s): 8148425: strerror() function is not thread-safe In-Reply-To: References: <56D3BEB8.50109@oracle.com> <56D528FF.3030308@oracle.com> <56DF4BAD.1040109@oracle.com> <56E26DF5.8080300@oracle.com> <56E63348.2010607@oracle.com> <56E8009B.7070009@oracle.com> <56E8240D.5000006@oracle.com> Message-ID: <56E929F3.3090107@oracle.com> Change pushed but unfortunately I hadn't noticed the bug report had been targetted to 10 so a 9 "backport" was created. Bah! I think hgupdater needs to be a little smarter about that. David On 16/03/2016 2:02 AM, Thomas St?fe wrote: > Coleen, David, > > thank you both! > > I will do a follow up change later when there is more time. > > Kind regards, Thomas > > > > On Tue, Mar 15, 2016 at 4:02 PM, Coleen Phillimore > > wrote: > > > This looks fine to me, as-is. > > On 3/15/16 8:31 AM, David Holmes wrote: > > Hi Thomas, > > On 15/03/2016 8:07 PM, Thomas St?fe wrote: > > Hi David, > > sorry, I will have not the time to work on this this week. > If the patch > is acceptable to you in this form, I'd say we commit it, > otherwise I'll > take it up again some time later. > > > If Coleen is okay with this as-is I'll commit it in the morning. > > About the suggested changes: > > - Merging both APIs into one, like suggested, is fine for me > and I would > do this in a follow-up. > > > Sure. > > - Handling unknown errno values: I do not like the idea of a > fallback to > ::strerror(). Writing the API comment on that one would be > weird: "Is > almost threadsafe", "will probably return a static constant > string"... > :) I would suggest either using the solution as it is now - only > honouring POSIX errno values or returning "Unknown", or to > expand them > with OS specific lists, either in the OS independent form > ("#ifdef EBLUB > handle(EBLUB) #endif") or by expanding os::strerror() with > platform > dependend os::strerror_pd(). > > I am pretty unemotional about either option but would prefer > avoiding > ::strerror() altogether. > > > A follow up on this okay. I'm unsure how best to handle it. > Given how rarely we encounter errors I'm probably over-thinking > it. ;) > > > Yeah, I think you're over-thinking it. The two APIs with comments > make sense to me, and something returning Unknown isn't a big deal > in real life. > > Thanks for the change and thanks for sponsoring this, David. > > Coleen > > > Thanks, > David > > Kind Regards, Thomas > > > > On Mon, Mar 14, 2016 at 4:43 AM, David Holmes > > >> wrote: > > On 12/03/2016 6:22 PM, Thomas St?fe wrote: > > Hi David, > > thanks again for your review. Here the new version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.02/webrev/ > > And the diff to the last version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01-to-02.txt > > I fixed the indention, copyright comments and the typo. > > > All looks good - thanks. > > Further comments inline. > > > Ditto :) > > > On Fri, Mar 11, 2016 at 8:04 AM, David Holmes > > > > > >>> wrote: > > Hi Thomas, > > Thanks for persevering with this. Sorry for > the delayed > response. > > On 10/03/2016 2:58 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at this next version of > the fix. > > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.01/webrev/ > > I am the first to admit that this is quite > ugly :(, but > it is a > pragmatic solution. > > Some details: > > - I added os::strerror() as a drop-in > replacement for > ::strerror() - it > returns the text as before, but does not > localize and > does not > handle > unknown error values; so it can be > implemented using a > simple static > string table and is always safe to use. > > > Ok. But I don't think we need os::lasterror() > if we have > this. A > follow up clean-up is okay for that though. > > > I would love to keep this functionality, because I > like printing > out the > short concise errno values, and there are a number > of logging > changes > coming at least for AIX. It also does not cost > much, as the > large string > table is already there. > > If the second API does not suit you, would it be > accepable for > you if I > hide this functionality behind a second parameter > in strerror, > defaulting to false, like I did in my first > version? E.g. > os::strerror(int e, bool short_name=false); ? > > > That was what I was thinking of yes. :) > > But talking about clean-up, could we get rid of > os::lasterror() ? I > think that function is a bad idea, and it > fortunately is only > called in > two places, both just need strerror() and no Win32 > error > handling anyway. > > > Sounds good. lasterror() is a fragile API as it is too > easy to > introduce unexpected system calls between the call to > lasterror and > the action you want to check for the error. > > I also would like to remove os::get_last_error(). > It returns > errno on > *nix, win32 error on Windows. Both are different > things, plus > there is > also an errno on Windows The return value of this > function is > useless > without knowing what the returned error number > actually is, so > it is not > of much use. > > > Simplifying and streamlining all this sounds good. > > Also it does seem to handle unknown error values. > > - I added os::errno_name() for those cases > where one > would want the > literalized errno value (e.g. "EINVAL") > instead of the > full text. > > > Ok. For the unknown case can it return the > numeric value > that it was > passed? > > > I would like to avoid this. This would make the > function more > complicated. > > I'd need to keep this thread-safe, so I either > would have to > allocate > thread local storage for the return string somehow or, > alternatively, > keep a fixed string table a la [][] {"unknown (0)", > "unknown(1)"} for > the first n values or so. > > > Okay. I was thinking this would be simpler but of > course we have to > convert to a string. > > I note that linux defines ~133 errno values, and you > have entries > for ~75 - are they all the POSIX ones? > > I'm wondering whether we should have a fallback > strategy for an > unknown (platform-specific) error by using the platform > strerror > even though not thread-safe (the window of exposure is > vastly reduced) ? > > Also, ::strerror() behaves not consistently for the > EINVAL case > on all > platforms anyway - on Linux and Bsd, it returns the > numerical > value, but > on Solaris, Windows and AIX, it just returns > "Unknown". Many > callsites I > saw take this already into account and print out > the numerical errno > value in addition to the error string. > > > I doubt those callsites are not taking into account > unknown values - > I think you will find they originally only reported the > numerical > value and were then augmented to also print the > strerror message. > > Thanks, > David > > - I fixed all callsites in the hotspot > which used > ::strerror to use > os::strerror, or, in some few cases > (mostly my own > coding for AIX), > os::errno_name(). > > > Bit subjective but okay - I personally don't > care either > way. :) > > - To avoid including os.hpp in debug.hpp, > I moved the > implemntation of > assert_status to debug.cpp > > > Okay ... did the include cause a problem? > > > os.hpp is a large beast. I wanted to keep it out of > debug.hpp, > to not > force this include upon anyone who includes > debug.hpp just to get > assert(). I also try to avoid calling system apis > in header files. > > > > General minor comments: > > src/os/posix/vm/os_posix.cpp > > Indentation of wrapped call needs fixing > > > Fixed > > --- > > src/share/vm/runtime/os.hpp > > Typo: > > + // sugested in the POSIX standard. > > -> suggested > > > Fixed > > --- > > src/share/vm/utilities/vmError.cpp > > Good catch on the code that potentially > reports the wrong error > using get_last_error! Even the simple > print_cr(..., > strerror(errno), > errno) could in fact print non-matching values > if strerror > itself > caused an error (unlikely of course :) ). > > > Thanks :) > > > Please check all copyright years - > attachListener_solaris.cpp was > updated to 2015 instead of 2016 :) Also note > correct format > for two > year copyrights - in > src/share/vm/logging/logFileOutput.cpp > you have: > > Copyright (c) 2015,2016 Oracle > > but it should be: > > Copyright (c) 2015, 2016, Oracle > > Fixed > > Thanks, > David > > > Thanks! > > Thomas > > > Kind Regards, Thomas > > > > > On Tue, Mar 8, 2016 at 11:01 PM, Coleen > Phillimore > > > > > >> > > > > > > >>>> wrote: > > > This latest version seems okay (or at > least better > than the > other > workarounds). > > thanks, > Coleen > > > On 3/1/16 12:30 AM, David Holmes wrote: > > Hi Thomas, > > On 1/03/2016 3:23 AM, Thomas > St?fe wrote: > > Hi David, > > On Mon, Feb 29, 2016 at 4:44 > AM, David Holmes > > > > > >> > > > > > >>> > > > > > > >> > > > > > > > >>>>> wrote: > > Hi Thomas, > > On 27/02/2016 2:05 AM, > Thomas St?fe > wrote: > > Hi, > > please take a look > at this > proposed fix: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148425 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/ > > This adds a > replacement function > os::strerror() as > a drop-in for > strerror(), which > has a number of > issues. > > strerror() is unsafe > to use and > may cause > (and has > caused) > crashes in > multithreaded > scenarios. It is > also not > ideal for > log files > because of the > implicit > localization of the > error messages. > > For details please > see the discussion > under the bug > report. > > > I just came across > strerror_l, which is > required to be > thread-safe. > Is that a possible > alternative? (I'm > not sure how > locale's are > obtained). > > > Sorry, I think this API is > glibc only. At > least I > cannot > find this in > our AIX headers, nor on Solaris. > > > It is a POSIX API: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror_l.html > > added in 2006 but part of > POSIX.1-2008. But as per > Dalibor's > link not necessarily available: > > "This function is missing on some > platforms: glibc > 2.3.6, Mac OS > X 10.5, FreeBSD 6.0, NetBSD 5.0, > OpenBSD 3.8, > Minix > 3.1.8, AIX > 5.1, HP-UX 11, IRIX 6.5, OSF/1 > 5.1, Solaris 11 > 2011-11, > Cygwin, > mingw, MSVC 9, Interix 3.5, BeOS. " > > Pity. > > > Otherwise what you have > seems okay - > though I do > dislike having to > duplicate all that > details already > buried in > the system > headers/library. Not > sure we need to > the long > text at > the VM level - > which would simplify > things a bit. > > > I agree, I dislike this too. > Like everyone > else in this > thread. But I > think this is a pragmatic > solution. > > I am a bit stuck here - > should we really > get rid of > the long > text > feature? There are some > callsites of > strerror() in the > hotspot where > arguably the long text is > better suited: > - in assert_status() (see > debug.hpp) - > this ends up > in the > header of > error files, if this suddenly > changes to a > literalized > errno, people may > be upset > > > I added assert_status purely to > expand on what > the failing > status was :) I'm happy to see > EINVAL in that > context > rather > than "invalid argument" (or > whatever) :) > > - when failing to write a > heap dump file - see > services/heapDumper.cpp. > Which ends as printout on the > command > line, I think. > > > Maybe ... if it is an error the > user can fix. > > The safe option would be to > provide both > variants > (short and > long text). > Or, provide the safe, short > variant for > all logging > calls - when > "EINVAL" is enough, and let > users continue > to use > strerror() > for those > few cases where the long text > is needed. > > What do you think? > > > Trying to decide what makes me > least unhappy. > :) Given > you've > already done the work I guess > having long and > short > forms is okay. > > Thanks, > David > > Thanks, Thomas > > Thanks, > David > > > Please note that I > did not yet > change any call > sites, although > all call > sites in the os > namespace should > already > use the > new function. I > wanted to > see whether there > would be any > general > objections. > > Kind Regards, Thomas > > > > > > > > From bengt.rutisson at oracle.com Wed Mar 16 10:38:05 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Mar 2016 11:38:05 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E87137.4080109@oracle.com> References: <56E87137.4080109@oracle.com> Message-ID: <56E9378D.5050706@oracle.com> Hi Robbin, On 2016-03-15 21:31, Robbin Ehn wrote: > Hi, please review this enhancement. > > This adds support for multiple UL tags in TraceTime. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ > Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ I think this is fine but I just wanted to mention an alternative approach. For the GC logging I introduced a GCTraceTimerImpl class and a GCTraceTime macro. See: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146 If you do something similar the code on the call site would look like this: TraceTime(Info, safepointcleanup) timer("deflating idle monitors"); instead of this: TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info, safepointcleanup)); Your call. I just wanted to mention it. Thanks, Bengt > > Tested with jprt hotspot and manually tested log output. > > Thanks! > > /Robbin From thomas.schatzl at oracle.com Wed Mar 16 11:40:41 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Mar 2016 12:40:41 +0100 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E88B6D.1000809@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> <7b553bec-baa7-447d-8b99-98980f910274@default> <56E88B6D.1000809@oracle.com> Message-ID: <1458128441.2326.37.camel@oracle.com> Hi, On Tue, 2016-03-15 at 15:23 -0700, Jon Masamitsu wrote: > > On 3/15/2016 6:37 AM, Fairoz Matte wrote: > > Hi Jon, David, Sangheon, Kim and Thomas, > > > > Thanks for your review comments. > > Patch is modified to incorporate the changes > > @@ -1675,9 +1675,8 @@ > > FLAG_SET_DEFAULT(ParallelGCThreads, > > > > Abstract_VM_Version::parallel_worker_threads()); > > if (ParallelGCThreads == 0) { > > - FLAG_SET_DEFAULT(ParallelGCThreads, > > - > > Abstract_VM_Version::parallel_worker_threads()); > > - } > > + vm_exit_during_initialization("The flag -XX:+UseG1GC can not > > be combined with -XX:ParallelGCThreads=0", NULL); > > + } > > > > Find below is the details > > Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 > > Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ > Looks good. fine with me, but we probably need to prepare some release note about that behavioral change. Thanks, Thomas From robbin.ehn at oracle.com Wed Mar 16 12:33:41 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 16 Mar 2016 13:33:41 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp Message-ID: <56E952A5.6050708@oracle.com> Hi, please review this small change. This also change allocation methods. Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ Thanks! /Robbin From max.ockner at oracle.com Wed Mar 16 15:00:35 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 16 Mar 2016 11:00:35 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E8F909.9060705@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> Message-ID: <56E97513.40902@oracle.com> Comments below. On 3/16/2016 2:11 AM, David Holmes wrote: > Hi Max, > > tl;dr: you can push this as-is (modulo fixing copyright years) but I > have some further queries/discussion points below. :) > > Meta question: should we consider using "classload, constraints" > instead of "loaderconstraints" ? > I think this would be appropriate. > On 16/03/2016 1:00 AM, Max Ockner wrote: >> Hello again, >> >> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >> - added resource marks back in >> - reverted to using outputStreams instead of log_info macro >> >> I ran into an issue with the outputStream eating its output when I >> removed " ]\n" from the end of some of the messages, solved by changing >> "out->print" to "out->print_cr". > > Aside: it is actually more efficient to have the \n in the string than > to use the print_cr form. :) > Thanks for pointing this out. I can change it. > Nit: is there a reason to remove the initial capitals from the log > messages? I find the capitals are a visual aid when trying to find the > end of the decorators. > > Aside 2: I notice we have now removed the only example of a product_rw > flag. I wonder if we should rip out product_rw support? (Separate RFE > of course). I'm also wondering if our logging flags are > visible/modifiable via the management tools like manageable/product_rw > flags are? > From an email discussion with Marcus: "There is a DCMD to reconfigure logging during runtime. It's all baked into a single command called VM.log and it works similar to the -Xlog command, but all of the parameters are named, so -Xlog:gc:gclog.txt would be VM.log output=gclog.txt what=gc." > With regard to the test I'm not sure those "loaders" are going to > continue to be valid once Jake has integrated. So you might want to > try this on a Jake build before finalising it. > Do you think this is important to test before submitting? > Thanks, > David > >> I thought about writing a log_info_rm which evaluates to a code block >> instead of a function, but I think one of the benefits of the current >> macros is that they allow two variable argument lists in the same >> expression. Returning a write function is important for handling the >> format string and its variable length argument list of format >> %substitutions. >> >> Thanks, >> Max >> >> >> On 3/9/2016 11:29 PM, David Holmes wrote: >>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>> >>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>> >>>> >>>> >>>> >>>> Why did you take out the ResourceMarks at line 130, 160, 231 and 244, >>>> 297, 308 and 357? >>> >>> Yes these should all be of the form: >>> >>> if (log_is_enabled(...)) { >>> ResourceMark rm; >>> // log stuff >>> } >>> >>>> Unfortunately, we really need log_info_rm(tag)("String") call because >>>> all those places need a ResourceMark. >>>> >>>> Anytime we call name()->as_C_string() there needs to be a ResourceMark >>>> in the scope of the call. >>> >>> Which means that a log_info_rm() call wouldn't help because we'd still >>> be calling as_C_string in the caller. :( >>> >>> David >>> >>>> >>>> Coleen >>>> >>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>> Hello again, >>>>> >>>>> Please review this change. TraceLoaderConstraints has been converted >>>>> to Unified Logging and can be accessed using >>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added >>>>> to the logging alias table. >>>>> >>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>> LoaderConstraintsTest.java >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>> >>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>> loaderconstraints by forcing class unloading. No other references to >>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>>> noncolo tests. >>>>> >>>>> Thanks, >>>>> Max >>>> >> From kim.barrett at oracle.com Wed Mar 16 16:13:41 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Mar 2016 12:13:41 -0400 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <56E952A5.6050708@oracle.com> References: <56E952A5.6050708@oracle.com> Message-ID: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> > On Mar 16, 2016, at 8:33 AM, Robbin Ehn wrote: > > Hi, please review this small change. > > This also change allocation methods. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ > > Thanks! > > /Robbin ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp Changing this: 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging); to this: 137 char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging); New code is missing out of memory handling that was present in the old code. New code will just try to use newbuf, with bad results if the allocation failed. New code is missing ASSERT-conditionalized PrintMallocFree support that was present in the old. I don't know how important this is, given that we also have PrintMalloc. (And I have to wonder why we have both PrintMalloc (develop) and PrintMallocFree (notproduct).) ------------------------------------------------------------------------------ From varming at gmail.com Wed Mar 16 16:27:21 2016 From: varming at gmail.com (Carsten Varming) Date: Wed, 16 Mar 2016 12:27:21 -0400 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> References: <56E952A5.6050708@oracle.com> <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> Message-ID: Dear Robbin, It would be much nicer if the code was changed to call a new method in a cpp file (this is clearly a slow path) and the new method could use a bufferedStream to automatically expand the needed buffer. You would need to implement vprint on bufferedStream to make is expand when needed, but that should be doable. Carsten On Wed, Mar 16, 2016 at 12:13 PM, Kim Barrett wrote: > > On Mar 16, 2016, at 8:33 AM, Robbin Ehn wrote: > > > > Hi, please review this small change. > > > > This also change allocation methods. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ > > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ > > > > Thanks! > > > > /Robbin > > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > Changing this: > 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging); > to this: > 137 char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, > mtLogging); > > New code is missing out of memory handling that was present in the old > code. New code will just try to use newbuf, with bad results if the > allocation failed. > > New code is missing ASSERT-conditionalized PrintMallocFree support > that was present in the old. I don't know how important this is, > given that we also have PrintMalloc. (And I have to wonder why we > have both PrintMalloc (develop) and PrintMallocFree (notproduct).) > > > ------------------------------------------------------------------------------ > > From gerard.ziemski at oracle.com Wed Mar 16 16:55:12 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 16 Mar 2016 11:55:12 -0500 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> Message-ID: <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> hi all, This is rev2 of the fix incorporating feedback from Dmitry: - re-use "CommandLineFlagConstraintList::find()" Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. bug https://bugs.openjdk.java.net/browse/JDK-8142510 webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation cheers From max.ockner at oracle.com Wed Mar 16 17:39:20 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 16 Mar 2016 13:39:20 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E85AC9.9020503@oracle.com> References: <56E84A2D.30304@oracle.com> <56E85AC9.9020503@oracle.com> Message-ID: <56E99A48.6080409@oracle.com> Comments below. webrev coming soon. Thanks, Max On 3/15/2016 2:56 PM, Coleen Phillimore wrote: > > Max, > > I think this looks fine. Small nit (for which I don't need to see > another webrev). > > Can you change #endif for the end of the #ifdef PRODUCT to #endif // > PRODUCT I have made this change in arguments.cpp and arguments.hpp > > This message is so much friendlier. Oh, and the vm doesn't crash, it > just exits... I have made this change to my vocabulary. Heh.... > > Thanks! > Coleen > > On 3/15/16 1:45 PM, Max Ockner wrote: >> Hello again everyone! >> >> Please review this change which adds better error messages for >> non-product flags that are now converted to Unified Logging. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >> >> Since these options have been removed, we want still want the vm to >> crash here, but now with an error message giving the correct command >> line option. The new message looks like this: >> >> > TraceClassInitialization has been removed. Please use >> -Xlog:classinit instead." >> >> The entire output looks like this: >> >> > TraceClassInitialization has been removed. Please use >> -Xlog:classinit instead. >> > Error: Could not create the Java Virtual Machine. >> > Error: A fatal exception has occurred. Program will exit. >> >> Tested with jtreg runtime tests. A new test checks for an appropriate >> error message for every develop flag that has so far been converted >> to logging. >> >> Thanks, >> Max >> >> > From max.ockner at oracle.com Wed Mar 16 17:40:50 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 16 Mar 2016 13:40:50 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E91DB8.1000009@oracle.com> References: <56E84A2D.30304@oracle.com> <56E91DB8.1000009@oracle.com> Message-ID: <56E99AA2.90904@oracle.com> I have made this change. Thanks for your suggestion. I was hoping someone would comment on this. webrev coming soon. Max On 3/16/2016 4:47 AM, Dmitry Dmitriev wrote: > Hi Max, > > If develop flag exist in removed_develop_logging_flags then flag > search is performed second time. I think that > is_removed_develop_logging_flag and removed_develop_logging_flag_name > can be refactored. Actually, I think that we only need > removed_develop_logging_flag_name function and > is_removed_develop_logging_flag can be removed. E.g.: > const char* Arguments::removed_develop_logging_flag_name(const char* > name){ > for (size_t i = 0; removed_develop_logging_flags[i].alias_name != > NULL; i++) { > const AliasedFlag& flag = removed_develop_logging_flags[i]; > if (strcmp(flag.alias_name, name) == 0) { > return flag.real_name; > } > } > return NULL; > } > ... > // Only make the obsolete check for valid arguments. > if (arg_len <= BUFLEN) { > // Construct a string which consists only of the argument name > without '+', '-', or '='. > char stripped_argname[BUFLEN+1]; > strncpy(stripped_argname, argname, arg_len); > stripped_argname[arg_len] = '\0'; // strncpy may not null > terminate. > const char* replacement; > > if (is_obsolete_flag(stripped_argname, &since)) { > char version[256]; > since.to_string(version, sizeof(version)); > warning("Ignoring option %s; support was removed in %s", > stripped_argname, version); > return true; > } > #ifndef PRODUCT > else if ((replacement = > removed_develop_logging_flag_name(stripped_argname)) != NULL){ > jio_fprintf(defaultStream::error_stream(), > "%s has been removed. Please use %s instead.\n", > stripped_argname, replacement); > return false; > #endif > } > > What you think about that? > > Thanks, > Dmitry > > On 15.03.2016 20:45, Max Ockner wrote: >> Hello again everyone! >> >> Please review this change which adds better error messages for >> non-product flags that are now converted to Unified Logging. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >> >> Since these options have been removed, we want still want the vm to >> crash here, but now with an error message giving the correct command >> line option. The new message looks like this: >> >> > TraceClassInitialization has been removed. Please use >> -Xlog:classinit instead." >> >> The entire output looks like this: >> >> > TraceClassInitialization has been removed. Please use >> -Xlog:classinit instead. >> > Error: Could not create the Java Virtual Machine. >> > Error: A fatal exception has occurred. Program will exit. >> >> Tested with jtreg runtime tests. A new test checks for an appropriate >> error message for every develop flag that has so far been converted >> to logging. >> >> Thanks, >> Max >> >> > From jon.masamitsu at oracle.com Wed Mar 16 17:30:31 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Mar 2016 10:30:31 -0700 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <1458128441.2326.37.camel@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> <7b553bec-baa7-447d-8b99-98980f910274@default> <56E88B6D.1000809@oracle.com> <1458128441.2326.37.camel@oracle.com> Message-ID: <56E99837.3010706@oracle.com> On 03/16/2016 04:40 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2016-03-15 at 15:23 -0700, Jon Masamitsu wrote: >> On 3/15/2016 6:37 AM, Fairoz Matte wrote: >>> Hi Jon, David, Sangheon, Kim and Thomas, >>> >>> Thanks for your review comments. >>> Patch is modified to incorporate the changes >>> @@ -1675,9 +1675,8 @@ >>> FLAG_SET_DEFAULT(ParallelGCThreads, >>> >>> Abstract_VM_Version::parallel_worker_threads()); >>> if (ParallelGCThreads == 0) { >>> - FLAG_SET_DEFAULT(ParallelGCThreads, >>> - >>> Abstract_VM_Version::parallel_worker_threads()); >>> - } >>> + vm_exit_during_initialization("The flag -XX:+UseG1GC can not >>> be combined with -XX:ParallelGCThreads=0", NULL); >>> + } >>> >>> Find below is the details >>> Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 >>> Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ >> Looks good. > fine with me, but we probably need to prepare some release note about > that behavioral change. I added the label release-note=yes and the comment > For release notes > > With UseG1GC specifying -XX:ParallelGCThreads=0 is no longer allowed. > Previously with -XX:ParallelGCThreads=0 G1 would execute some tasks > using serial code executed by the VM thread. The closest approximation > to this behavior is to specify -XX:ParallelGCThreads=1 which will > cause parallel tasks to be executed by a single GC worker thread using > parallel code. Please feel free to edit that comment. Jon > > Thanks, > Thomas From max.ockner at oracle.com Wed Mar 16 18:05:59 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 16 Mar 2016 14:05:59 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E8F39B.3000402@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> Message-ID: <56E9A087.8010101@oracle.com> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ - Labeled #endif with // PRODUCT - refactored table lookup code to only do lookup once. - Added VerboseVerification to the table. Comments below. On 3/16/2016 1:48 AM, David Holmes wrote: > Hi Max, > > On 16/03/2016 3:45 AM, Max Ockner wrote: >> Hello again everyone! >> >> Please review this change which adds better error messages for >> non-product flags that are now converted to Unified Logging. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >> >> Since these options have been removed, we want still want the vm to >> crash here, but now with an error message giving the correct command >> line option. The new message looks like this: >> >> > TraceClassInitialization has been removed. Please use -Xlog:classinit >> instead." >> >> The entire output looks like this: >> >> > TraceClassInitialization has been removed. Please use -Xlog:classinit >> instead. >> > Error: Could not create the Java Virtual Machine. >> > Error: A fatal exception has occurred. Program will exit. > > I'm concerned that this has introduced another variant of "flag > deprecation". It begs the question as to when this new code should be > removed. Maybe we need to add "replaced" as another type of flag > change so we can report in 9 the flag has been replaced and then in 10 > just report an "unknown option" error ? > > Thanks, > David > Seems appropriate to report a specific error message for 9 and then remove it for 10. If it would help, we can store a Version in the table to keep track of when each entry needs to be deleted, like what is done in the table of obsolete flags. >> Tested with jtreg runtime tests. A new test checks for an appropriate >> error message for every develop flag that has so far been converted to >> logging. >> >> Thanks, >> Max >> >> From dmitry.dmitriev at oracle.com Wed Mar 16 18:27:47 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 16 Mar 2016 21:27:47 +0300 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9A087.8010101@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> Message-ID: <56E9A5A3.4040901@oracle.com> Hi Max, Thank you for the refactoring. Unfortunately in my suggestion I missed that 'replacement' variable is used only in non-product build and for product build it will be an unused variable. Sorry about that. We need to handle this somehow - surround it with '#ifdef PRODUCT'(but this will add more ifdefs...) or refactor 'else' branch. Dmitry On 16.03.2016 21:05, Max Ockner wrote: > webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ > - Labeled #endif with // PRODUCT > - refactored table lookup code to only do lookup once. > - Added VerboseVerification to the table. > > Comments below. > > On 3/16/2016 1:48 AM, David Holmes wrote: >> Hi Max, >> >> On 16/03/2016 3:45 AM, Max Ockner wrote: >>> Hello again everyone! >>> >>> Please review this change which adds better error messages for >>> non-product flags that are now converted to Unified Logging. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>> >>> Since these options have been removed, we want still want the vm to >>> crash here, but now with an error message giving the correct command >>> line option. The new message looks like this: >>> >>> > TraceClassInitialization has been removed. Please use >>> -Xlog:classinit >>> instead." >>> >>> The entire output looks like this: >>> >>> > TraceClassInitialization has been removed. Please use >>> -Xlog:classinit >>> instead. >>> > Error: Could not create the Java Virtual Machine. >>> > Error: A fatal exception has occurred. Program will exit. >> >> I'm concerned that this has introduced another variant of "flag >> deprecation". It begs the question as to when this new code should be >> removed. Maybe we need to add "replaced" as another type of flag >> change so we can report in 9 the flag has been replaced and then in >> 10 just report an "unknown option" error ? >> >> Thanks, >> David >> > Seems appropriate to report a specific error message for 9 and then > remove it for 10. If it would help, we can store a Version in the > table to keep track of when each entry needs to be deleted, like what > is done in the table of obsolete flags. >>> Tested with jtreg runtime tests. A new test checks for an appropriate >>> error message for every develop flag that has so far been converted to >>> logging. >>> >>> Thanks, >>> Max >>> >>> > From harold.seigel at oracle.com Wed Mar 16 19:03:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 16 Mar 2016 15:03:53 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9A087.8010101@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> Message-ID: <56E9AE19.7040302@oracle.com> Hi Max, Looks good. Thanks for adding VerboseVerification. One nit, you may want to move the declaration of "const char* replacement;" so that it is under the #ifndef PRODUCT, perhaps like this? 1224 #ifndef PRODUCT 1225 else { const char* replacement; if ((replacement = removed_develop_logging_flag_name(stripped_argname)) != NULL){ 1226 jio_fprintf(defaultStream::error_stream(), 1227 "%s has been removed. Please use %s instead.\n", stripped_argname, replacement); 1228 return false; } } 1229 #endif Thanks, Harold On 3/16/2016 2:05 PM, Max Ockner wrote: > webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ > - Labeled #endif with // PRODUCT > - refactored table lookup code to only do lookup once. > - Added VerboseVerification to the table. > > Comments below. > > On 3/16/2016 1:48 AM, David Holmes wrote: >> Hi Max, >> >> On 16/03/2016 3:45 AM, Max Ockner wrote: >>> Hello again everyone! >>> >>> Please review this change which adds better error messages for >>> non-product flags that are now converted to Unified Logging. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>> >>> Since these options have been removed, we want still want the vm to >>> crash here, but now with an error message giving the correct command >>> line option. The new message looks like this: >>> >>> > TraceClassInitialization has been removed. Please use >>> -Xlog:classinit >>> instead." >>> >>> The entire output looks like this: >>> >>> > TraceClassInitialization has been removed. Please use >>> -Xlog:classinit >>> instead. >>> > Error: Could not create the Java Virtual Machine. >>> > Error: A fatal exception has occurred. Program will exit. >> >> I'm concerned that this has introduced another variant of "flag >> deprecation". It begs the question as to when this new code should be >> removed. Maybe we need to add "replaced" as another type of flag >> change so we can report in 9 the flag has been replaced and then in >> 10 just report an "unknown option" error ? >> >> Thanks, >> David >> > Seems appropriate to report a specific error message for 9 and then > remove it for 10. If it would help, we can store a Version in the > table to keep track of when each entry needs to be deleted, like what > is done in the table of obsolete flags. >>> Tested with jtreg runtime tests. A new test checks for an appropriate >>> error message for every develop flag that has so far been converted to >>> logging. >>> >>> Thanks, >>> Max >>> >>> > From max.ockner at oracle.com Wed Mar 16 19:04:54 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 16 Mar 2016 15:04:54 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9A4EB.20402@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> Message-ID: <56E9AE56.7050500@oracle.com> I did, but it blended in with the rest of the text My response: "Seems appropriate to report a specific error message for 9 and then remove it for 10. If it would help, we can store a Version in the table to keep track of when each entry needs to be deleted, like what is done in the table of obsolete flags. " On 3/16/2016 2:24 PM, Coleen Phillimore wrote: > > You should also answer David's concern. > Coleen > > On 3/16/16 2:05 PM, Max Ockner wrote: >> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >> - Labeled #endif with // PRODUCT >> - refactored table lookup code to only do lookup once. >> - Added VerboseVerification to the table. >> >> Comments below. >> >> On 3/16/2016 1:48 AM, David Holmes wrote: >>> Hi Max, >>> >>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>> Hello again everyone! >>>> >>>> Please review this change which adds better error messages for >>>> non-product flags that are now converted to Unified Logging. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>> >>>> Since these options have been removed, we want still want the vm to >>>> crash here, but now with an error message giving the correct command >>>> line option. The new message looks like this: >>>> >>>> > TraceClassInitialization has been removed. Please use >>>> -Xlog:classinit >>>> instead." >>>> >>>> The entire output looks like this: >>>> >>>> > TraceClassInitialization has been removed. Please use >>>> -Xlog:classinit >>>> instead. >>>> > Error: Could not create the Java Virtual Machine. >>>> > Error: A fatal exception has occurred. Program will exit. >>> >>> I'm concerned that this has introduced another variant of "flag >>> deprecation". It begs the question as to when this new code should >>> be removed. Maybe we need to add "replaced" as another type of flag >>> change so we can report in 9 the flag has been replaced and then in >>> 10 just report an "unknown option" error ? >>> >>> Thanks, >>> David >>> >> Seems appropriate to report a specific error message for 9 and then >> remove it for 10. If it would help, we can store a Version in the >> table to keep track of when each entry needs to be deleted, like what >> is done in the table of obsolete flags. >>>> Tested with jtreg runtime tests. A new test checks for an appropriate >>>> error message for every develop flag that has so far been converted to >>>> logging. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> > From harold.seigel at oracle.com Wed Mar 16 19:17:11 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 16 Mar 2016 15:17:11 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9AE19.7040302@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9AE19.7040302@oracle.com> Message-ID: <56E9B137.6050909@oracle.com> Better formatting: #ifndef PRODUCT else { const char* replacement; if ((replacement = removed_develop_logging_flag_name(stripped_argname)) != NULL) { jio_fprintf(defaultStream::error_stream(), "%s has been removed. Please use %s instead.\n", stripped_argname, replacement); return false; } } #endif On 3/16/2016 3:03 PM, harold seigel wrote: > Hi Max, > > Looks good. Thanks for adding VerboseVerification. > > One nit, you may want to move the declaration of "const char* > replacement;" so that it is under the #ifndef PRODUCT, perhaps like this? > > 1224 #ifndef PRODUCT > 1225 else { const char* replacement; if ((replacement = > removed_develop_logging_flag_name(stripped_argname)) != NULL){ > 1226 jio_fprintf(defaultStream::error_stream(), > 1227 "%s has been removed. Please use %s instead.\n", > stripped_argname, replacement); > 1228 return false; } } 1229 #endif > > > Thanks, Harold > > On 3/16/2016 2:05 PM, Max Ockner wrote: >> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >> - Labeled #endif with // PRODUCT >> - refactored table lookup code to only do lookup once. >> - Added VerboseVerification to the table. >> >> Comments below. >> >> On 3/16/2016 1:48 AM, David Holmes wrote: >>> Hi Max, >>> >>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>> Hello again everyone! >>>> >>>> Please review this change which adds better error messages for >>>> non-product flags that are now converted to Unified Logging. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>> >>>> Since these options have been removed, we want still want the vm to >>>> crash here, but now with an error message giving the correct command >>>> line option. The new message looks like this: >>>> >>>> > TraceClassInitialization has been removed. Please use >>>> -Xlog:classinit >>>> instead." >>>> >>>> The entire output looks like this: >>>> >>>> > TraceClassInitialization has been removed. Please use >>>> -Xlog:classinit >>>> instead. >>>> > Error: Could not create the Java Virtual Machine. >>>> > Error: A fatal exception has occurred. Program will exit. >>> >>> I'm concerned that this has introduced another variant of "flag >>> deprecation". It begs the question as to when this new code should >>> be removed. Maybe we need to add "replaced" as another type of flag >>> change so we can report in 9 the flag has been replaced and then in >>> 10 just report an "unknown option" error ? >>> >>> Thanks, >>> David >>> >> Seems appropriate to report a specific error message for 9 and then >> remove it for 10. If it would help, we can store a Version in the >> table to keep track of when each entry needs to be deleted, like what >> is done in the table of obsolete flags. >>>> Tested with jtreg runtime tests. A new test checks for an appropriate >>>> error message for every develop flag that has so far been converted to >>>> logging. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> > From coleen.phillimore at oracle.com Wed Mar 16 19:20:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Mar 2016 15:20:24 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9AE56.7050500@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> Message-ID: <56E9B1F8.3040800@oracle.com> Okay, I didn't see your reply. I also thought that storing a version in the table might be helpful for documentation purposes so we know in the future when to remove the line from the table. I agree with your implementation choice to have an additional table rather than twisting the other table to cover this use case. http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html I think Harold's refactoring makes sense and I think the #endif // PRODUCT } *+ #ifndef PRODUCT* *+ else if ((replacement = removed_develop_logging_flag_name(stripped_argname)) != NULL){* *+ jio_fprintf(defaultStream::error_stream(),* *+ "%s has been removed. Please use %s instead.\n", stripped_argname, replacement);* *+ return false;* *+ #endif* *+ }* I think this should be like this so the {} match inside of #ifndef PRODUCT: *+ #ifndef PRODUCT* *+ } else if ((replacement = removed_develop_logging_flag_name(stripped_argname)) != NULL) {* *+ jio_fprintf(defaultStream::error_stream(),* *+ "%s has been removed. Please use %s instead.\n", stripped_argname, replacement);* *+ return false;* *+ #endif* *+ }* Or refactor as Harold suggested. Coleen On 3/16/16 3:04 PM, Max Ockner wrote: > I did, but it blended in with the rest of the text > > My response: "Seems appropriate to report a specific error message for > 9 and then remove it for 10. If it would help, we can store a Version > in the table to keep track of when each entry needs to be deleted, > like what is done in the table of obsolete flags. " > > > On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >> >> You should also answer David's concern. >> Coleen >> >> On 3/16/16 2:05 PM, Max Ockner wrote: >>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>> - Labeled #endif with // PRODUCT >>> - refactored table lookup code to only do lookup once. >>> - Added VerboseVerification to the table. >>> >>> Comments below. >>> >>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>> Hi Max, >>>> >>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>> Hello again everyone! >>>>> >>>>> Please review this change which adds better error messages for >>>>> non-product flags that are now converted to Unified Logging. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>> >>>>> Since these options have been removed, we want still want the vm to >>>>> crash here, but now with an error message giving the correct command >>>>> line option. The new message looks like this: >>>>> >>>>> > TraceClassInitialization has been removed. Please use >>>>> -Xlog:classinit >>>>> instead." >>>>> >>>>> The entire output looks like this: >>>>> >>>>> > TraceClassInitialization has been removed. Please use >>>>> -Xlog:classinit >>>>> instead. >>>>> > Error: Could not create the Java Virtual Machine. >>>>> > Error: A fatal exception has occurred. Program will exit. >>>> >>>> I'm concerned that this has introduced another variant of "flag >>>> deprecation". It begs the question as to when this new code should >>>> be removed. Maybe we need to add "replaced" as another type of flag >>>> change so we can report in 9 the flag has been replaced and then in >>>> 10 just report an "unknown option" error ? >>>> >>>> Thanks, >>>> David >>>> >>> Seems appropriate to report a specific error message for 9 and then >>> remove it for 10. If it would help, we can store a Version in the >>> table to keep track of when each entry needs to be deleted, like >>> what is done in the table of obsolete flags. >>>>> Tested with jtreg runtime tests. A new test checks for an appropriate >>>>> error message for every develop flag that has so far been >>>>> converted to >>>>> logging. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>> >> > From david.holmes at oracle.com Wed Mar 16 21:09:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Mar 2016 07:09:34 +1000 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E97513.40902@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> <56E97513.40902@oracle.com> Message-ID: <56E9CB8E.6000109@oracle.com> Follow ups below ... On 17/03/2016 1:00 AM, Max Ockner wrote: > Comments below. > > On 3/16/2016 2:11 AM, David Holmes wrote: >> Hi Max, >> >> tl;dr: you can push this as-is (modulo fixing copyright years) but I >> have some further queries/discussion points below. :) >> >> Meta question: should we consider using "classload, constraints" >> instead of "loaderconstraints" ? >> > I think this would be appropriate. Ok. >> On 16/03/2016 1:00 AM, Max Ockner wrote: >>> Hello again, >>> >>> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >>> - added resource marks back in >>> - reverted to using outputStreams instead of log_info macro >>> >>> I ran into an issue with the outputStream eating its output when I >>> removed " ]\n" from the end of some of the messages, solved by changing >>> "out->print" to "out->print_cr". >> >> Aside: it is actually more efficient to have the \n in the string than >> to use the print_cr form. :) >> > Thanks for pointing this out. I can change it. It was just an observation - we don't pay this much attention elsewhere. >> Nit: is there a reason to remove the initial capitals from the log >> messages? I find the capitals are a visual aid when trying to find the >> end of the decorators. >> >> Aside 2: I notice we have now removed the only example of a product_rw >> flag. I wonder if we should rip out product_rw support? (Separate RFE >> of course). I'm also wondering if our logging flags are >> visible/modifiable via the management tools like manageable/product_rw >> flags are? >> > From an email discussion with Marcus: > "There is a DCMD to reconfigure logging during runtime. It's all baked > into a single command called VM.log and it works similar to the -Xlog > command, but all of the parameters are named, so -Xlog:gc:gclog.txt > would be VM.log output=gclog.txt what=gc." Thanks. >> With regard to the test I'm not sure those "loaders" are going to >> continue to be valid once Jake has integrated. So you might want to >> try this on a Jake build before finalising it. >> > > Do you think this is important to test before submitting? It might stop working next week so yes I think it worth checking this now. Thanks, David >> Thanks, >> David >> >>> I thought about writing a log_info_rm which evaluates to a code block >>> instead of a function, but I think one of the benefits of the current >>> macros is that they allow two variable argument lists in the same >>> expression. Returning a write function is important for handling the >>> format string and its variable length argument list of format >>> %substitutions. >>> >>> Thanks, >>> Max >>> >>> >>> On 3/9/2016 11:29 PM, David Holmes wrote: >>>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>>> >>>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>>> >>>>> >>>>> >>>>> >>>>> Why did you take out the ResourceMarks at line 130, 160, 231 and 244, >>>>> 297, 308 and 357? >>>> >>>> Yes these should all be of the form: >>>> >>>> if (log_is_enabled(...)) { >>>> ResourceMark rm; >>>> // log stuff >>>> } >>>> >>>>> Unfortunately, we really need log_info_rm(tag)("String") call because >>>>> all those places need a ResourceMark. >>>>> >>>>> Anytime we call name()->as_C_string() there needs to be a ResourceMark >>>>> in the scope of the call. >>>> >>>> Which means that a log_info_rm() call wouldn't help because we'd still >>>> be calling as_C_string in the caller. :( >>>> >>>> David >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>>> Hello again, >>>>>> >>>>>> Please review this change. TraceLoaderConstraints has been converted >>>>>> to Unified Logging and can be accessed using >>>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been added >>>>>> to the logging alias table. >>>>>> >>>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>>> LoaderConstraintsTest.java >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>>> >>>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>>> loaderconstraints by forcing class unloading. No other references to >>>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>>>> noncolo tests. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>> >>> > From rachel.protacio at oracle.com Wed Mar 16 21:10:13 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 16 Mar 2016 17:10:13 -0400 Subject: RFR (XS): 8151560: Message-ID: <56E9CBB5.8000008@oracle.com> Hi, Please review this fix for safepoint logging. The original conversion accidentally put a "debug" stream where a "trace" stream should have been. Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ Passes JPRT. Thanks, Rachel From harold.seigel at oracle.com Wed Mar 16 21:11:40 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 16 Mar 2016 17:11:40 -0400 Subject: RFR (XS): 8151560: In-Reply-To: <56E9CBB5.8000008@oracle.com> References: <56E9CBB5.8000008@oracle.com> Message-ID: <56E9CC0C.2060205@oracle.com> Change looks good! Harold On 3/16/2016 5:10 PM, Rachel Protacio wrote: > Hi, > > Please review this fix for safepoint logging. The original conversion > accidentally put a "debug" stream where a "trace" stream should have > been. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ > > Passes JPRT. > > Thanks, > Rachel From jiangli.zhou at oracle.com Wed Mar 16 21:21:34 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 16 Mar 2016 14:21:34 -0700 Subject: RFR (XS): 8151560: In-Reply-To: <56E9CC0C.2060205@oracle.com> References: <56E9CBB5.8000008@oracle.com> <56E9CC0C.2060205@oracle.com> Message-ID: <5255F37C-4402-4B31-BC32-9B0DE0395385@oracle.com> +1 Thanks, Jiangli > On Mar 16, 2016, at 2:11 PM, harold seigel wrote: > > Change looks good! > > Harold > > On 3/16/2016 5:10 PM, Rachel Protacio wrote: >> Hi, >> >> Please review this fix for safepoint logging. The original conversion accidentally put a "debug" stream where a "trace" stream should have been. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ >> >> Passes JPRT. >> >> Thanks, >> Rachel > From rachel.protacio at oracle.com Wed Mar 16 21:25:39 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 16 Mar 2016 17:25:39 -0400 Subject: RFR (XS): 8151560: Safepoint logging has mismatch between command line level and printed level In-Reply-To: <5255F37C-4402-4B31-BC32-9B0DE0395385@oracle.com> References: <56E9CBB5.8000008@oracle.com> <56E9CC0C.2060205@oracle.com> <5255F37C-4402-4B31-BC32-9B0DE0395385@oracle.com> Message-ID: <56E9CF53.8040100@oracle.com> Thanks, Harold and Jiangli! Rachel On 3/16/2016 5:21 PM, Jiangli Zhou wrote: > +1 > > Thanks, > Jiangli > >> On Mar 16, 2016, at 2:11 PM, harold seigel wrote: >> >> Change looks good! >> >> Harold >> >> On 3/16/2016 5:10 PM, Rachel Protacio wrote: >>> Hi, >>> >>> Please review this fix for safepoint logging. The original conversion accidentally put a "debug" stream where a "trace" stream should have been. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ >>> >>> Passes JPRT. >>> >>> Thanks, >>> Rachel From david.holmes at oracle.com Wed Mar 16 22:25:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Mar 2016 08:25:00 +1000 Subject: RFR (XS): 8151560: Safepoint logging has mismatch between command line level and printed level In-Reply-To: <56E9CF53.8040100@oracle.com> References: <56E9CBB5.8000008@oracle.com> <56E9CC0C.2060205@oracle.com> <5255F37C-4402-4B31-BC32-9B0DE0395385@oracle.com> <56E9CF53.8040100@oracle.com> Message-ID: <56E9DD3C.8050500@oracle.com> +1 from me :) David On 17/03/2016 7:25 AM, Rachel Protacio wrote: > Thanks, Harold and Jiangli! > Rachel > > On 3/16/2016 5:21 PM, Jiangli Zhou wrote: >> +1 >> >> Thanks, >> Jiangli >> >>> On Mar 16, 2016, at 2:11 PM, harold seigel >>> wrote: >>> >>> Change looks good! >>> >>> Harold >>> >>> On 3/16/2016 5:10 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Please review this fix for safepoint logging. The original >>>> conversion accidentally put a "debug" stream where a "trace" stream >>>> should have been. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ >>>> >>>> Passes JPRT. >>>> >>>> Thanks, >>>> Rachel > From david.holmes at oracle.com Thu Mar 17 01:43:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Mar 2016 11:43:41 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E9E417.3020503@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <56E9E417.3020503@oracle.com> Message-ID: <56EA0BCD.4080106@oracle.com> Hi James, On 17/03/2016 8:54 AM, james cheng wrote: > Hi David, > > Thanks for implementing this RFE. > > A Solaris Linker guru suggested what we do something like this: > > my_pthread_setname_np(...) > { > static (*fptr)() = NULL; > void *handle; > > if ((fptr == NULL) && > ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) && > ((fptr = dlsym(handle, "pthread_setname_np")) == NULL)) > fptr = noop_setname; > > (*fptr)(...); > } > > So using libc.so.1 without a path should be okay. But I don't see you have > a null check for the return of dlsym(). We initialize _pthread_setname_np using dlopen+dlsym as above at VM startup - we don't want to do the lookup on each use. The NULL check happens in the actual os::set_native_thread_name() function. Glad to hear using the libc.so.1 path is okay (as we already use it) but was wondering if we can assume /usr/lib/libc.so.1 and so shorten the search time even further? Thanks, David > > Thanks, > -James > > On 3/15/2016 9:24 PM, David Holmes wrote: >> cc'ing James as initial requestor for this. >> >> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>> >>>> On Mar 15, 2016, at 4:31 PM, David Holmes >>>> wrote: >>>> >>>>> Couldn?t we look it up on as needed basis in the implementation of >>>>> "void os::set_native_thread_name(const char *name)? instead? >>>> >>>> AFAIK we never lookup anything as-needed but always handle it at VM >>>> initialization time. A quick grep will show that we are using >>>> RTLD_DEFAULT in a few places across >>>> different platforms. Elsewhere we know what library we have to >>>> search. I can try finding out which library it should be if you >>>> think that is preferable? >>> >>> Sure, either that or we find out the performance impact on the >>> startup time, so then we can decide if it?s an issue or not. >> >> Some numbers in the bug report. It seems to me if we know the library >> that will contain the symbol then we should just open it. I filed a RFE: >> >> https://bugs.openjdk.java.net/browse/JDK-8151953 >> >> to look at use of RTLD_DEFAULT in general. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >> >> Not 100% sure whether dlopen should be also relying on the search path >> dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 >> should be hard-wired? I'm not >> familiar enough with solaris library management to know whether we >> will always find libc on that exact path? We have one existing >> /usr/lib/libc.so.1 dlopen on Solaris x86, >> but most dlopens just take the base name. >> >> Thanks, >> David >> ----- >> >>> >>> thanks >>> From coleen.phillimore at oracle.com Thu Mar 17 02:03:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Mar 2016 22:03:32 -0400 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E8EEBE.9040208@oracle.com> References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com> <56E8EEBE.9040208@oracle.com> Message-ID: <56EA1074.1070605@oracle.com> On 3/16/16 1:27 AM, David Holmes wrote: > On 16/03/2016 3:14 PM, David Holmes wrote: >> Hi Robbin, >> >> Thanks for tackling this. :) >> >> On 16/03/2016 6:31 AM, Robbin Ehn wrote: >>> Hi, please review this enhancement. >>> >>> This adds support for multiple UL tags in TraceTime. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ >> >> Initial query: why do so many .cpp files now include the timerTrace.hpp >> file yet have no other changes? > > Okay this is because they already implicitly include timer.hpp but now > have to include the new timerTrace.hpp. Fair enough. Now I see why also. > > Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was > not put in in alphabetical order. > >> I'm still mulling over the verbosity of the new format. You may recall >> there was a lot of discussion about this last time round :) > > Do we perhaps want to keep the wrapper classes in logTimer.hpp? > Additional uses of TraceTime with UL can then either add their own > wrappers or use the direct form you have added support for. > I think this looks good. The verbosity is far less than I thought it would be and having a macro TRACETIME_LOG is a good indication that something strange and macro-y is going on. Another clever use of templates and macros here, but fine at the call sites. thank you for fixing this. Coleen > Thanks, > David > >> Thanks, >> David >> >>> Tested with jprt hotspot and manually tested log output. >>> >>> Thanks! >>> >>> /Robbin From calvin.cheung at oracle.com Thu Mar 17 05:36:42 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 16 Mar 2016 22:36:42 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56CF41F5.7010206@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> Message-ID: <56EA426A.4010608@oracle.com> Dean, Ioi, Thanks for the review and discussions. Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ Changes in this webrev: - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. Testing: JPRT with testset hotspot jtreg tests under hotspot/runtime on all platforms thanks, Calvin p.s. I corrected the bug id in the subject line from 8145521 to 8145221 On 2/25/16, 10:03 AM, Ioi Lam wrote: > > > On 2/22/16 12:50 PM, Dean Long wrote: >> Hi Ioi, comments inlined below. >> >> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>> Hi Dean, >>> >>> Thanks for raising this issue. >>> >>> My first impression is this probably shouldn't matter (or somehow we >>> can get away with this). >>> >>> Today, the CDS archive already contains executable code in the "misc >>> code" section. On Linux/x64, this is typically in the address range >>> 0x802400000-0x802409000. The code is used to dynamically patch the >>> C++ vtables of Metadata types that are stored in the CDS archive. So >>> even today, there's a chance that the suspended PC lands in this >>> section. >>> >> >> OK, so you're saying that the trampolines don't make things any worse >> :-) > > Well, theoretically the i2i and c2i entries would be executed more > frequently than the vtable patching code, so if there was a problem, > it could be aggravated. >> >>> The code is generated inside >>> MetaspaceShared::generate_vtable_methods and looks like this when >>> you run with -Xshare:on: >>> >>> (gdb) x/5i 0x802400000 >>> 0x802400000: mov $0x0,%eax >>> 0x802400005: jmpq 0x8024084d0 >>> 0x80240000a: mov $0x1,%eax >>> 0x80240000f: jmpq 0x8024084d0 >>> 0x802400014: mov $0x2,%eax >>> .... >>> (gdb) x/16i 0x8024084d0 >>> 0x8024084d0: push %rsi >>> 0x8024084d1: push %rdi >>> 0x8024084d2: mov %rax,%rdi >>> 0x8024084d5: shr $0x8,%rdi >>> 0x8024084d9: shl $0x3,%rdi >>> 0x8024084dd: movabs $0x802000000,%rsi >>> 0x8024084e7: add %rdi,%rsi >>> 0x8024084ea: mov (%rsi),%rsi >>> 0x8024084ed: pop %rdi >>> 0x8024084ee: mov %rsi,(%rdi) >>> 0x8024084f1: and $0xff,%rax >>> 0x8024084f8: shl $0x3,%rax >>> 0x8024084fc: add %rsi,%rax >>> 0x8024084ff: pop %rsi >>> 0x802408500: mov (%rax),%rax >>> 0x802408503: jmpq *%rax >>> >>> In JDK9, the profiler takes a sample by first calling into >>> JavaThread::pd_get_top_frame_for_profiling: >>> >>> (gdb) where >>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>> ucontext=0x7ffec6287d00, isInJava=true) >>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling >>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>> isInJava=true) >>> >>> I tried manually setting frame::_pc to 0x802400000, and it would >>> cause frame::safe_for_sender() to return false, and thus would >>> prevent the profiler from doing any stack walking. >>> >> >> Was the reason safe_for_sender() failed something that we can rely on >> 100%? I looked at safe_for_sender, and it's not obvious why it would >> fail, unless the frame pointer was invalid, and I think that depends >> on the platform and flags like PreserveFramePointer. How about >> filing a separate bug to track this issue? >> > > OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 > to track this. > > Thanks > - Ioi > >> dl >> >>> Also, both the CDS vtable patching code and the i2i trampolines are >>> tail calls, so you will never find a PC in them except for the >>> top-most frame. This means the check in JavaThread::pd_get_top_frame >>> is enough. There's no need to do additional checks after we have >>> started stack walking. >>> >>> I think the chance of landing in the CDS vtable patching methods, or >>> in the trampolines, is pretty small, so that shouldn't bother the >>> sampling profiler too much. >>> >>> Anyway, as part of this bug, we should add a regression test with >>> the profiler enabled, and keep calling a method in the CDS archive >>> in a tight loop (and manually disable compilation of that method >>> using command-line options). The test should never crash, and if >>> possible, it should also check that we don't have too many "unknown" >>> samples. >>> >>> Thanks >>> - Ioi >>> >>> >>> On 2/19/16 4:39 PM, Dean Long wrote: >>>> We have profiling code that will suspend a thread at random points >>>> and try to walk the stack. >>>> I think frame::sender() will get confused if you happen to catch a >>>> thread in the trampoline, >>>> and frame::_pc is in metadata and not the code cache. >>>> >>>> dl >>>> >>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>> >>>>> This optimization reduces the size of the RW region of the CDS >>>>> archive. It also reduces the amount of pages in the RW region that >>>>> are actually written into during runtime. >>>>> >>>>> The original prototype on the x86_64 platform was done by Ioi >>>>> (ioi.lam at oracle.com). >>>>> I helped porting it to other platforms. >>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided >>>>> the changes to the ppc platform. >>>>> >>>>> Testing: >>>>> JPRT with testset hotspot >>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>> built on the Zero platform >>>>> tested on the openjdk aarch64 platform >>>>> refworkload on various platform (please refer to bug report >>>>> for data) >>>>> >>>>> thanks, >>>>> Calvin >>>> >>> >> > From robbin.ehn at oracle.com Thu Mar 17 06:33:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 17 Mar 2016 07:33:51 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: References: <56E952A5.6050708@oracle.com> <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> Message-ID: <56EA4FCF.60107@oracle.com> Hi Carsten, thanks for looking at this. On 03/16/2016 05:27 PM, Carsten Varming wrote: > Dear Robbin, > > It would be much nicer if the code was changed to call a new method in a > cpp file (this is clearly a slow path) and the new method could use a This is a template class. > bufferedStream to automatically expand the needed buffer. You would need > to implement vprint on bufferedStream to make is expand when needed, but > that should be doable. After 'fastpath' we know the size, so there should never be any need for 'expand' anything? Thanks! /Robbin > > Carsten > > On Wed, Mar 16, 2016 at 12:13 PM, Kim Barrett > wrote: > > > On Mar 16, 2016, at 8:33 AM, Robbin Ehn > wrote: > > > > Hi, please review this small change. > > > > This also change allocation methods. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ > > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ > > > > Thanks! > > > > /Robbin > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > Changing this: > 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, > mtLogging); > to this: > 137 char* newbuf = (char*) os::malloc(sizeof(char) * > newbuf_len, mtLogging); > > New code is missing out of memory handling that was present in the old > code. New code will just try to use newbuf, with bad results if the > allocation failed. > > New code is missing ASSERT-conditionalized PrintMallocFree support > that was present in the old. I don't know how important this is, > given that we also have PrintMalloc. (And I have to wonder why we > have both PrintMalloc (develop) and PrintMallocFree (notproduct).) > > ------------------------------------------------------------------------------ > > From robbin.ehn at oracle.com Thu Mar 17 06:44:32 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 17 Mar 2016 07:44:32 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> References: <56E952A5.6050708@oracle.com> <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> Message-ID: <56EA5250.8090001@oracle.com> Hi Kim, On 03/16/2016 05:13 PM, Kim Barrett wrote: >> On Mar 16, 2016, at 8:33 AM, Robbin Ehn wrote: >> >> Hi, please review this small change. >> >> This also change allocation methods. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >> >> Thanks! >> >> /Robbin > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > Changing this: > 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging); > to this: > 137 char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging); > > New code is missing out of memory handling that was present in the old > code. New code will just try to use newbuf, with bad results if the > allocation failed. Yes > > New code is missing ASSERT-conditionalized PrintMallocFree support > that was present in the old. I don't know how important this is, > given that we also have PrintMalloc. (And I have to wonder why we > have both PrintMalloc (develop) and PrintMallocFree (notproduct).) > > ------------------------------------------------------------------------------ > I wonder if this is even is the right path, we have 25 hpp including allocation.inline. The other ones seem to do their allocation from their inline.hpp file. Making me believe that we should either ignore this or do log.inline.hpp. Either way this patch should be dropped, thoughts? Thanks for having a look Kim! /Robbin From thomas.schatzl at oracle.com Thu Mar 17 08:01:02 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Mar 2016 09:01:02 +0100 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <56E99837.3010706@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> <7b553bec-baa7-447d-8b99-98980f910274@default> <56E88B6D.1000809@oracle.com> <1458128441.2326.37.camel@oracle.com> <56E99837.3010706@oracle.com> Message-ID: <1458201662.2291.0.camel@oracle.com> Hi Jon, On Wed, 2016-03-16 at 10:30 -0700, Jon Masamitsu wrote: > > On 03/16/2016 04:40 AM, Thomas Schatzl wrote: > > Hi, > > > > [...] > > > > Find below is the details > > > > Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 > > > > Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ > > > Looks good. > > fine with me, but we probably need to prepare some release note > > about > > that behavioral change. > > I added the label release-note=yes and the comment > > > For release notes > > > > With UseG1GC specifying -XX:ParallelGCThreads=0 is no longer > > allowed. > > Previously with -XX:ParallelGCThreads=0 G1 would execute some tasks > > using serial code executed by the VM thread. The closest > > approximation > > to this behavior is to specify -XX:ParallelGCThreads=1 which will > > cause parallel tasks to be executed by a single GC worker thread > > using > > parallel code. > > Please feel free to edit that comment. sounds fine. Thanks. Thomas From robbin.ehn at oracle.com Thu Mar 17 10:42:04 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 17 Mar 2016 11:42:04 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56EA1074.1070605@oracle.com> References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com> <56E8EEBE.9040208@oracle.com> <56EA1074.1070605@oracle.com> Message-ID: <56EA89FC.7050200@oracle.com> Hi Coleen, thanks for reviewing. On 03/17/2016 03:03 AM, Coleen Phillimore wrote: > > > On 3/16/16 1:27 AM, David Holmes wrote: >> On 16/03/2016 3:14 PM, David Holmes wrote: >>> Hi Robbin, >>> >>> Thanks for tackling this. :) >>> >>> On 16/03/2016 6:31 AM, Robbin Ehn wrote: >>>> Hi, please review this enhancement. >>>> >>>> This adds support for multiple UL tags in TraceTime. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >>>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ >>> >>> Initial query: why do so many .cpp files now include the timerTrace.hpp >>> file yet have no other changes? >> >> Okay this is because they already implicitly include timer.hpp but now >> have to include the new timerTrace.hpp. Fair enough. > > Now I see why also. > >> >> Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was >> not put in in alphabetical order. >> >>> I'm still mulling over the verbosity of the new format. You may recall >>> there was a lot of discussion about this last time round :) >> >> Do we perhaps want to keep the wrapper classes in logTimer.hpp? >> Additional uses of TraceTime with UL can then either add their own >> wrappers or use the direct form you have added support for. >> > > I think this looks good. The verbosity is far less than I thought it > would be and having a macro TRACETIME_LOG is a good indication that > something strange and macro-y is going on. Another clever use of > templates and macros here, but fine at the call sites. > Ok, I'll push as is, e.g. without logTimer.hpp Thanks ! /Robbin > thank you for fixing this. > > Coleen > > >> Thanks, >> David >> >>> Thanks, >>> David >>> >>>> Tested with jprt hotspot and manually tested log output. >>>> >>>> Thanks! >>>> >>>> /Robbin > From robbin.ehn at oracle.com Thu Mar 17 10:51:08 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 17 Mar 2016 11:51:08 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56E9378D.5050706@oracle.com> References: <56E87137.4080109@oracle.com> <56E9378D.5050706@oracle.com> Message-ID: <56EA8C1C.9020901@oracle.com> Hi Bengt Thanks for your input. On 03/16/2016 11:38 AM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-03-15 21:31, Robbin Ehn wrote: >> Hi, please review this enhancement. >> >> This adds support for multiple UL tags in TraceTime. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ > > I think this is fine but I just wanted to mention an alternative > approach. For the GC logging I introduced a GCTraceTimerImpl class and a > GCTraceTime macro. See: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146 > > > If you do something similar the code on the call site would look like this: > > TraceTime(Info, safepointcleanup) timer("deflating idle monitors"); > > instead of this: > > TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info, > safepointcleanup)); > > Your call. I just wanted to mention it. As discussed in other forums, I have created: https://bugs.openjdk.java.net/browse/JDK-8152089 for this. As we also agreed on, I'll be pushing this change-set. Thanks, /Robbin > > Thanks, > Bengt > >> >> Tested with jprt hotspot and manually tested log output. >> >> Thanks! >> >> /Robbin > From bengt.rutisson at oracle.com Thu Mar 17 12:32:38 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Mar 2016 13:32:38 +0100 Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more seamlessly In-Reply-To: <56EA8C1C.9020901@oracle.com> References: <56E87137.4080109@oracle.com> <56E9378D.5050706@oracle.com> <56EA8C1C.9020901@oracle.com> Message-ID: <56EAA3E6.1000508@oracle.com> Hi Robbin, Thanks for filing the RFE. Bengt On 2016-03-17 11:51, Robbin Ehn wrote: > Hi Bengt > > Thanks for your input. > > On 03/16/2016 11:38 AM, Bengt Rutisson wrote: >> >> Hi Robbin, >> >> On 2016-03-15 21:31, Robbin Ehn wrote: >>> Hi, please review this enhancement. >>> >>> This adds support for multiple UL tags in TraceTime. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/ >> >> I think this is fine but I just wanted to mention an alternative >> approach. For the GC logging I introduced a GCTraceTimerImpl class and a >> GCTraceTime macro. See: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146 >> >> >> >> If you do something similar the code on the call site would look like >> this: >> >> TraceTime(Info, safepointcleanup) timer("deflating idle monitors"); >> >> instead of this: >> >> TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info, >> safepointcleanup)); >> >> Your call. I just wanted to mention it. > > As discussed in other forums, I have created: > https://bugs.openjdk.java.net/browse/JDK-8152089 > for this. > > As we also agreed on, I'll be pushing this change-set. > > Thanks, > > /Robbin > >> >> Thanks, >> Bengt >> >>> >>> Tested with jprt hotspot and manually tested log output. >>> >>> Thanks! >>> >>> /Robbin >> From dmitry.dmitriev at oracle.com Thu Mar 17 13:29:01 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 17 Mar 2016 16:29:01 +0300 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> Message-ID: <56EAB11D.2030001@oracle.com> Hi Gerard, Looks good, except copyrights years in the following modules(forgot about that in the first round): commandLineFlagConstraintList.cpp commandLineFlagConstraintList.hpp commandLineFlagRangeList.hpp Not need a new webrev for that. Thanks, Dmitry On 16.03.2016 19:55, Gerard Ziemski wrote: > hi all, > > This is rev2 of the fix incorporating feedback from Dmitry: > > - re-use "CommandLineFlagConstraintList::find()" > > Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) > > With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. > > > bug https://bugs.openjdk.java.net/browse/JDK-8142510 > webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 > > tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation > > > cheers From gerard.ziemski at oracle.com Thu Mar 17 13:51:59 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Mar 2016 08:51:59 -0500 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EA0BCD.4080106@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <56E9E417.3020503@oracle.com> <56EA0BCD.4080106@oracle.com> Message-ID: David, If we were to move the initialization code off the startup path, we wouldn?t need to bother with this optimization. I?m in favor of ?defer until needed?, as I suggested earlier, as opposed to the ?eagerly initialize? approach taken here. cheers > On Mar 16, 2016, at 8:43 PM, David Holmes wrote: > > Hi James, > > On 17/03/2016 8:54 AM, james cheng wrote: >> Hi David, >> >> Thanks for implementing this RFE. >> >> A Solaris Linker guru suggested what we do something like this: >> >> my_pthread_setname_np(...) >> { >> static (*fptr)() = NULL; >> void *handle; >> >> if ((fptr == NULL) && >> ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) && >> ((fptr = dlsym(handle, "pthread_setname_np")) == NULL)) >> fptr = noop_setname; >> >> (*fptr)(...); >> } >> >> So using libc.so.1 without a path should be okay. But I don't see you have >> a null check for the return of dlsym(). > > We initialize _pthread_setname_np using dlopen+dlsym as above at VM startup - we don't want to do the lookup on each use. The NULL check happens in the actual os::set_native_thread_name() function. > > Glad to hear using the libc.so.1 path is okay (as we already use it) but was wondering if we can assume /usr/lib/libc.so.1 and so shorten the search time even further? > > Thanks, > David > >> >> Thanks, >> -James >> >> On 3/15/2016 9:24 PM, David Holmes wrote: >>> cc'ing James as initial requestor for this. >>> >>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>> >>>>> On Mar 15, 2016, at 4:31 PM, David Holmes >>>>> wrote: >>>>> >>>>>> Couldn?t we look it up on as needed basis in the implementation of >>>>>> "void os::set_native_thread_name(const char *name)? instead? >>>>> >>>>> AFAIK we never lookup anything as-needed but always handle it at VM >>>>> initialization time. A quick grep will show that we are using >>>>> RTLD_DEFAULT in a few places across >>>>> different platforms. Elsewhere we know what library we have to >>>>> search. I can try finding out which library it should be if you >>>>> think that is preferable? >>>> >>>> Sure, either that or we find out the performance impact on the >>>> startup time, so then we can decide if it?s an issue or not. >>> >>> Some numbers in the bug report. It seems to me if we know the library >>> that will contain the symbol then we should just open it. I filed a RFE: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>> >>> to look at use of RTLD_DEFAULT in general. >>> >>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>> >>> Not 100% sure whether dlopen should be also relying on the search path >>> dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 >>> should be hard-wired? I'm not >>> familiar enough with solaris library management to know whether we >>> will always find libc on that exact path? We have one existing >>> /usr/lib/libc.so.1 dlopen on Solaris x86, >>> but most dlopens just take the base name. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> thanks From gerard.ziemski at oracle.com Thu Mar 17 13:52:57 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 17 Mar 2016 08:52:57 -0500 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <56EAB11D.2030001@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> <56EAB11D.2030001@oracle.com> Message-ID: <176E1ED0-E954-4CAC-BB6D-1E8AAA184877@oracle.com> Thank you very much Dmitry! > On Mar 17, 2016, at 8:29 AM, Dmitry Dmitriev wrote: > > Hi Gerard, > > Looks good, except copyrights years in the following modules(forgot about that in the first round): > commandLineFlagConstraintList.cpp > commandLineFlagConstraintList.hpp > commandLineFlagRangeList.hpp > > Not need a new webrev for that. > > Thanks, > Dmitry > > On 16.03.2016 19:55, Gerard Ziemski wrote: >> hi all, >> >> This is rev2 of the fix incorporating feedback from Dmitry: >> >> - re-use "CommandLineFlagConstraintList::find()" >> >> Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) >> >> With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. >> >> >> bug https://bugs.openjdk.java.net/browse/JDK-8142510 >> webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 >> >> tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation >> >> >> cheers > From rachel.protacio at oracle.com Thu Mar 17 14:57:03 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 17 Mar 2016 10:57:03 -0400 Subject: RFR (XS): 8151560: Safepoint logging has mismatch between command line level and printed level In-Reply-To: <56E9DD3C.8050500@oracle.com> References: <56E9CBB5.8000008@oracle.com> <56E9CC0C.2060205@oracle.com> <5255F37C-4402-4B31-BC32-9B0DE0395385@oracle.com> <56E9CF53.8040100@oracle.com> <56E9DD3C.8050500@oracle.com> Message-ID: <56EAC5BF.3080103@oracle.com> Great, thanks David! Rachel On 3/16/2016 6:25 PM, David Holmes wrote: > +1 from me :) > > David > > On 17/03/2016 7:25 AM, Rachel Protacio wrote: >> Thanks, Harold and Jiangli! >> Rachel >> >> On 3/16/2016 5:21 PM, Jiangli Zhou wrote: >>> +1 >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 16, 2016, at 2:11 PM, harold seigel >>>> wrote: >>>> >>>> Change looks good! >>>> >>>> Harold >>>> >>>> On 3/16/2016 5:10 PM, Rachel Protacio wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for safepoint logging. The original >>>>> conversion accidentally put a "debug" stream where a "trace" stream >>>>> should have been. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151560 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8151560/ >>>>> >>>>> Passes JPRT. >>>>> >>>>> Thanks, >>>>> Rachel >> From ioi.lam at oracle.com Thu Mar 17 20:46:32 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 17 Mar 2016 13:46:32 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EA426A.4010608@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> Message-ID: <56EB17A8.3020807@oracle.com> Hi Calvin, The changes look good to me. Thanks for fixing the issues. - Ioi On 3/16/16 10:36 PM, Calvin Cheung wrote: > Dean, Ioi, > > Thanks for the review and discussions. > > Here's an updated webrev: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ > > Changes in this webrev: > - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). > Return if it is in the middle of a trampoline call. > - moved the guarantee from metaspaceShared_sparc.cpp to the common > metaspaceShared.cpp; > - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE > and related comment in metaspaceShared.hpp > > The last 2 changes are required due to the test failure with the > hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java > test. > > Testing: > JPRT with testset hotspot > jtreg tests under hotspot/runtime on all platforms > > thanks, > Calvin > > p.s. I corrected the bug id in the subject line from 8145521 to 8145221 > > > On 2/25/16, 10:03 AM, Ioi Lam wrote: >> >> >> On 2/22/16 12:50 PM, Dean Long wrote: >>> Hi Ioi, comments inlined below. >>> >>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>> Hi Dean, >>>> >>>> Thanks for raising this issue. >>>> >>>> My first impression is this probably shouldn't matter (or somehow >>>> we can get away with this). >>>> >>>> Today, the CDS archive already contains executable code in the >>>> "misc code" section. On Linux/x64, this is typically in the address >>>> range 0x802400000-0x802409000. The code is used to dynamically >>>> patch the C++ vtables of Metadata types that are stored in the CDS >>>> archive. So even today, there's a chance that the suspended PC >>>> lands in this section. >>>> >>> >>> OK, so you're saying that the trampolines don't make things any >>> worse :-) >> >> Well, theoretically the i2i and c2i entries would be executed more >> frequently than the vtable patching code, so if there was a problem, >> it could be aggravated. >>> >>>> The code is generated inside >>>> MetaspaceShared::generate_vtable_methods and looks like this when >>>> you run with -Xshare:on: >>>> >>>> (gdb) x/5i 0x802400000 >>>> 0x802400000: mov $0x0,%eax >>>> 0x802400005: jmpq 0x8024084d0 >>>> 0x80240000a: mov $0x1,%eax >>>> 0x80240000f: jmpq 0x8024084d0 >>>> 0x802400014: mov $0x2,%eax >>>> .... >>>> (gdb) x/16i 0x8024084d0 >>>> 0x8024084d0: push %rsi >>>> 0x8024084d1: push %rdi >>>> 0x8024084d2: mov %rax,%rdi >>>> 0x8024084d5: shr $0x8,%rdi >>>> 0x8024084d9: shl $0x3,%rdi >>>> 0x8024084dd: movabs $0x802000000,%rsi >>>> 0x8024084e7: add %rdi,%rsi >>>> 0x8024084ea: mov (%rsi),%rsi >>>> 0x8024084ed: pop %rdi >>>> 0x8024084ee: mov %rsi,(%rdi) >>>> 0x8024084f1: and $0xff,%rax >>>> 0x8024084f8: shl $0x3,%rax >>>> 0x8024084fc: add %rsi,%rax >>>> 0x8024084ff: pop %rsi >>>> 0x802408500: mov (%rax),%rax >>>> 0x802408503: jmpq *%rax >>>> >>>> In JDK9, the profiler takes a sample by first calling into >>>> JavaThread::pd_get_top_frame_for_profiling: >>>> >>>> (gdb) where >>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>> thread=0x7ffff08ce000) >>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>> ucontext=0x7ffec6287d00, isInJava=true) >>>> #2 0x00007ffff69d70be in >>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>> isInJava=true) >>>> >>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>> cause frame::safe_for_sender() to return false, and thus would >>>> prevent the profiler from doing any stack walking. >>>> >>> >>> Was the reason safe_for_sender() failed something that we can rely >>> on 100%? I looked at safe_for_sender, and it's not obvious why it >>> would fail, unless the frame pointer was invalid, and I think that >>> depends on the platform and flags like PreserveFramePointer. How >>> about filing a separate bug to track this issue? >>> >> >> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 >> to track this. >> >> Thanks >> - Ioi >> >>> dl >>> >>>> Also, both the CDS vtable patching code and the i2i trampolines are >>>> tail calls, so you will never find a PC in them except for the >>>> top-most frame. This means the check in >>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>> additional checks after we have started stack walking. >>>> >>>> I think the chance of landing in the CDS vtable patching methods, >>>> or in the trampolines, is pretty small, so that shouldn't bother >>>> the sampling profiler too much. >>>> >>>> Anyway, as part of this bug, we should add a regression test with >>>> the profiler enabled, and keep calling a method in the CDS archive >>>> in a tight loop (and manually disable compilation of that method >>>> using command-line options). The test should never crash, and if >>>> possible, it should also check that we don't have too many >>>> "unknown" samples. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>> We have profiling code that will suspend a thread at random points >>>>> and try to walk the stack. >>>>> I think frame::sender() will get confused if you happen to catch a >>>>> thread in the trampoline, >>>>> and frame::_pc is in metadata and not the code cache. >>>>> >>>>> dl >>>>> >>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>> >>>>>> This optimization reduces the size of the RW region of the CDS >>>>>> archive. It also reduces the amount of pages in the RW region >>>>>> that are actually written into during runtime. >>>>>> >>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>> (ioi.lam at oracle.com). >>>>>> I helped porting it to other platforms. >>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided >>>>>> the changes to the ppc platform. >>>>>> >>>>>> Testing: >>>>>> JPRT with testset hotspot >>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>> built on the Zero platform >>>>>> tested on the openjdk aarch64 platform >>>>>> refworkload on various platform (please refer to bug report >>>>>> for data) >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>> >>>> >>> >> From david.holmes at oracle.com Thu Mar 17 21:02:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 07:02:36 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <56E9E417.3020503@oracle.com> <56EA0BCD.4080106@oracle.com> Message-ID: <56EB1B6C.4030101@oracle.com> On 17/03/2016 11:51 PM, Gerard Ziemski wrote: > David, > > If we were to move the initialization code off the startup path, we wouldn?t need to bother with this optimization. > > I?m in favor of ?defer until needed?, as I suggested earlier, as opposed to the ?eagerly initialize? approach taken here. That would make things worse. During startup we will call set_native_thread_name multiple times. David > > cheers > >> On Mar 16, 2016, at 8:43 PM, David Holmes wrote: >> >> Hi James, >> >> On 17/03/2016 8:54 AM, james cheng wrote: >>> Hi David, >>> >>> Thanks for implementing this RFE. >>> >>> A Solaris Linker guru suggested what we do something like this: >>> >>> my_pthread_setname_np(...) >>> { >>> static (*fptr)() = NULL; >>> void *handle; >>> >>> if ((fptr == NULL) && >>> ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) && >>> ((fptr = dlsym(handle, "pthread_setname_np")) == NULL)) >>> fptr = noop_setname; >>> >>> (*fptr)(...); >>> } >>> >>> So using libc.so.1 without a path should be okay. But I don't see you have >>> a null check for the return of dlsym(). >> >> We initialize _pthread_setname_np using dlopen+dlsym as above at VM startup - we don't want to do the lookup on each use. The NULL check happens in the actual os::set_native_thread_name() function. >> >> Glad to hear using the libc.so.1 path is okay (as we already use it) but was wondering if we can assume /usr/lib/libc.so.1 and so shorten the search time even further? >> >> Thanks, >> David >> >>> >>> Thanks, >>> -James >>> >>> On 3/15/2016 9:24 PM, David Holmes wrote: >>>> cc'ing James as initial requestor for this. >>>> >>>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>>> >>>>>> On Mar 15, 2016, at 4:31 PM, David Holmes >>>>>> wrote: >>>>>> >>>>>>> Couldn?t we look it up on as needed basis in the implementation of >>>>>>> "void os::set_native_thread_name(const char *name)? instead? >>>>>> >>>>>> AFAIK we never lookup anything as-needed but always handle it at VM >>>>>> initialization time. A quick grep will show that we are using >>>>>> RTLD_DEFAULT in a few places across >>>>>> different platforms. Elsewhere we know what library we have to >>>>>> search. I can try finding out which library it should be if you >>>>>> think that is preferable? >>>>> >>>>> Sure, either that or we find out the performance impact on the >>>>> startup time, so then we can decide if it?s an issue or not. >>>> >>>> Some numbers in the bug report. It seems to me if we know the library >>>> that will contain the symbol then we should just open it. I filed a RFE: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>>> >>>> to look at use of RTLD_DEFAULT in general. >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>>> >>>> Not 100% sure whether dlopen should be also relying on the search path >>>> dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 >>>> should be hard-wired? I'm not >>>> familiar enough with solaris library management to know whether we >>>> will always find libc on that exact path? We have one existing >>>> /usr/lib/libc.so.1 dlopen on Solaris x86, >>>> but most dlopens just take the base name. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> thanks > From coleen.phillimore at oracle.com Thu Mar 17 21:39:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Mar 2016 17:39:53 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack Message-ID: <56EB2429.3090800@oracle.com> Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8152065 Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). Thanks, Coleen From kim.barrett at oracle.com Thu Mar 17 22:11:30 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Mar 2016 18:11:30 -0400 Subject: RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double) In-Reply-To: <1458201662.2291.0.camel@oracle.com> References: <636e660e-8a9c-4be7-b141-2a7d7b0c9c6c@default> <56E0FDD3.6020501@oracle.com> <56E1AD2A.201@oracle.com> <807BC935-887E-4FA3-B27B-B28224070E05@oracle.com> <56E2E7CE.1080809@oracle.com> <56E60A82.3020905@oracle.com> <56E65B8C.4010908@oracle.com> <56E65F81.5000909@oracle.com> <56E705C9.2010605@oracle.com> <7b553bec-baa7-447d-8b99-98980f910274@default> <56E88B6D.1000809@oracle.com> <1458128441.2326.37.camel@oracle.com> <56E99837.3010706@oracle.com> <1458201662.2291.0.camel@oracle.com> Message-ID: > On Mar 17, 2016, at 4:01 AM, Thomas Schatzl wrote: > > Hi Jon, > > On Wed, 2016-03-16 at 10:30 -0700, Jon Masamitsu wrote: >> >> On 03/16/2016 04:40 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> > [...] >>>>> Find below is the details >>>>> Bugid - https://bugs.openjdk.java.net/browse/JDK-8150518 >>>>> Webrev - http://cr.openjdk.java.net/~rpatil/8150518/webrev.01/ >>>> Looks good. >>> fine with me, but we probably need to prepare some release note >>> about >>> that behavioral change. >> >> I added the label release-note=yes and the comment >> >>> For release notes >>> >>> With UseG1GC specifying -XX:ParallelGCThreads=0 is no longer >>> allowed. >>> Previously with -XX:ParallelGCThreads=0 G1 would execute some tasks >>> using serial code executed by the VM thread. The closest >>> approximation >>> to this behavior is to specify -XX:ParallelGCThreads=1 which will >>> cause parallel tasks to be executed by a single GC worker thread >>> using >>> parallel code. >> >> Please feel free to edit that comment. > > sounds fine. Thanks. > > Thomas Looks good to me too. From kim.barrett at oracle.com Thu Mar 17 22:33:49 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 17 Mar 2016 18:33:49 -0400 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <56EA5250.8090001@oracle.com> References: <56E952A5.6050708@oracle.com> <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> <56EA5250.8090001@oracle.com> Message-ID: <2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com> > On Mar 17, 2016, at 2:44 AM, Robbin Ehn wrote: > On 03/16/2016 05:13 PM, Kim Barrett wrote: >>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn wrote: >>> >>> Hi, please review this small change. >>> >>> This also change allocation methods. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >>> >>> Thanks! >>> >>> /Robbin >> >> ------------------------------------------------------------------------------ >> src/share/vm/logging/log.hpp >> Changing this: >> 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging); >> to this: >> 137 char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging); >> >> New code is missing out of memory handling that was present in the old >> code. New code will just try to use newbuf, with bad results if the >> allocation failed. > > Yes > >> >> New code is missing ASSERT-conditionalized PrintMallocFree support >> that was present in the old. I don't know how important this is, >> given that we also have PrintMalloc. (And I have to wonder why we >> have both PrintMalloc (develop) and PrintMallocFree (notproduct).) >> >> ------------------------------------------------------------------------------ >> > > I wonder if this is even is the right path, we have 25 hpp including allocation.inline. > The other ones seem to do their allocation from their inline.hpp file. > > Making me believe that we should either ignore this or do log.inline.hpp. > > Either way this patch should be dropped, thoughts? I don't think ignoring is the right long-term approach, though is probably ok in the short term. In particular, I think adding log.inline.hpp would touch a lot of files, which seems like a bad thing to do just now, with largish changes coming soon that would need to be merged. And I'm not convinced log.inline.hpp is the right long term approach anyway. Rather, I prefer Carsten's suggestion of an out of line slow-path function in a .cpp. This approach is possible, even though we're dealing with templates, by using type-erasure. The generic (non-templated) slow-path function would need to receive a couple of function pointers from the vwrite template, e.g. the prefix and puts functions that are referenced by the present template code. The function pointer types don't refer to template parameters, e.g. the prefix function's type is size_t (*prefix_fn)(char*, size_t) and puts is void (*puts_fn)(LogLevelType, const char*) From jiangli.zhou at oracle.com Fri Mar 18 00:08:05 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 17 Mar 2016 17:08:05 -0700 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EB2429.3090800@oracle.com> References: <56EB2429.3090800@oracle.com> Message-ID: <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> Hi Coleen, This looks like a safe fix, but I probably can?t serve as a very good reviewer for this area. I have a question. Would ?JRT_LEAF? work also in this case? Thanks, Jiangli > On Mar 17, 2016, at 2:39 PM, Coleen Phillimore wrote: > > Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. > > open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8152065 > > Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). > > Thanks, > Coleen From david.holmes at oracle.com Fri Mar 18 00:47:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 10:47:40 +1000 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> Message-ID: <56EB502C.9010209@oracle.com> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: > Hi Coleen, > > This looks like a safe fix, but I probably can?t serve as a very good reviewer for this area. I have a question. Would ?JRT_LEAF? work also in this case? That was my question too! David > Thanks, > Jiangli > >> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore wrote: >> >> Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >> >> Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Fri Mar 18 01:34:12 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Mar 2016 21:34:12 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EB502C.9010209@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> Message-ID: <56EB5B14.8010308@oracle.com> Hi, Thank you for looking at this. IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use the IRT version. I guess someday we should get rid of the IRT versions. I'm not sure what the history was behind them. Coleen On 3/17/16 8:47 PM, David Holmes wrote: > On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >> Hi Coleen, >> >> This looks like a safe fix, but I probably can?t serve as a very good >> reviewer for this area. I have a question. Would ?JRT_LEAF? work also >> in this case? > > That was my question too! > > David > >> Thanks, >> Jiangli >> >>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>> wrote: >>> >>> Summary: Move trace_bytecode to InterpreterRuntime and make >>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>> >>> Tested with test program for bug >>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>> >>> Thanks, >>> Coleen >> From david.holmes at oracle.com Fri Mar 18 02:09:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 12:09:36 +1000 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EB5B14.8010308@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> Message-ID: <56EB6360.2070206@oracle.com> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: > > Hi, Thank you for looking at this. > > IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and > IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use > the IRT version. Sure - but then why the move from SharedRuntime to IntepreterRuntime ? Thanks, David > I guess someday we should get rid of the IRT versions. I'm not sure > what the history was behind them. > > Coleen > > > On 3/17/16 8:47 PM, David Holmes wrote: >> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>> Hi Coleen, >>> >>> This looks like a safe fix, but I probably can?t serve as a very good >>> reviewer for this area. I have a question. Would ?JRT_LEAF? work also >>> in this case? >> >> That was my question too! >> >> David >> >>> Thanks, >>> Jiangli >>> >>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>> wrote: >>>> >>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>> >>>> Tested with test program for bug >>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>> >>>> Thanks, >>>> Coleen >>> > From david.holmes at oracle.com Fri Mar 18 04:12:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 14:12:48 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56E9B1F8.3040800@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> Message-ID: <56EB8040.5090509@oracle.com> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: > Okay, I didn't see your reply. I also thought that storing a version in > the table might be helpful for documentation purposes so we know in the > future when to remove the line from the table. I agree with your > implementation choice to have an additional table rather than twisting > the other table to cover this use case. I don't I'm afraid - it is yet another special case and no automatic dropping of the message when we switch to JDK 10. Can't it be folded into the AliasedLoggingFlag support? I'm really not seeing why the conversion of the non-product flags to UL has to be handled differently to the product ones ?? Aren't these just deprecated flags? We internally convert them to their replacement form and issue a warning that they are going away? David > http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html > > > I think Harold's refactoring makes sense and I think the #endif // PRODUCT > > } > *+ #ifndef PRODUCT* > *+ else if ((replacement = > removed_develop_logging_flag_name(stripped_argname)) != NULL){* > *+ jio_fprintf(defaultStream::error_stream(),* > *+ "%s has been removed. Please use %s instead.\n", stripped_argname, > replacement);* > *+ return false;* > *+ #endif* > *+ }* > > > I think this should be like this so the {} match inside of #ifndef PRODUCT: > > *+ #ifndef PRODUCT* > *+ } else if ((replacement = > removed_develop_logging_flag_name(stripped_argname)) != NULL) {* > *+ jio_fprintf(defaultStream::error_stream(),* > *+ "%s has been removed. Please use %s instead.\n", stripped_argname, > replacement);* > *+ return false;* > *+ #endif* > *+ }* > > > Or refactor as Harold suggested. > > Coleen > > On 3/16/16 3:04 PM, Max Ockner wrote: >> I did, but it blended in with the rest of the text >> >> My response: "Seems appropriate to report a specific error message for >> 9 and then remove it for 10. If it would help, we can store a Version >> in the table to keep track of when each entry needs to be deleted, >> like what is done in the table of obsolete flags. " >> >> >> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>> >>> You should also answer David's concern. >>> Coleen >>> >>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>> - Labeled #endif with // PRODUCT >>>> - refactored table lookup code to only do lookup once. >>>> - Added VerboseVerification to the table. >>>> >>>> Comments below. >>>> >>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>> Hello again everyone! >>>>>> >>>>>> Please review this change which adds better error messages for >>>>>> non-product flags that are now converted to Unified Logging. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>> >>>>>> Since these options have been removed, we want still want the vm to >>>>>> crash here, but now with an error message giving the correct command >>>>>> line option. The new message looks like this: >>>>>> >>>>>> > TraceClassInitialization has been removed. Please use >>>>>> -Xlog:classinit >>>>>> instead." >>>>>> >>>>>> The entire output looks like this: >>>>>> >>>>>> > TraceClassInitialization has been removed. Please use >>>>>> -Xlog:classinit >>>>>> instead. >>>>>> > Error: Could not create the Java Virtual Machine. >>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> I'm concerned that this has introduced another variant of "flag >>>>> deprecation". It begs the question as to when this new code should >>>>> be removed. Maybe we need to add "replaced" as another type of flag >>>>> change so we can report in 9 the flag has been replaced and then in >>>>> 10 just report an "unknown option" error ? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>> Seems appropriate to report a specific error message for 9 and then >>>> remove it for 10. If it would help, we can store a Version in the >>>> table to keep track of when each entry needs to be deleted, like >>>> what is done in the table of obsolete flags. >>>>>> Tested with jtreg runtime tests. A new test checks for an appropriate >>>>>> error message for every develop flag that has so far been >>>>>> converted to >>>>>> logging. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>> >>> >> > From jiangli.zhou at Oracle.COM Fri Mar 18 04:37:45 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Thu, 17 Mar 2016 21:37:45 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EA426A.4010608@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> Message-ID: <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> Hi Calvin, The changes look good overall. Following are my comments and questions. - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp Please place the new CDS-only code under #if INCLUDE_CDS. It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. - src/share/vm/interpreter/abstractInterpreter.cpp It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. - src/share/vm/memory/metaspaceShared.cpp I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. - src/share/vm/oops/method.cpp Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? - src/share/vm/oops/method.hpp In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? - src/share/vm/runtime/sharedRuntime.cpp Please add a comment for the change at line 2537 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { - src/share/vm/oops/constMethod.hpp ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. Do you have estimate about the size increase with the generated trampolines for the shared methods? Thanks, Jiangli > On Mar 16, 2016, at 10:36 PM, Calvin Cheung wrote: > > Dean, Ioi, > > Thanks for the review and discussions. > > Here's an updated webrev: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ > > Changes in this webrev: > - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. > - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; > - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp > > The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. > > Testing: > JPRT with testset hotspot > jtreg tests under hotspot/runtime on all platforms > > thanks, > Calvin > > p.s. I corrected the bug id in the subject line from 8145521 to 8145221 > > > On 2/25/16, 10:03 AM, Ioi Lam wrote: >> >> >> On 2/22/16 12:50 PM, Dean Long wrote: >>> Hi Ioi, comments inlined below. >>> >>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>> Hi Dean, >>>> >>>> Thanks for raising this issue. >>>> >>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>> >>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>> >>> >>> OK, so you're saying that the trampolines don't make things any worse :-) >> >> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>> >>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>> >>>> (gdb) x/5i 0x802400000 >>>> 0x802400000: mov $0x0,%eax >>>> 0x802400005: jmpq 0x8024084d0 >>>> 0x80240000a: mov $0x1,%eax >>>> 0x80240000f: jmpq 0x8024084d0 >>>> 0x802400014: mov $0x2,%eax >>>> .... >>>> (gdb) x/16i 0x8024084d0 >>>> 0x8024084d0: push %rsi >>>> 0x8024084d1: push %rdi >>>> 0x8024084d2: mov %rax,%rdi >>>> 0x8024084d5: shr $0x8,%rdi >>>> 0x8024084d9: shl $0x3,%rdi >>>> 0x8024084dd: movabs $0x802000000,%rsi >>>> 0x8024084e7: add %rdi,%rsi >>>> 0x8024084ea: mov (%rsi),%rsi >>>> 0x8024084ed: pop %rdi >>>> 0x8024084ee: mov %rsi,(%rdi) >>>> 0x8024084f1: and $0xff,%rax >>>> 0x8024084f8: shl $0x3,%rax >>>> 0x8024084fc: add %rsi,%rax >>>> 0x8024084ff: pop %rsi >>>> 0x802408500: mov (%rax),%rax >>>> 0x802408503: jmpq *%rax >>>> >>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>> >>>> (gdb) where >>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>> isInJava=true) >>>> >>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>> >>> >>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>> >> >> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >> >> Thanks >> - Ioi >> >>> dl >>> >>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>> >>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>> >>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>> and frame::_pc is in metadata and not the code cache. >>>>> >>>>> dl >>>>> >>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>> >>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>> >>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com). >>>>>> I helped porting it to other platforms. >>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided the changes to the ppc platform. >>>>>> >>>>>> Testing: >>>>>> JPRT with testset hotspot >>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>> built on the Zero platform >>>>>> tested on the openjdk aarch64 platform >>>>>> refworkload on various platform (please refer to bug report for data) >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>> >>>> >>> >> From ioi.lam at oracle.com Fri Mar 18 05:13:50 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 17 Mar 2016 22:13:50 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> Message-ID: <56EB8E8E.4020209@oracle.com> Hi Jiangli, Since I wrote some of the original code, I'll try to answer some of the questions below On 3/17/16 9:37 PM, Jiangli Zhou wrote: > Hi Calvin, > > The changes look good overall. Following are my comments and questions. > > - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp > - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp > - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp > - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp > - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp > - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp > - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp > Please place the new CDS-only code under #if INCLUDE_CDS. > > It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. I am not sure what this means. Could you explain? > > - src/share/vm/interpreter/abstractInterpreter.cpp > It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. > > - src/share/vm/memory/metaspaceShared.cpp > I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. > > - src/share/vm/oops/method.cpp > Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? We can change the code to assert(DumpSharedSpaces, "..."); // Set the values to what they should be at run time. Note that // this Method can no longer be executed during dump time. _i2i_entry = Interpreter::entry_for_cds_method(this); _from_interpreted_entry = _i2i_entry; I think unlink_method used to be called during run time as well. See this assert later in unlink_method // In case of DumpSharedSpaces, _method_data should always be NULL. // // During runtime (!DumpSharedSpaces), when we are cleaning a // shared class that failed to load, this->link_method() may // have already been called (before an exception happened), so // this->_method_data may not be NULL. assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method data?"); So we need to remove the "!DumpSharedSpaces ||" and fix the comments. > - src/share/vm/oops/method.hpp > In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? The purpose of the check is to avoid writing the same value into the shared Method (which would cause the pages to be copied-on-write, even if the value does not change). 475 void set_interpreter_entry(address entry) { 476 if (_i2i_entry != entry) { 477 _i2i_entry = entry; 478 } 479 if (_from_interpreted_entry != entry) { 480 _from_interpreted_entry = entry; 481 } 482 } > - src/share/vm/runtime/sharedRuntime.cpp > Please add a comment for the change at line 2537 > 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { > - src/share/vm/oops/constMethod.hpp > > ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. The pointer ConstMethod::_adapter_trampoline never changes at run time. Only the content pointed to by _adapter_trampoline can change. Thanks - Ioi > Do you have estimate about the size increase with the generated trampolines for the shared methods? > > Thanks, > Jiangli > >> On Mar 16, 2016, at 10:36 PM, Calvin Cheung wrote: >> >> Dean, Ioi, >> >> Thanks for the review and discussions. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >> >> Changes in this webrev: >> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >> >> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >> >> Testing: >> JPRT with testset hotspot >> jtreg tests under hotspot/runtime on all platforms >> >> thanks, >> Calvin >> >> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >> >> >> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>> >>> On 2/22/16 12:50 PM, Dean Long wrote: >>>> Hi Ioi, comments inlined below. >>>> >>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>> Hi Dean, >>>>> >>>>> Thanks for raising this issue. >>>>> >>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>> >>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>> >>>> OK, so you're saying that the trampolines don't make things any worse :-) >>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>> >>>>> (gdb) x/5i 0x802400000 >>>>> 0x802400000: mov $0x0,%eax >>>>> 0x802400005: jmpq 0x8024084d0 >>>>> 0x80240000a: mov $0x1,%eax >>>>> 0x80240000f: jmpq 0x8024084d0 >>>>> 0x802400014: mov $0x2,%eax >>>>> .... >>>>> (gdb) x/16i 0x8024084d0 >>>>> 0x8024084d0: push %rsi >>>>> 0x8024084d1: push %rdi >>>>> 0x8024084d2: mov %rax,%rdi >>>>> 0x8024084d5: shr $0x8,%rdi >>>>> 0x8024084d9: shl $0x3,%rdi >>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>> 0x8024084e7: add %rdi,%rsi >>>>> 0x8024084ea: mov (%rsi),%rsi >>>>> 0x8024084ed: pop %rdi >>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>> 0x8024084f1: and $0xff,%rax >>>>> 0x8024084f8: shl $0x3,%rax >>>>> 0x8024084fc: add %rsi,%rax >>>>> 0x8024084ff: pop %rsi >>>>> 0x802408500: mov (%rax),%rax >>>>> 0x802408503: jmpq *%rax >>>>> >>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>> >>>>> (gdb) where >>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>> isInJava=true) >>>>> >>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>> >>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>> >>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>> >>> Thanks >>> - Ioi >>> >>>> dl >>>> >>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>> >>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>> >>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>> and frame::_pc is in metadata and not the code cache. >>>>>> >>>>>> dl >>>>>> >>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>> >>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>> >>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com). >>>>>>> I helped porting it to other platforms. >>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided the changes to the ppc platform. >>>>>>> >>>>>>> Testing: >>>>>>> JPRT with testset hotspot >>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>> built on the Zero platform >>>>>>> tested on the openjdk aarch64 platform >>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>> >>>>>>> thanks, >>>>>>> Calvin From cheleswer.sahu at oracle.com Fri Mar 18 07:54:02 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 18 Mar 2016 00:54:02 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters Message-ID: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> 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. 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(const 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. Regards, Cheleswer From dmitry.samersoff at oracle.com Fri Mar 18 09:04:36 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 18 Mar 2016 12:04:36 +0300 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> Message-ID: <56EBC4A4.7060904@oracle.com> Cheleswer, Fix (as immediate solution) looks good for me. But IMHO, silent truncation of the output inside output stream is not a correct behavior. So please file a follow-up CR to have it addressed. -Dmitry On 2016-03-18 10:54, 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. > > > > 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(const 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. > > > > > > 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 david.holmes at oracle.com Fri Mar 18 09:11:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 19:11:35 +1000 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> Message-ID: <56EBC647.6020704@oracle.com> 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(const > 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? David > Regards, > > Cheleswer > From cheleswer.sahu at oracle.com Fri Mar 18 09:58:07 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 18 Mar 2016 02:58:07 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EBC4A4.7060904@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC4A4.7060904@oracle.com> Message-ID: <01acffa1-ff7f-43d0-8ea4-7af6ecc92f6d@default> Thanks Dmitry for review. I will file CR and let you know once done. Cheleswer -----Original Message----- From: Dmitry Samersoff Sent: Friday, March 18, 2016 2:35 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 Cheleswer, Fix (as immediate solution) looks good for me. But IMHO, silent truncation of the output inside output stream is not a correct behavior. So please file a follow-up CR to have it addressed. -Dmitry On 2016-03-18 10:54, 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. > > > > 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(const 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. > > > > > > 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 dmitry.dmitriev at oracle.com Fri Mar 18 10:00:29 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 18 Mar 2016 13:00:29 +0300 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> Message-ID: <56EBD1BD.6090406@oracle.com> Hello Cheleswer, It is possible to create a regression test for that? Dmitry On 18.03.2016 10:54, 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. > > 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(const > 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. > > Regards, > > Cheleswer > From coleen.phillimore at oracle.com Fri Mar 18 11:43:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 07:43:19 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EB6360.2070206@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> Message-ID: <56EBE9D7.7020302@oracle.com> On 3/17/16 10:09 PM, David Holmes wrote: > > On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >> >> Hi, Thank you for looking at this. >> >> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use >> the IRT version. > > Sure - but then why the move from SharedRuntime to IntepreterRuntime ? Because it's used by the interpreter only. That's the first place to look for it so it's where it belongs. Coleen > > Thanks, > David > >> I guess someday we should get rid of the IRT versions. I'm not sure >> what the history was behind them. >> >> Coleen >> >> >> On 3/17/16 8:47 PM, David Holmes wrote: >>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>> Hi Coleen, >>>> >>>> This looks like a safe fix, but I probably can?t serve as a very good >>>> reviewer for this area. I have a question. Would ?JRT_LEAF? work also >>>> in this case? >>> >>> That was my question too! >>> >>> David >>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>> wrote: >>>>> >>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>> >>>>> Tested with test program for bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>> >>>>> Thanks, >>>>> Coleen >>>> >> From coleen.phillimore at oracle.com Fri Mar 18 11:58:35 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 07:58:35 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56EB8040.5090509@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> Message-ID: <56EBED6B.3000009@oracle.com> On 3/18/16 12:12 AM, David Holmes wrote: > On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >> Okay, I didn't see your reply. I also thought that storing a version in >> the table might be helpful for documentation purposes so we know in the >> future when to remove the line from the table. I agree with your >> implementation choice to have an additional table rather than twisting >> the other table to cover this use case. > > I don't I'm afraid - it is yet another special case and no automatic > dropping of the message when we switch to JDK 10. Can't it be folded > into the AliasedLoggingFlag support? I'm really not seeing why the > conversion of the non-product flags to UL has to be handled > differently to the product ones ?? The deprecation of non-product flags has always been different than product flags. The AliasedLogging flags alias the old option with the new flag because they are "deprecated", ie. warned (tbd) but not removed. Non-product flags can be removed without deprecation. This new table is just to improve the error message temporarily for non-product flags. It can't be handled with the aliased logging flag table because they convert the option. It is the intent to remove these options. > > Aren't these just deprecated flags? We internally convert them to > their replacement form and issue a warning that they are going away? The intent was to make a nice error message for the non-product flags we removed to help internal users. i thought you agreed to this in concept. Coleen > > > David > >> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >> >> >> >> I think Harold's refactoring makes sense and I think the #endif // >> PRODUCT >> >> } >> *+ #ifndef PRODUCT* >> *+ else if ((replacement = >> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >> *+ jio_fprintf(defaultStream::error_stream(),* >> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >> replacement);* >> *+ return false;* >> *+ #endif* >> *+ }* >> >> >> I think this should be like this so the {} match inside of #ifndef >> PRODUCT: >> >> *+ #ifndef PRODUCT* >> *+ } else if ((replacement = >> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >> *+ jio_fprintf(defaultStream::error_stream(),* >> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >> replacement);* >> *+ return false;* >> *+ #endif* >> *+ }* >> >> >> Or refactor as Harold suggested. >> >> Coleen >> >> On 3/16/16 3:04 PM, Max Ockner wrote: >>> I did, but it blended in with the rest of the text >>> >>> My response: "Seems appropriate to report a specific error message for >>> 9 and then remove it for 10. If it would help, we can store a Version >>> in the table to keep track of when each entry needs to be deleted, >>> like what is done in the table of obsolete flags. " >>> >>> >>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>> >>>> You should also answer David's concern. >>>> Coleen >>>> >>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>> - Labeled #endif with // PRODUCT >>>>> - refactored table lookup code to only do lookup once. >>>>> - Added VerboseVerification to the table. >>>>> >>>>> Comments below. >>>>> >>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>> Hello again everyone! >>>>>>> >>>>>>> Please review this change which adds better error messages for >>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>> >>>>>>> Since these options have been removed, we want still want the vm to >>>>>>> crash here, but now with an error message giving the correct >>>>>>> command >>>>>>> line option. The new message looks like this: >>>>>>> >>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>> -Xlog:classinit >>>>>>> instead." >>>>>>> >>>>>>> The entire output looks like this: >>>>>>> >>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>> -Xlog:classinit >>>>>>> instead. >>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> I'm concerned that this has introduced another variant of "flag >>>>>> deprecation". It begs the question as to when this new code should >>>>>> be removed. Maybe we need to add "replaced" as another type of flag >>>>>> change so we can report in 9 the flag has been replaced and then in >>>>>> 10 just report an "unknown option" error ? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>> Seems appropriate to report a specific error message for 9 and then >>>>> remove it for 10. If it would help, we can store a Version in the >>>>> table to keep track of when each entry needs to be deleted, like >>>>> what is done in the table of obsolete flags. >>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>> appropriate >>>>>>> error message for every develop flag that has so far been >>>>>>> converted to >>>>>>> logging. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>> >>>> >>> >> From cheleswer.sahu at oracle.com Fri Mar 18 12:03:55 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 18 Mar 2016 05:03:55 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EBC647.6020704@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC647.6020704@oracle.com> Message-ID: <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> 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(const > 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. David > Regards, > > Cheleswer > From coleen.phillimore at oracle.com Fri Mar 18 12:18:18 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 08:18:18 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> Message-ID: <56EBF20A.4020101@oracle.com> Thank you, Jiangli! I answered the JRT_LEAF question in my reply to David. Coleen On 3/17/16 8:08 PM, Jiangli Zhou wrote: > Hi Coleen, > > This looks like a safe fix, but I probably can?t serve as a very good reviewer for this area. I have a question. Would ?JRT_LEAF? work also in this case? > > Thanks, > Jiangli > >> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore wrote: >> >> Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >> >> Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). >> >> Thanks, >> Coleen From david.holmes at oracle.com Fri Mar 18 12:41:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 22:41:26 +1000 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EBE9D7.7020302@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> Message-ID: <56EBF776.2000902@oracle.com> On 18/03/2016 9:43 PM, Coleen Phillimore wrote: > > > On 3/17/16 10:09 PM, David Holmes wrote: >> >> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>> >>> Hi, Thank you for looking at this. >>> >>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use >>> the IRT version. >> >> Sure - but then why the move from SharedRuntime to IntepreterRuntime ? > > Because it's used by the interpreter only. That's the first place to > look for it so it's where it belongs. I'll take your word for it - I have no idea what belongs in sharedRuntime. :) But I'm still confused about the fix. How does the change to being a leaf method fix the rsp problem? And what is the connection with safepoints? Thanks, David > Coleen > >> >> Thanks, >> David >> >>> I guess someday we should get rid of the IRT versions. I'm not sure >>> what the history was behind them. >>> >>> Coleen >>> >>> >>> On 3/17/16 8:47 PM, David Holmes wrote: >>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>> Hi Coleen, >>>>> >>>>> This looks like a safe fix, but I probably can?t serve as a very good >>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? work also >>>>> in this case? >>>> >>>> That was my question too! >>>> >>>> David >>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>> wrote: >>>>>> >>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>> >>>>>> Tested with test program for bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>> > From david.holmes at oracle.com Fri Mar 18 12:45:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 22:45:09 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56EBED6B.3000009@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> Message-ID: <56EBF855.6060008@oracle.com> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: > On 3/18/16 12:12 AM, David Holmes wrote: >> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>> Okay, I didn't see your reply. I also thought that storing a version in >>> the table might be helpful for documentation purposes so we know in the >>> future when to remove the line from the table. I agree with your >>> implementation choice to have an additional table rather than twisting >>> the other table to cover this use case. >> >> I don't I'm afraid - it is yet another special case and no automatic >> dropping of the message when we switch to JDK 10. Can't it be folded >> into the AliasedLoggingFlag support? I'm really not seeing why the >> conversion of the non-product flags to UL has to be handled >> differently to the product ones ?? > > The deprecation of non-product flags has always been different than > product flags. The AliasedLogging flags alias the old option with the > new flag because they are "deprecated", ie. warned (tbd) but not > removed. Non-product flags can be removed without deprecation. This new > table is just to improve the error message temporarily for non-product > flags. > > It can't be handled with the aliased logging flag table because they > convert the option. It is the intent to remove these options. >> >> Aren't these just deprecated flags? We internally convert them to >> their replacement form and issue a warning that they are going away? > > The intent was to make a nice error message for the non-product flags we > removed to help internal users. i thought you agreed to this in concept. Concept yes but I'm frustrated by the mechanism - we have too many special cases with all this option processing, and too many tables. As you said above non-product flags can be removed without deprecation, but all deprecation does is produce a nice error message when you use the flag, and you want to add a nice error message for this case so you have in fact turned it back into a deprecation! David > Coleen > >> >> >> David >> >>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>> >>> >>> >>> I think Harold's refactoring makes sense and I think the #endif // >>> PRODUCT >>> >>> } >>> *+ #ifndef PRODUCT* >>> *+ else if ((replacement = >>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>> *+ jio_fprintf(defaultStream::error_stream(),* >>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>> replacement);* >>> *+ return false;* >>> *+ #endif* >>> *+ }* >>> >>> >>> I think this should be like this so the {} match inside of #ifndef >>> PRODUCT: >>> >>> *+ #ifndef PRODUCT* >>> *+ } else if ((replacement = >>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>> *+ jio_fprintf(defaultStream::error_stream(),* >>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>> replacement);* >>> *+ return false;* >>> *+ #endif* >>> *+ }* >>> >>> >>> Or refactor as Harold suggested. >>> >>> Coleen >>> >>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>> I did, but it blended in with the rest of the text >>>> >>>> My response: "Seems appropriate to report a specific error message for >>>> 9 and then remove it for 10. If it would help, we can store a Version >>>> in the table to keep track of when each entry needs to be deleted, >>>> like what is done in the table of obsolete flags. " >>>> >>>> >>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>> >>>>> You should also answer David's concern. >>>>> Coleen >>>>> >>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>> - Labeled #endif with // PRODUCT >>>>>> - refactored table lookup code to only do lookup once. >>>>>> - Added VerboseVerification to the table. >>>>>> >>>>>> Comments below. >>>>>> >>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>> Hello again everyone! >>>>>>>> >>>>>>>> Please review this change which adds better error messages for >>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>> >>>>>>>> Since these options have been removed, we want still want the vm to >>>>>>>> crash here, but now with an error message giving the correct >>>>>>>> command >>>>>>>> line option. The new message looks like this: >>>>>>>> >>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>> -Xlog:classinit >>>>>>>> instead." >>>>>>>> >>>>>>>> The entire output looks like this: >>>>>>>> >>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>> -Xlog:classinit >>>>>>>> instead. >>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>> deprecation". It begs the question as to when this new code should >>>>>>> be removed. Maybe we need to add "replaced" as another type of flag >>>>>>> change so we can report in 9 the flag has been replaced and then in >>>>>>> 10 just report an "unknown option" error ? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>> Seems appropriate to report a specific error message for 9 and then >>>>>> remove it for 10. If it would help, we can store a Version in the >>>>>> table to keep track of when each entry needs to be deleted, like >>>>>> what is done in the table of obsolete flags. >>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>> appropriate >>>>>>>> error message for every develop flag that has so far been >>>>>>>> converted to >>>>>>>> logging. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Fri Mar 18 12:51:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2016 22:51:24 +1000 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC647.6020704@oracle.com> <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> Message-ID: <56EBF9CC.8000809@oracle.com> 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(const >> 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 marcus.larsson at oracle.com Fri Mar 18 13:04:12 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 18 Mar 2016 14:04:12 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56E2D478.3090202@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> Message-ID: <56EBFCCC.1080701@oracle.com> Updated patch after feedback. New webrev: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ Incremental: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ Tested with internal VM tests through RBT. Changes: * Rotation filecount is now limited to 1000 files. * Removed loop in os::compare_file_modified_times. * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file. * Added test case to check that logging to a directory gives the intended error message. * Fixed test help method to handle arbitrary length log lines. Thanks, Marcus On 03/11/2016 03:21 PM, Marcus Larsson wrote: > Third time's the charm. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ > > This patch makes log file rotation the default. Default thresholds are > 5 rotated files with a target size of 20MiB. Truncating behavior can > be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). > > If a log file already exists during log file initialization it will be > rotated. If any of the target file names (file.0 to file.4 in the > default case) are available, that filename will be used for the > existing log. If all names are taken the VM will attempt to overwrite > the oldest file. > > This should prevent unlimited log file creations and avoid accidental > loss of log files from previous runs. The default thresholds (5 files, > 20MiB each) is just a suggestion. If you think it should be > higher/lower let me know. > > Tested with included internal VM tests through RBT. > > Thanks, > Marcus > > On 2016-03-01 15:05, Marcus Larsson wrote: >> Hi, >> >> After some offline discussions I'm withdrawing this patch. I will >> instead investigate if I can achieve similar behavior using log >> rotation as the default. >> >> Thanks, >> Marcus >> >> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>> Hi again, >>> >>> Taking a different approach to this. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>> >>> Existing files will now by default be renamed/archived with a .X >>> suffix where X is the lowest number such that the resulting file >>> name is available (jvm.log becomes jvm.log.0). A mode option for >>> controlling this behavior has been added as well. It can be set to >>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>> >>> Tested with included jtreg test through JPRT. >>> >>> Thanks, >>> Marcus >>> >>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to make sure UL truncates >>>> existing log files before writing to them. Since files are opened >>>> in append mode, truncation isn't done automatically, so instead the >>>> patch adds an attempt to remove the log file before opening it. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>> >>>> Testing: >>>> Included test through JPRT >>>> >>>> Thanks, >>>> Marcus >>> >> > From dmitry.samersoff at oracle.com Fri Mar 18 13:28:37 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 18 Mar 2016 16:28:37 +0300 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EBF9CC.8000809@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC647.6020704@oracle.com> <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> <56EBF9CC.8000809@oracle.com> Message-ID: <56EC0285.9080004@oracle.com> 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("\""\"); 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. -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(const >>> 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 >>> -- 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 Fri Mar 18 14:02:08 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 10:02:08 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EBF776.2000902@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> <56EBF776.2000902@oracle.com> Message-ID: <56EC0A60.4010408@oracle.com> On 3/18/16 8:41 AM, David Holmes wrote: > On 18/03/2016 9:43 PM, Coleen Phillimore wrote: >> >> >> On 3/17/16 10:09 PM, David Holmes wrote: >>> >>> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>>> >>>> Hi, Thank you for looking at this. >>>> >>>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >>>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use >>>> the IRT version. >>> >>> Sure - but then why the move from SharedRuntime to IntepreterRuntime ? >> >> Because it's used by the interpreter only. That's the first place to >> look for it so it's where it belongs. > > I'll take your word for it - I have no idea what belongs in > sharedRuntime. :) > > But I'm still confused about the fix. How does the change to being a > leaf method fix the rsp problem? And what is the connection with > safepoints? So the IRT/JRT_ENTRY macro has a ThreadInVMFromJava scoped object, where the destructor does SafepointSynchronize::block. So there's a safepoint check at the IRT/JRT_END of these functions (JRT_BLOCK_END also). On x86, rsp - the stack pointer- is also the top of the expression stack. When we do a call_VM, we save rsp to last_Java_sp in the frame. The C++ frame.cpp code uses last_Java_sp to find oops on the expression stack. I verified that all the other calls into the call_VM() leave the correct state on the stack, but trace_bytecode pushes registers to save before calling call_VM. Look for trace_bytecode in src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp. It pushes the 4 argument registers to the stack. The failure I was debugging showed that these were causing the wrong oops to be found on the expression stack with Tom Benson's debugging code. The alternatives were to change all the cpu dependent code to not pass any arguments to trace_bytecode, since tos can be retrieved with frame::interpreter_frame_expression_stack_at(0), but I didn't really want to do that. I can't test a lot of platforms! Another choice was to copy the guts of call_VM into the trace_bytecode generator so that last_Java_sp is saved before the call to vm. I briefly looked at this, which is why I noticed that there were incorrect comments in the code. There are also way too many call_VM variants on x86 at least. All seem needed. So making trace_bytecode IRT_LEAF is the simplest fix so that we could get to the bottom of these other reported bugs. thanks, Coleen > Thanks, > David > >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> I guess someday we should get rid of the IRT versions. I'm not sure >>>> what the history was behind them. >>>> >>>> Coleen >>>> >>>> >>>> On 3/17/16 8:47 PM, David Holmes wrote: >>>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> This looks like a safe fix, but I probably can?t serve as a very >>>>>> good >>>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? work >>>>>> also >>>>>> in this case? >>>>> >>>>> That was my question too! >>>>> >>>>> David >>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>>> wrote: >>>>>>> >>>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>>> >>>>>>> Tested with test program for bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>>>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>> >> From coleen.phillimore at oracle.com Fri Mar 18 14:03:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 10:03:17 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56EBF855.6060008@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> Message-ID: <56EC0AA5.6000108@oracle.com> On 3/18/16 8:45 AM, David Holmes wrote: > On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >> On 3/18/16 12:12 AM, David Holmes wrote: >>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>> Okay, I didn't see your reply. I also thought that storing a >>>> version in >>>> the table might be helpful for documentation purposes so we know in >>>> the >>>> future when to remove the line from the table. I agree with your >>>> implementation choice to have an additional table rather than twisting >>>> the other table to cover this use case. >>> >>> I don't I'm afraid - it is yet another special case and no automatic >>> dropping of the message when we switch to JDK 10. Can't it be folded >>> into the AliasedLoggingFlag support? I'm really not seeing why the >>> conversion of the non-product flags to UL has to be handled >>> differently to the product ones ?? >> >> The deprecation of non-product flags has always been different than >> product flags. The AliasedLogging flags alias the old option with the >> new flag because they are "deprecated", ie. warned (tbd) but not >> removed. Non-product flags can be removed without deprecation. This new >> table is just to improve the error message temporarily for non-product >> flags. >> >> It can't be handled with the aliased logging flag table because they >> convert the option. It is the intent to remove these options. >>> >>> Aren't these just deprecated flags? We internally convert them to >>> their replacement form and issue a warning that they are going away? >> >> The intent was to make a nice error message for the non-product flags we >> removed to help internal users. i thought you agreed to this in >> concept. > > Concept yes but I'm frustrated by the mechanism - we have too many > special cases with all this option processing, and too many tables. > > As you said above non-product flags can be removed without > deprecation, but all deprecation does is produce a nice error message > when you use the flag, and you want to add a nice error message for > this case so you have in fact turned it back into a deprecation! Deprecation is ignore and run the JVM. This is going to exit the JVM with unrecognized option with a nicer message. Coleen > > David > >> Coleen >> >>> >>> >>> David >>> >>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>> >>>> >>>> >>>> >>>> I think Harold's refactoring makes sense and I think the #endif // >>>> PRODUCT >>>> >>>> } >>>> *+ #ifndef PRODUCT* >>>> *+ else if ((replacement = >>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>> replacement);* >>>> *+ return false;* >>>> *+ #endif* >>>> *+ }* >>>> >>>> >>>> I think this should be like this so the {} match inside of #ifndef >>>> PRODUCT: >>>> >>>> *+ #ifndef PRODUCT* >>>> *+ } else if ((replacement = >>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>> replacement);* >>>> *+ return false;* >>>> *+ #endif* >>>> *+ }* >>>> >>>> >>>> Or refactor as Harold suggested. >>>> >>>> Coleen >>>> >>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>> I did, but it blended in with the rest of the text >>>>> >>>>> My response: "Seems appropriate to report a specific error message >>>>> for >>>>> 9 and then remove it for 10. If it would help, we can store a Version >>>>> in the table to keep track of when each entry needs to be deleted, >>>>> like what is done in the table of obsolete flags. " >>>>> >>>>> >>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>> >>>>>> You should also answer David's concern. >>>>>> Coleen >>>>>> >>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>> - Labeled #endif with // PRODUCT >>>>>>> - refactored table lookup code to only do lookup once. >>>>>>> - Added VerboseVerification to the table. >>>>>>> >>>>>>> Comments below. >>>>>>> >>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>> Hello again everyone! >>>>>>>>> >>>>>>>>> Please review this change which adds better error messages for >>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>> >>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>> vm to >>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>> command >>>>>>>>> line option. The new message looks like this: >>>>>>>>> >>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>> -Xlog:classinit >>>>>>>>> instead." >>>>>>>>> >>>>>>>>> The entire output looks like this: >>>>>>>>> >>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>> -Xlog:classinit >>>>>>>>> instead. >>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>>> deprecation". It begs the question as to when this new code should >>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>> flag >>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>> then in >>>>>>>> 10 just report an "unknown option" error ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>> Seems appropriate to report a specific error message for 9 and then >>>>>>> remove it for 10. If it would help, we can store a Version in the >>>>>>> table to keep track of when each entry needs to be deleted, like >>>>>>> what is done in the table of obsolete flags. >>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>> appropriate >>>>>>>>> error message for every develop flag that has so far been >>>>>>>>> converted to >>>>>>>>> logging. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From daniel.daugherty at oracle.com Fri Mar 18 15:45:34 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Mar 2016 09:45:34 -0600 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EC0A60.4010408@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> <56EBF776.2000902@oracle.com> <56EC0A60.4010408@oracle.com> Message-ID: <56EC229E.8080802@oracle.com> On 3/18/16 8:02 AM, Coleen Phillimore wrote: > On 3/18/16 8:41 AM, David Holmes wrote: >> On 18/03/2016 9:43 PM, Coleen Phillimore wrote: >>> >>> >>> On 3/17/16 10:09 PM, David Holmes wrote: >>>> >>>> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi, Thank you for looking at this. >>>>> >>>>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >>>>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to use >>>>> the IRT version. >>>> >>>> Sure - but then why the move from SharedRuntime to IntepreterRuntime ? >>> >>> Because it's used by the interpreter only. That's the first place to >>> look for it so it's where it belongs. >> >> I'll take your word for it - I have no idea what belongs in >> sharedRuntime. :) >> >> But I'm still confused about the fix. How does the change to being a >> leaf method fix the rsp problem? And what is the connection with >> safepoints? > So the IRT/JRT_ENTRY macro has a ThreadInVMFromJava scoped object, > where the destructor does SafepointSynchronize::block. So there's a > safepoint check at the IRT/JRT_END of these functions (JRT_BLOCK_END > also). > > On x86, rsp - the stack pointer- is also the top of the expression > stack. When we do a call_VM, we save rsp to last_Java_sp in the > frame. The C++ frame.cpp code uses last_Java_sp to find oops on the > expression stack. > > I verified that all the other calls into the call_VM() leave the > correct state on the stack, but trace_bytecode pushes registers to > save before calling call_VM. > > Look for trace_bytecode in > src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp. It pushes the 4 > argument registers to the stack. The failure I was debugging showed > that these were causing the wrong oops to be found on the expression > stack with Tom Benson's debugging code. > > The alternatives were to change all the cpu dependent code to not pass > any arguments to trace_bytecode, since tos can be retrieved with > frame::interpreter_frame_expression_stack_at(0), but I didn't really > want to do that. I can't test a lot of platforms! Another choice was > to copy the guts of call_VM into the trace_bytecode generator so that > last_Java_sp is saved before the call to vm. I briefly looked at > this, which is why I noticed that there were incorrect comments in the > code. There are also way too many call_VM variants on x86 at least. > All seem needed. > > So making trace_bytecode IRT_LEAF is the simplest fix so that we could > get to the bottom of these other reported bugs. > > thanks, > Coleen > open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp src/share/vm/interpreter/bytecodeInterpreter.cpp No comments on these renames. src/cpu/x86/vm/frame_x86.hpp No comments (comment removal). src/cpu/x86/vm/interp_masm_x86.cpp No comments (name typo in mesg). src/share/vm/interpreter/interpreterRuntime.cpp No comments (comment removal). trace_bytecode() function moves to here and changes from JRT_ENTRY -> IRT_LEAF. src/share/vm/interpreter/interpreterRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp trace_bytecode() function moves from here and changes from JRT_ENTRY -> IRT_LEAF. src/share/vm/runtime/sharedRuntime.hpp No comments. So the old version of trace_bytecode() was marked JRT_ENTRY which meant that the built-in "ThreadInVMfromJava __tiv(thread)" caused the caller of trace_bytcode() to potentially safepoint at the end of the call to trace_bytecode() when ThreadInVMfromJava is destroyed. src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp: #ifndef _LP64 #else __ push(state); __ push(c_rarg0); __ push(c_rarg1); __ push(c_rarg2); __ push(c_rarg3); __ mov(c_rarg2, rax); // Pass itos #ifdef _WIN64 __ movflt(xmm3, xmm0); // Pass ftos #endif __ call_VM(noreg, CAST_FROM_FN_PTR(address, SharedRuntime::trace_bytecode), c_rarg1, c_rarg2, c_rarg3); // So the JRT_ENTRY marking of SharedRuntime::trace_bytecode() means // that we can go to a safepoint just before call_VM() returns and // that safepoint might be confused by the regs pushed above. __ pop(c_rarg3); __ pop(c_rarg2); __ pop(c_rarg1); __ pop(c_rarg0); __ pop(state); __ ret(0); // return from result handler #endif // _LP64 So if I understand what you said above, the safepoint code is expecting last_Java_sp to refer to the interpreter expression stack and instead it finds four registers on the top of the stack. Of course, now that trace_bytecode() is marked as an IRT_LEAF, I start wondering if we should be using one of the "leaf" variants of call_VM(), but I see that call_VM_leaf() isn't used anywhere in templateInterpreterGenerator_x86.cpp. Sigh... Do you happen to know why we shouldn't use a leaf variant? Thumbs up on the fix. Would be good to nail down some of the nagging questions, but not absolutely necessary... Dan > >> Thanks, >> David >> >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> I guess someday we should get rid of the IRT versions. I'm not sure >>>>> what the history was behind them. >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 3/17/16 8:47 PM, David Holmes wrote: >>>>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> This looks like a safe fix, but I probably can?t serve as a very >>>>>>> good >>>>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? work >>>>>>> also >>>>>>> in this case? >>>>>> >>>>>> That was my question too! >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>>>> wrote: >>>>>>>> >>>>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>>>> >>>>>>>> Tested with test program for bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with >>>>>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Fri Mar 18 17:42:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 13:42:05 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EC229E.8080802@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> <56EBF776.2000902@oracle.com> <56EC0A60.4010408@oracle.com> <56EC229E.8080802@oracle.com> Message-ID: <56EC3DED.7040605@oracle.com> Dan, Thank you for the code review and filling out the explanation of this change. See below about call_VM_leaf. On 3/18/16 11:45 AM, Daniel D. Daugherty wrote: > On 3/18/16 8:02 AM, Coleen Phillimore wrote: >> On 3/18/16 8:41 AM, David Holmes wrote: >>> On 18/03/2016 9:43 PM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/17/16 10:09 PM, David Holmes wrote: >>>>> >>>>> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi, Thank you for looking at this. >>>>>> >>>>>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >>>>>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to >>>>>> use >>>>>> the IRT version. >>>>> >>>>> Sure - but then why the move from SharedRuntime to >>>>> IntepreterRuntime ? >>>> >>>> Because it's used by the interpreter only. That's the first place to >>>> look for it so it's where it belongs. >>> >>> I'll take your word for it - I have no idea what belongs in >>> sharedRuntime. :) >>> >>> But I'm still confused about the fix. How does the change to being a >>> leaf method fix the rsp problem? And what is the connection with >>> safepoints? >> So the IRT/JRT_ENTRY macro has a ThreadInVMFromJava scoped object, >> where the destructor does SafepointSynchronize::block. So there's a >> safepoint check at the IRT/JRT_END of these functions (JRT_BLOCK_END >> also). >> >> On x86, rsp - the stack pointer- is also the top of the expression >> stack. When we do a call_VM, we save rsp to last_Java_sp in the >> frame. The C++ frame.cpp code uses last_Java_sp to find oops on the >> expression stack. >> >> I verified that all the other calls into the call_VM() leave the >> correct state on the stack, but trace_bytecode pushes registers to >> save before calling call_VM. >> >> Look for trace_bytecode in >> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp. It pushes the 4 >> argument registers to the stack. The failure I was debugging showed >> that these were causing the wrong oops to be found on the expression >> stack with Tom Benson's debugging code. >> >> The alternatives were to change all the cpu dependent code to not >> pass any arguments to trace_bytecode, since tos can be retrieved with >> frame::interpreter_frame_expression_stack_at(0), but I didn't really >> want to do that. I can't test a lot of platforms! Another choice >> was to copy the guts of call_VM into the trace_bytecode generator so >> that last_Java_sp is saved before the call to vm. I briefly looked >> at this, which is why I noticed that there were incorrect comments in >> the code. There are also way too many call_VM variants on x86 at >> least. All seem needed. >> >> So making trace_bytecode IRT_LEAF is the simplest fix so that we >> could get to the bottom of these other reported bugs. >> >> thanks, >> Coleen > > > open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev > > src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp > src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp > src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp > src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp > src/share/vm/interpreter/bytecodeInterpreter.cpp > No comments on these renames. > > src/cpu/x86/vm/frame_x86.hpp > No comments (comment removal). > > src/cpu/x86/vm/interp_masm_x86.cpp > No comments (name typo in mesg). > > src/share/vm/interpreter/interpreterRuntime.cpp > No comments (comment removal). > > trace_bytecode() function moves to here and changes from > JRT_ENTRY -> IRT_LEAF. > > src/share/vm/interpreter/interpreterRuntime.hpp > No comments. > > src/share/vm/runtime/sharedRuntime.cpp > trace_bytecode() function moves from here and changes from > JRT_ENTRY -> IRT_LEAF. > > src/share/vm/runtime/sharedRuntime.hpp > No comments. > > > So the old version of trace_bytecode() was marked JRT_ENTRY which > meant that the built-in "ThreadInVMfromJava __tiv(thread)" caused > the caller of trace_bytcode() to potentially safepoint at the end > of the call to trace_bytecode() when ThreadInVMfromJava is destroyed. > > src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp: > > #ifndef _LP64 > > #else > __ push(state); > __ push(c_rarg0); > __ push(c_rarg1); > __ push(c_rarg2); > __ push(c_rarg3); > __ mov(c_rarg2, rax); // Pass itos > #ifdef _WIN64 > __ movflt(xmm3, xmm0); // Pass ftos > #endif > __ call_VM(noreg, > CAST_FROM_FN_PTR(address, SharedRuntime::trace_bytecode), > c_rarg1, c_rarg2, c_rarg3); > > // So the JRT_ENTRY marking of SharedRuntime::trace_bytecode() means > // that we can go to a safepoint just before call_VM() returns and > // that safepoint might be confused by the regs pushed above. > > __ pop(c_rarg3); > __ pop(c_rarg2); > __ pop(c_rarg1); > __ pop(c_rarg0); > __ pop(state); > __ ret(0); // return from result > handler > #endif // _LP64 > > > So if I understand what you said above, the safepoint code is > expecting last_Java_sp to refer to the interpreter expression > stack and instead it finds four registers on the top of the > stack. Yes. > > Of course, now that trace_bytecode() is marked as an IRT_LEAF, > I start wondering if we should be using one of the "leaf" variants > of call_VM(), but I see that call_VM_leaf() isn't used anywhere > in templateInterpreterGenerator_x86.cpp. Sigh... Do you happen > to know why we shouldn't use a leaf variant? I started to change this, thinking the same thing. Most of the calls to call_VM_leaf don't walk the stack because they don't need to if they don't safepoint, so they don't set up last_Java_sp. There are a couple of calls that do set last_Java_sp. On x86, set_last_Java_sp also sets the fp (frame pointer) which is how the method and bcp are found. Maybe to be even more correct, these should be passed but I didn't want to change all the platforms which would require testing platforms that I don't have. > > Thumbs up on the fix. Would be good to nail down some of the > nagging questions, but not absolutely necessary... Thank you! I tried to explain this anomaly in the comment in InterpreterRuntime::trace_bytecode(). Coleen > > Dan > > > >> >>> Thanks, >>> David >>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I guess someday we should get rid of the IRT versions. I'm not sure >>>>>> what the history was behind them. >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 3/17/16 8:47 PM, David Holmes wrote: >>>>>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> This looks like a safe fix, but I probably can?t serve as a >>>>>>>> very good >>>>>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? >>>>>>>> work also >>>>>>>> in this case? >>>>>>> >>>>>>> That was my question too! >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Jiangli >>>>>>>> >>>>>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>>>>> >>>>>>>>> Tested with test program for bug >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese >>>>>>>>> with >>>>>>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>> >>>>>> >>>> >> > From jiangli.zhou at oracle.com Fri Mar 18 17:53:25 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 18 Mar 2016 10:53:25 -0700 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EBF20A.4020101@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EBF20A.4020101@oracle.com> Message-ID: <9536C5B8-EBAB-4107-BA23-2F0282577AF0@oracle.com> Hi Coleen, Thank you for the answers. Thanks, Jiangli > On Mar 18, 2016, at 5:18 AM, Coleen Phillimore wrote: > > > Thank you, Jiangli! I answered the JRT_LEAF question in my reply to David. > Coleen > > On 3/17/16 8:08 PM, Jiangli Zhou wrote: >> Hi Coleen, >> >> This looks like a safe fix, but I probably can?t serve as a very good reviewer for this area. I have a question. Would ?JRT_LEAF? work also in this case? >> >> Thanks, >> Jiangli >> >>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore wrote: >>> >>> Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>> >>> Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). >>> >>> Thanks, >>> Coleen > From calvin.cheung at oracle.com Fri Mar 18 17:53:30 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 18 Mar 2016 10:53:30 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EB8E8E.4020209@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> Message-ID: <56EC409A.1070202@oracle.com> Hi Jiangli, Thanks for your quick review. Let me try to answer the remaining questions below. On 3/17/16, 10:13 PM, Ioi Lam wrote: > Hi Jiangli, > > Since I wrote some of the original code, I'll try to answer some of > the questions below > > On 3/17/16 9:37 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> The changes look good overall. Following are my comments and questions. >> >> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >> Please place the new CDS-only code under #if INCLUDE_CDS. >> >> It would be a good idea to assert the address (current pc) is >> within the generated trampoline entry buffer. > I am not sure what this means. Could you explain? >> >> - src/share/vm/interpreter/abstractInterpreter.cpp >> It?s not necessary to put '#include for >> memory/metaspaceShared.hpp' under #if INCLUDE_CDS. I'll fix that. >> >> - src/share/vm/memory/metaspaceShared.cpp >> I see you changed ?read_only? to false for ?mc? region. Is it >> possible to place the trampoline code buffer in the ?md? region, so >> the ?mc? region does not need to be writable? It?s good to keep the >> ?mc? as read only so it would be easier to detect any ?accidental? >> writes to the region due to future changes. The ?md? can be made >> executable. But putting code in the md region and making md region executable is confusing too. I'd prefer leaving it as is for now. >> >> - src/share/vm/oops/method.cpp >> Method::unlink_method() is only called from >> Method::remove_unshareable_info(), which happens at dump time only. >> Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? > We can change the code to > > assert(DumpSharedSpaces, "..."); > // Set the values to what they should be at run time. Note that > // this Method can no longer be executed during dump time. > _i2i_entry = Interpreter::entry_for_cds_method(this); > _from_interpreted_entry = _i2i_entry; > > I think unlink_method used to be called during run time as well. See > this assert later in unlink_method > > // In case of DumpSharedSpaces, _method_data should always be NULL. > // > // During runtime (!DumpSharedSpaces), when we are cleaning a > // shared class that failed to load, this->link_method() may > // have already been called (before an exception happened), so > // this->_method_data may not be NULL. > assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method > data?"); > > So we need to remove the "!DumpSharedSpaces ||" and fix the comments. >> - src/share/vm/oops/method.hpp >> In set_interpreter_entry(), when _i2i_entry and >> _from_interpreted_entry are not the same as ?entry? for shared method? > > The purpose of the check is to avoid writing the same value into the > shared Method (which would cause the pages to be copied-on-write, even > if the value does not change). > > 475 void set_interpreter_entry(address entry) { > 476 if (_i2i_entry != entry) { > 477 _i2i_entry = entry; > 478 } > 479 if (_from_interpreted_entry != entry) { > 480 _from_interpreted_entry = entry; > 481 } > 482 } > >> - src/share/vm/runtime/sharedRuntime.cpp >> Please add a comment for the change at line 2537 >> 2537 if (!DumpSharedSpaces && >> CodeCacheExtensions::skip_compiler_support()) { I believe this is for handling the case when compiler is disabled during dumping. I'll work with Ioi to come up with some comments. >> - src/share/vm/oops/constMethod.hpp >> >> ConstMethod does not seem to be the right place for >> ?_adapter_trampoline? since it?s set at runtime. > > The pointer ConstMethod::_adapter_trampoline never changes at run > time. Only the content pointed to by _adapter_trampoline can change. > > Thanks > - Ioi >> Do you have estimate about the size increase with the generated >> trampolines for the shared methods? IIRC, the CDSAdapterHandlerEntry::init() is being called around 670 times during dump time using the default classlist. So for 64-bit, the size increase for md is around 50k. thanks, Calvin >> >> Thanks, >> Jiangli >> >>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>> wrote: >>> >>> Dean, Ioi, >>> >>> Thanks for the review and discussions. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>> >>> Changes in this webrev: >>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>> Return if it is in the middle of a trampoline call. >>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>> metaspaceShared.cpp; >>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>> >>> The last 2 changes are required due to the test failure with the >>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> test. >>> >>> Testing: >>> JPRT with testset hotspot >>> jtreg tests under hotspot/runtime on all platforms >>> >>> thanks, >>> Calvin >>> >>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>> >>> >>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>> >>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>> Hi Ioi, comments inlined below. >>>>> >>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>> Hi Dean, >>>>>> >>>>>> Thanks for raising this issue. >>>>>> >>>>>> My first impression is this probably shouldn't matter (or somehow >>>>>> we can get away with this). >>>>>> >>>>>> Today, the CDS archive already contains executable code in the >>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>> the suspended PC lands in this section. >>>>>> >>>>> OK, so you're saying that the trampolines don't make things any >>>>> worse :-) >>>> Well, theoretically the i2i and c2i entries would be executed more >>>> frequently than the vtable patching code, so if there was a >>>> problem, it could be aggravated. >>>>>> The code is generated inside >>>>>> MetaspaceShared::generate_vtable_methods and looks like this when >>>>>> you run with -Xshare:on: >>>>>> >>>>>> (gdb) x/5i 0x802400000 >>>>>> 0x802400000: mov $0x0,%eax >>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>> 0x80240000a: mov $0x1,%eax >>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>> 0x802400014: mov $0x2,%eax >>>>>> .... >>>>>> (gdb) x/16i 0x8024084d0 >>>>>> 0x8024084d0: push %rsi >>>>>> 0x8024084d1: push %rdi >>>>>> 0x8024084d2: mov %rax,%rdi >>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>> 0x8024084e7: add %rdi,%rsi >>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>> 0x8024084ed: pop %rdi >>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>> 0x8024084f1: and $0xff,%rax >>>>>> 0x8024084f8: shl $0x3,%rax >>>>>> 0x8024084fc: add %rsi,%rax >>>>>> 0x8024084ff: pop %rsi >>>>>> 0x802408500: mov (%rax),%rax >>>>>> 0x802408503: jmpq *%rax >>>>>> >>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>> >>>>>> (gdb) where >>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>> thread=0x7ffff08ce000) >>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>> #2 0x00007ffff69d70be in >>>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>> isInJava=true) >>>>>> >>>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>>> cause frame::safe_for_sender() to return false, and thus would >>>>>> prevent the profiler from doing any stack walking. >>>>>> >>>>> Was the reason safe_for_sender() failed something that we can rely >>>>> on 100%? I looked at safe_for_sender, and it's not obvious why it >>>>> would fail, unless the frame pointer was invalid, and I think that >>>>> depends on the platform and flags like PreserveFramePointer. How >>>>> about filing a separate bug to track this issue? >>>>> >>>> OK, I fill a new bug >>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> dl >>>>> >>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>> are tail calls, so you will never find a PC in them except for >>>>>> the top-most frame. This means the check in >>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>> additional checks after we have started stack walking. >>>>>> >>>>>> I think the chance of landing in the CDS vtable patching methods, >>>>>> or in the trampolines, is pretty small, so that shouldn't bother >>>>>> the sampling profiler too much. >>>>>> >>>>>> Anyway, as part of this bug, we should add a regression test with >>>>>> the profiler enabled, and keep calling a method in the CDS >>>>>> archive in a tight loop (and manually disable compilation of that >>>>>> method using command-line options). The test should never crash, >>>>>> and if possible, it should also check that we don't have too many >>>>>> "unknown" samples. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>> We have profiling code that will suspend a thread at random >>>>>>> points and try to walk the stack. >>>>>>> I think frame::sender() will get confused if you happen to catch >>>>>>> a thread in the trampoline, >>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>> >>>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>>> that are actually written into during runtime. >>>>>>>> >>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>> (ioi.lam at oracle.com). >>>>>>>> I helped porting it to other platforms. >>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>> provided the changes to the ppc platform. >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT with testset hotspot >>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>> built on the Zero platform >>>>>>>> tested on the openjdk aarch64 platform >>>>>>>> refworkload on various platform (please refer to bug report >>>>>>>> for data) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin > From jiangli.zhou at oracle.com Fri Mar 18 18:52:14 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 18 Mar 2016 11:52:14 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EB8E8E.4020209@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> Message-ID: Hi Ioi, > On Mar 17, 2016, at 10:13 PM, Ioi Lam wrote: > > Hi Jiangli, > > Since I wrote some of the original code, I'll try to answer some of the questions below > > On 3/17/16 9:37 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> The changes look good overall. Following are my comments and questions. >> >> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >> Please place the new CDS-only code under #if INCLUDE_CDS. >> >> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. > I am not sure what this means. Could you explain? We should assert that the address is in the generated trampoline code, but not at a random place in the shared space. If the control dumps to an arbitrary location, it might manifest itself into a bug that?s hard to debug. >> >> - src/share/vm/interpreter/abstractInterpreter.cpp >> It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >> >> - src/share/vm/memory/metaspaceShared.cpp >> I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. >> >> - src/share/vm/oops/method.cpp >> Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? > We can change the code to > > assert(DumpSharedSpaces, "..."); > // Set the values to what they should be at run time. Note that > // this Method can no longer be executed during dump time. > _i2i_entry = Interpreter::entry_for_cds_method(this); > _from_interpreted_entry = _i2i_entry; > > I think unlink_method used to be called during run time as well. See this assert later in unlink_method > > // In case of DumpSharedSpaces, _method_data should always be NULL. > // > // During runtime (!DumpSharedSpaces), when we are cleaning a > // shared class that failed to load, this->link_method() may > // have already been called (before an exception happened), so > // this->_method_data may not be NULL. > assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method data?"); > > So we need to remove the "!DumpSharedSpaces ||" and fix the comments. Ok. As part of the change, unlink_method() should be made more CDS explicit by adding CDS_ONLY, since it?s only used for CDS. >> - src/share/vm/oops/method.hpp >> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? > > The purpose of the check is to avoid writing the same value into the shared Method (which would cause the pages to be copied-on-write, even if the value does not change). > > 475 void set_interpreter_entry(address entry) { > 476 if (_i2i_entry != entry) { > 477 _i2i_entry = entry; > 478 } > 479 if (_from_interpreted_entry != entry) { > 480 _from_interpreted_entry = entry; > 481 } > 482 } I see set_interpreter_entry() is called from Method initializing code and link_method(). For a shared method, we should change the if check to be an assert. Would there be any case where the entry is not the same as the one in the shared method? > >> - src/share/vm/runtime/sharedRuntime.cpp >> Please add a comment for the change at line 2537 >> 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { >> - src/share/vm/oops/constMethod.hpp >> >> ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. > > The pointer ConstMethod::_adapter_trampoline never changes at run time. Only the content pointed to by _adapter_trampoline can change. Ok. Thanks, Jiangli > > Thanks > - Ioi >> Do you have estimate about the size increase with the generated trampolines for the shared methods? >> >> Thanks, >> Jiangli >> >>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung wrote: >>> >>> Dean, Ioi, >>> >>> Thanks for the review and discussions. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>> >>> Changes in this webrev: >>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >>> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >>> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>> >>> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>> >>> Testing: >>> JPRT with testset hotspot >>> jtreg tests under hotspot/runtime on all platforms >>> >>> thanks, >>> Calvin >>> >>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>> >>> >>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>> >>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>> Hi Ioi, comments inlined below. >>>>> >>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>> Hi Dean, >>>>>> >>>>>> Thanks for raising this issue. >>>>>> >>>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>>> >>>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>>> >>>>> OK, so you're saying that the trampolines don't make things any worse :-) >>>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>>> >>>>>> (gdb) x/5i 0x802400000 >>>>>> 0x802400000: mov $0x0,%eax >>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>> 0x80240000a: mov $0x1,%eax >>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>> 0x802400014: mov $0x2,%eax >>>>>> .... >>>>>> (gdb) x/16i 0x8024084d0 >>>>>> 0x8024084d0: push %rsi >>>>>> 0x8024084d1: push %rdi >>>>>> 0x8024084d2: mov %rax,%rdi >>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>> 0x8024084e7: add %rdi,%rsi >>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>> 0x8024084ed: pop %rdi >>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>> 0x8024084f1: and $0xff,%rax >>>>>> 0x8024084f8: shl $0x3,%rax >>>>>> 0x8024084fc: add %rsi,%rax >>>>>> 0x8024084ff: pop %rsi >>>>>> 0x802408500: mov (%rax),%rax >>>>>> 0x802408503: jmpq *%rax >>>>>> >>>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>>> >>>>>> (gdb) where >>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>> isInJava=true) >>>>>> >>>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>>> >>>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>>> >>>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> dl >>>>> >>>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>>> >>>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>>> >>>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>> >>>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>>> >>>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com). >>>>>>>> I helped porting it to other platforms. >>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided the changes to the ppc platform. >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT with testset hotspot >>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>> built on the Zero platform >>>>>>>> tested on the openjdk aarch64 platform >>>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin > From coleen.phillimore at oracle.com Fri Mar 18 18:53:08 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 14:53:08 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <9536C5B8-EBAB-4107-BA23-2F0282577AF0@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EBF20A.4020101@oracle.com> <9536C5B8-EBAB-4107-BA23-2F0282577AF0@oracle.com> Message-ID: <56EC4E94.9010404@oracle.com> Thanks, Jiangli! Coleen On 3/18/16 1:53 PM, Jiangli Zhou wrote: > Hi Coleen, > > Thank you for the answers. > > Thanks, > Jiangli > >> On Mar 18, 2016, at 5:18 AM, Coleen Phillimore wrote: >> >> >> Thank you, Jiangli! I answered the JRT_LEAF question in my reply to David. >> Coleen >> >> On 3/17/16 8:08 PM, Jiangli Zhou wrote: >>> Hi Coleen, >>> >>> This looks like a safe fix, but I probably can?t serve as a very good reviewer for this area. I have a question. Would ?JRT_LEAF? work also in this case? >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore wrote: >>>> >>>> Summary: Move trace_bytecode to InterpreterRuntime and make trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>> >>>> Tested with test program for bug https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese with -XX:+TraceBytecodes for a few minutes (output file got too big). >>>> >>>> Thanks, >>>> Coleen From calvin.cheung at oracle.com Fri Mar 18 20:51:11 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 18 Mar 2016 13:51:11 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs Message-ID: <56EC6A3F.7070500@oracle.com> This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 (unfortunately the bug was marked as "confidential") webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ Some adjustments need to be made due to: - attribute name in the jar manifest has been changed to "Multi-release"; - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". The diff between this patch and the reviewed patch is as follows: 11c11 < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); --- > + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); 14c14 < + strcmp(multi_ver, "true") == 0 || --- > + strcmp(multi_ver, "enable") == 0 || 64c64 < @@ -296,6 +345,17 @@ --- > @@ -272,6 +321,17 @@ 72c72 < + if (strstr(buffer, "Multi-Release: true") != NULL) { --- > + if (strstr(buffer, "Multiversion: true") != NULL) { thanks, Calvin [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From calvin.cheung at oracle.com Fri Mar 18 21:03:50 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 18 Mar 2016 14:03:50 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56EC6A3F.7070500@oracle.com> References: <56EC6A3F.7070500@oracle.com> Message-ID: <56EC6D36.6000109@oracle.com> Typo in the email: "Multi-release" -> "Multi-Release" Testing: JPRT -testset hotspot all tests under the hotspot_runtime testlist thanks, Calvin On 3/18/16, 1:51 PM, Calvin Cheung wrote: > > This fix was reviewed in Aug 2015[1] though most of the review > comments was via internal mailing list. Recently, the JEP 238 > (Multiple-Release jar files) has been checked into jdk9. So it is time > to make the corresponding changes in hotspot. > > JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 > (unfortunately the bug was marked as "confidential") > > webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ > > Some adjustments need to be made due to: > - attribute name in the jar manifest has been changed to "Multi-release"; > - system property has been changed to jdk.util.jar.enableMultiRelease > and it has value of "true", "force" or "false". > > The diff between this patch and the reviewed patch is as follows: > > 11c11 > < + const char* multi_ver = > Arguments::get_property("jdk.util.jar.enableMultiRelease"); > --- > > + const char* multi_ver = > Arguments::get_property("jdk.util.jar.multiversion"); > 14c14 > < + strcmp(multi_ver, "true") == 0 || > --- > > + strcmp(multi_ver, "enable") == 0 || > 64c64 > < @@ -296,6 +345,17 @@ > --- > > @@ -272,6 +321,17 @@ > 72c72 > < + if (strstr(buffer, "Multi-Release: true") != NULL) { > --- > > + if (strstr(buffer, "Multiversion: true") != NULL) { > > thanks, > Calvin > > [1]: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From david.holmes at oracle.com Fri Mar 18 21:37:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Mar 2016 07:37:10 +1000 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EC0285.9080004@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> Message-ID: <56EC7506.902@oracle.com> 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(const >>>> 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 david.holmes at oracle.com Fri Mar 18 21:45:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Mar 2016 07:45:41 +1000 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EC3DED.7040605@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> <56EBF776.2000902@oracle.com> <56EC0A60.4010408@oracle.com> <56EC229E.8080802@oracle.com> <56EC3DED.7040605@oracle.com> Message-ID: <56EC7705.2060001@oracle.com> On 19/03/2016 3:42 AM, Coleen Phillimore wrote: > > Dan, Thank you for the code review and filling out the explanation of > this change. Yes thanks Dan - I wasn't getting it. So really this just works around the real problem - call_VM makes an invalid assumption about what rsp points to when storing into _last_Java_fp. :( David ----- > See below about call_VM_leaf. > > On 3/18/16 11:45 AM, Daniel D. Daugherty wrote: >> On 3/18/16 8:02 AM, Coleen Phillimore wrote: >>> On 3/18/16 8:41 AM, David Holmes wrote: >>>> On 18/03/2016 9:43 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/17/16 10:09 PM, David Holmes wrote: >>>>>> >>>>>> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi, Thank you for looking at this. >>>>>>> >>>>>>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY and >>>>>>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to >>>>>>> use >>>>>>> the IRT version. >>>>>> >>>>>> Sure - but then why the move from SharedRuntime to >>>>>> IntepreterRuntime ? >>>>> >>>>> Because it's used by the interpreter only. That's the first place to >>>>> look for it so it's where it belongs. >>>> >>>> I'll take your word for it - I have no idea what belongs in >>>> sharedRuntime. :) >>>> >>>> But I'm still confused about the fix. How does the change to being a >>>> leaf method fix the rsp problem? And what is the connection with >>>> safepoints? >>> So the IRT/JRT_ENTRY macro has a ThreadInVMFromJava scoped object, >>> where the destructor does SafepointSynchronize::block. So there's a >>> safepoint check at the IRT/JRT_END of these functions (JRT_BLOCK_END >>> also). >>> >>> On x86, rsp - the stack pointer- is also the top of the expression >>> stack. When we do a call_VM, we save rsp to last_Java_sp in the >>> frame. The C++ frame.cpp code uses last_Java_sp to find oops on the >>> expression stack. >>> >>> I verified that all the other calls into the call_VM() leave the >>> correct state on the stack, but trace_bytecode pushes registers to >>> save before calling call_VM. >>> >>> Look for trace_bytecode in >>> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp. It pushes the 4 >>> argument registers to the stack. The failure I was debugging showed >>> that these were causing the wrong oops to be found on the expression >>> stack with Tom Benson's debugging code. >>> >>> The alternatives were to change all the cpu dependent code to not >>> pass any arguments to trace_bytecode, since tos can be retrieved with >>> frame::interpreter_frame_expression_stack_at(0), but I didn't really >>> want to do that. I can't test a lot of platforms! Another choice >>> was to copy the guts of call_VM into the trace_bytecode generator so >>> that last_Java_sp is saved before the call to vm. I briefly looked >>> at this, which is why I noticed that there were incorrect comments in >>> the code. There are also way too many call_VM variants on x86 at >>> least. All seem needed. >>> >>> So making trace_bytecode IRT_LEAF is the simplest fix so that we >>> could get to the bottom of these other reported bugs. >>> >>> thanks, >>> Coleen >> >> > open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >> >> src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp >> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >> src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp >> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp >> src/share/vm/interpreter/bytecodeInterpreter.cpp >> No comments on these renames. >> >> src/cpu/x86/vm/frame_x86.hpp >> No comments (comment removal). >> >> src/cpu/x86/vm/interp_masm_x86.cpp >> No comments (name typo in mesg). >> >> src/share/vm/interpreter/interpreterRuntime.cpp >> No comments (comment removal). >> >> trace_bytecode() function moves to here and changes from >> JRT_ENTRY -> IRT_LEAF. >> >> src/share/vm/interpreter/interpreterRuntime.hpp >> No comments. >> >> src/share/vm/runtime/sharedRuntime.cpp >> trace_bytecode() function moves from here and changes from >> JRT_ENTRY -> IRT_LEAF. >> >> src/share/vm/runtime/sharedRuntime.hpp >> No comments. >> >> >> So the old version of trace_bytecode() was marked JRT_ENTRY which >> meant that the built-in "ThreadInVMfromJava __tiv(thread)" caused >> the caller of trace_bytcode() to potentially safepoint at the end >> of the call to trace_bytecode() when ThreadInVMfromJava is destroyed. >> >> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp: >> >> #ifndef _LP64 >> >> #else >> __ push(state); >> __ push(c_rarg0); >> __ push(c_rarg1); >> __ push(c_rarg2); >> __ push(c_rarg3); >> __ mov(c_rarg2, rax); // Pass itos >> #ifdef _WIN64 >> __ movflt(xmm3, xmm0); // Pass ftos >> #endif >> __ call_VM(noreg, >> CAST_FROM_FN_PTR(address, SharedRuntime::trace_bytecode), >> c_rarg1, c_rarg2, c_rarg3); >> >> // So the JRT_ENTRY marking of SharedRuntime::trace_bytecode() means >> // that we can go to a safepoint just before call_VM() returns and >> // that safepoint might be confused by the regs pushed above. >> >> __ pop(c_rarg3); >> __ pop(c_rarg2); >> __ pop(c_rarg1); >> __ pop(c_rarg0); >> __ pop(state); >> __ ret(0); // return from result >> handler >> #endif // _LP64 >> >> >> So if I understand what you said above, the safepoint code is >> expecting last_Java_sp to refer to the interpreter expression >> stack and instead it finds four registers on the top of the >> stack. > > Yes. >> >> Of course, now that trace_bytecode() is marked as an IRT_LEAF, >> I start wondering if we should be using one of the "leaf" variants >> of call_VM(), but I see that call_VM_leaf() isn't used anywhere >> in templateInterpreterGenerator_x86.cpp. Sigh... Do you happen >> to know why we shouldn't use a leaf variant? > > I started to change this, thinking the same thing. Most of the calls > to call_VM_leaf don't walk the stack because they don't need to if they > don't safepoint, so they don't set up last_Java_sp. There are a couple > of calls that do set last_Java_sp. On x86, set_last_Java_sp also sets > the fp (frame pointer) which is how the method and bcp are found. > > Maybe to be even more correct, these should be passed but I didn't want > to change all the platforms which would require testing platforms that I > don't have. >> >> Thumbs up on the fix. Would be good to nail down some of the >> nagging questions, but not absolutely necessary... > > Thank you! I tried to explain this anomaly in the comment in > InterpreterRuntime::trace_bytecode(). > > Coleen > >> >> Dan >> >> >> >>> >>>> Thanks, >>>> David >>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I guess someday we should get rid of the IRT versions. I'm not sure >>>>>>> what the history was behind them. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 3/17/16 8:47 PM, David Holmes wrote: >>>>>>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> This looks like a safe fix, but I probably can?t serve as a >>>>>>>>> very good >>>>>>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? >>>>>>>>> work also >>>>>>>>> in this case? >>>>>>>> >>>>>>>> That was my question too! >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jiangli >>>>>>>>> >>>>>>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>>>>>> >>>>>>>>>> open webrev at >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>>>>>> >>>>>>>>>> Tested with test program for bug >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese >>>>>>>>>> with >>>>>>>>>> -XX:+TraceBytecodes for a few minutes (output file got too big). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>> >>>>>>> >>>>> >>> >> > From david.holmes at oracle.com Fri Mar 18 21:49:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Mar 2016 07:49:09 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56EC0AA5.6000108@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> Message-ID: <56EC77D5.4080603@oracle.com> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: > > > On 3/18/16 8:45 AM, David Holmes wrote: >> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>> On 3/18/16 12:12 AM, David Holmes wrote: >>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>> Okay, I didn't see your reply. I also thought that storing a >>>>> version in >>>>> the table might be helpful for documentation purposes so we know in >>>>> the >>>>> future when to remove the line from the table. I agree with your >>>>> implementation choice to have an additional table rather than twisting >>>>> the other table to cover this use case. >>>> >>>> I don't I'm afraid - it is yet another special case and no automatic >>>> dropping of the message when we switch to JDK 10. Can't it be folded >>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>> conversion of the non-product flags to UL has to be handled >>>> differently to the product ones ?? >>> >>> The deprecation of non-product flags has always been different than >>> product flags. The AliasedLogging flags alias the old option with the >>> new flag because they are "deprecated", ie. warned (tbd) but not >>> removed. Non-product flags can be removed without deprecation. This new >>> table is just to improve the error message temporarily for non-product >>> flags. >>> >>> It can't be handled with the aliased logging flag table because they >>> convert the option. It is the intent to remove these options. >>>> >>>> Aren't these just deprecated flags? We internally convert them to >>>> their replacement form and issue a warning that they are going away? >>> >>> The intent was to make a nice error message for the non-product flags we >>> removed to help internal users. i thought you agreed to this in >>> concept. >> >> Concept yes but I'm frustrated by the mechanism - we have too many >> special cases with all this option processing, and too many tables. >> >> As you said above non-product flags can be removed without >> deprecation, but all deprecation does is produce a nice error message >> when you use the flag, and you want to add a nice error message for >> this case so you have in fact turned it back into a deprecation! > > Deprecation is ignore and run the JVM. This is going to exit the JVM > with unrecognized option with a nicer message. So it is a special case of "expired" which means it isn't really expired because the VM still has to know about it. Hence yet-another-kind-of-flag. Seems to me this would all be a lot simpler if we treated the non-product flags the same as product and just aliased and deprecated them in 9, then expire in 10. There seems to be no benefit in what we are doing only added complexity. David > Coleen >> >> David >> >>> Coleen >>> >>>> >>>> >>>> David >>>> >>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> I think Harold's refactoring makes sense and I think the #endif // >>>>> PRODUCT >>>>> >>>>> } >>>>> *+ #ifndef PRODUCT* >>>>> *+ else if ((replacement = >>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>>> replacement);* >>>>> *+ return false;* >>>>> *+ #endif* >>>>> *+ }* >>>>> >>>>> >>>>> I think this should be like this so the {} match inside of #ifndef >>>>> PRODUCT: >>>>> >>>>> *+ #ifndef PRODUCT* >>>>> *+ } else if ((replacement = >>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>>> replacement);* >>>>> *+ return false;* >>>>> *+ #endif* >>>>> *+ }* >>>>> >>>>> >>>>> Or refactor as Harold suggested. >>>>> >>>>> Coleen >>>>> >>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>> I did, but it blended in with the rest of the text >>>>>> >>>>>> My response: "Seems appropriate to report a specific error message >>>>>> for >>>>>> 9 and then remove it for 10. If it would help, we can store a Version >>>>>> in the table to keep track of when each entry needs to be deleted, >>>>>> like what is done in the table of obsolete flags. " >>>>>> >>>>>> >>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> You should also answer David's concern. >>>>>>> Coleen >>>>>>> >>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>> - Added VerboseVerification to the table. >>>>>>>> >>>>>>>> Comments below. >>>>>>>> >>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>> Hello again everyone! >>>>>>>>>> >>>>>>>>>> Please review this change which adds better error messages for >>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>> >>>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>>> vm to >>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>> command >>>>>>>>>> line option. The new message looks like this: >>>>>>>>>> >>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>> -Xlog:classinit >>>>>>>>>> instead." >>>>>>>>>> >>>>>>>>>> The entire output looks like this: >>>>>>>>>> >>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>> -Xlog:classinit >>>>>>>>>> instead. >>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>> >>>>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>>>> deprecation". It begs the question as to when this new code should >>>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>>> flag >>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>> then in >>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>> Seems appropriate to report a specific error message for 9 and then >>>>>>>> remove it for 10. If it would help, we can store a Version in the >>>>>>>> table to keep track of when each entry needs to be deleted, like >>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>> appropriate >>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>> converted to >>>>>>>>>> logging. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Fri Mar 18 21:51:06 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Mar 2016 17:51:06 -0400 Subject: RFR 8152065: TraceBytecodes breaks the interpreter expression stack In-Reply-To: <56EC7705.2060001@oracle.com> References: <56EB2429.3090800@oracle.com> <485C738C-3CF0-47D4-A9F8-DD9DCEC6E19A@oracle.com> <56EB502C.9010209@oracle.com> <56EB5B14.8010308@oracle.com> <56EB6360.2070206@oracle.com> <56EBE9D7.7020302@oracle.com> <56EBF776.2000902@oracle.com> <56EC0A60.4010408@oracle.com> <56EC229E.8080802@oracle.com> <56EC3DED.7040605@oracle.com> <56EC7705.2060001@oracle.com> Message-ID: <56EC784A.4020208@oracle.com> On 3/18/16 5:45 PM, David Holmes wrote: > On 19/03/2016 3:42 AM, Coleen Phillimore wrote: >> >> Dan, Thank you for the code review and filling out the explanation of >> this change. > > Yes thanks Dan - I wasn't getting it. So really this just works around > the real problem - call_VM makes an invalid assumption about what rsp > points to when storing into _last_Java_fp. :( It's not invalid. It's deliberately valid all the time except for trace_bytecode(). Coleen > > David > ----- > >> See below about call_VM_leaf. >> >> On 3/18/16 11:45 AM, Daniel D. Daugherty wrote: >>> On 3/18/16 8:02 AM, Coleen Phillimore wrote: >>>> On 3/18/16 8:41 AM, David Holmes wrote: >>>>> On 18/03/2016 9:43 PM, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 3/17/16 10:09 PM, David Holmes wrote: >>>>>>> >>>>>>> On 18/03/2016 11:34 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi, Thank you for looking at this. >>>>>>>> >>>>>>>> IRT_LEAF and JRT_LEAF are almost identical, just like JRT_ENTRY >>>>>>>> and >>>>>>>> IRT_ENTRY. It's just the convention in interpreterRuntime.cpp to >>>>>>>> use >>>>>>>> the IRT version. >>>>>>> >>>>>>> Sure - but then why the move from SharedRuntime to >>>>>>> IntepreterRuntime ? >>>>>> >>>>>> Because it's used by the interpreter only. That's the first >>>>>> place to >>>>>> look for it so it's where it belongs. >>>>> >>>>> I'll take your word for it - I have no idea what belongs in >>>>> sharedRuntime. :) >>>>> >>>>> But I'm still confused about the fix. How does the change to being a >>>>> leaf method fix the rsp problem? And what is the connection with >>>>> safepoints? >>>> So the IRT/JRT_ENTRY macro has a ThreadInVMFromJava scoped object, >>>> where the destructor does SafepointSynchronize::block. So there's a >>>> safepoint check at the IRT/JRT_END of these functions (JRT_BLOCK_END >>>> also). >>>> >>>> On x86, rsp - the stack pointer- is also the top of the expression >>>> stack. When we do a call_VM, we save rsp to last_Java_sp in the >>>> frame. The C++ frame.cpp code uses last_Java_sp to find oops on the >>>> expression stack. >>>> >>>> I verified that all the other calls into the call_VM() leave the >>>> correct state on the stack, but trace_bytecode pushes registers to >>>> save before calling call_VM. >>>> >>>> Look for trace_bytecode in >>>> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp. It pushes the 4 >>>> argument registers to the stack. The failure I was debugging showed >>>> that these were causing the wrong oops to be found on the expression >>>> stack with Tom Benson's debugging code. >>>> >>>> The alternatives were to change all the cpu dependent code to not >>>> pass any arguments to trace_bytecode, since tos can be retrieved with >>>> frame::interpreter_frame_expression_stack_at(0), but I didn't really >>>> want to do that. I can't test a lot of platforms! Another choice >>>> was to copy the guts of call_VM into the trace_bytecode generator so >>>> that last_Java_sp is saved before the call to vm. I briefly looked >>>> at this, which is why I noticed that there were incorrect comments in >>>> the code. There are also way too many call_VM variants on x86 at >>>> least. All seem needed. >>>> >>>> So making trace_bytecode IRT_LEAF is the simplest fix so that we >>>> could get to the bottom of these other reported bugs. >>>> >>>> thanks, >>>> Coleen >>> >>> > open webrev at http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>> >>> src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp >>> src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp >>> src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp >>> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp >>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>> No comments on these renames. >>> >>> src/cpu/x86/vm/frame_x86.hpp >>> No comments (comment removal). >>> >>> src/cpu/x86/vm/interp_masm_x86.cpp >>> No comments (name typo in mesg). >>> >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> No comments (comment removal). >>> >>> trace_bytecode() function moves to here and changes from >>> JRT_ENTRY -> IRT_LEAF. >>> >>> src/share/vm/interpreter/interpreterRuntime.hpp >>> No comments. >>> >>> src/share/vm/runtime/sharedRuntime.cpp >>> trace_bytecode() function moves from here and changes from >>> JRT_ENTRY -> IRT_LEAF. >>> >>> src/share/vm/runtime/sharedRuntime.hpp >>> No comments. >>> >>> >>> So the old version of trace_bytecode() was marked JRT_ENTRY which >>> meant that the built-in "ThreadInVMfromJava __tiv(thread)" caused >>> the caller of trace_bytcode() to potentially safepoint at the end >>> of the call to trace_bytecode() when ThreadInVMfromJava is destroyed. >>> >>> src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp: >>> >>> #ifndef _LP64 >>> >>> #else >>> __ push(state); >>> __ push(c_rarg0); >>> __ push(c_rarg1); >>> __ push(c_rarg2); >>> __ push(c_rarg3); >>> __ mov(c_rarg2, rax); // Pass itos >>> #ifdef _WIN64 >>> __ movflt(xmm3, xmm0); // Pass ftos >>> #endif >>> __ call_VM(noreg, >>> CAST_FROM_FN_PTR(address, SharedRuntime::trace_bytecode), >>> c_rarg1, c_rarg2, c_rarg3); >>> >>> // So the JRT_ENTRY marking of SharedRuntime::trace_bytecode() means >>> // that we can go to a safepoint just before call_VM() returns and >>> // that safepoint might be confused by the regs pushed above. >>> >>> __ pop(c_rarg3); >>> __ pop(c_rarg2); >>> __ pop(c_rarg1); >>> __ pop(c_rarg0); >>> __ pop(state); >>> __ ret(0); // return from result >>> handler >>> #endif // _LP64 >>> >>> >>> So if I understand what you said above, the safepoint code is >>> expecting last_Java_sp to refer to the interpreter expression >>> stack and instead it finds four registers on the top of the >>> stack. >> >> Yes. >>> >>> Of course, now that trace_bytecode() is marked as an IRT_LEAF, >>> I start wondering if we should be using one of the "leaf" variants >>> of call_VM(), but I see that call_VM_leaf() isn't used anywhere >>> in templateInterpreterGenerator_x86.cpp. Sigh... Do you happen >>> to know why we shouldn't use a leaf variant? >> >> I started to change this, thinking the same thing. Most of the calls >> to call_VM_leaf don't walk the stack because they don't need to if they >> don't safepoint, so they don't set up last_Java_sp. There are a couple >> of calls that do set last_Java_sp. On x86, set_last_Java_sp also sets >> the fp (frame pointer) which is how the method and bcp are found. >> >> Maybe to be even more correct, these should be passed but I didn't want >> to change all the platforms which would require testing platforms that I >> don't have. >>> >>> Thumbs up on the fix. Would be good to nail down some of the >>> nagging questions, but not absolutely necessary... >> >> Thank you! I tried to explain this anomaly in the comment in >> InterpreterRuntime::trace_bytecode(). >> >> Coleen >> >>> >>> Dan >>> >>> >>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I guess someday we should get rid of the IRT versions. I'm not >>>>>>>> sure >>>>>>>> what the history was behind them. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> On 3/17/16 8:47 PM, David Holmes wrote: >>>>>>>>> On 18/03/2016 10:08 AM, Jiangli Zhou wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> This looks like a safe fix, but I probably can?t serve as a >>>>>>>>>> very good >>>>>>>>>> reviewer for this area. I have a question. Would ?JRT_LEAF? >>>>>>>>>> work also >>>>>>>>>> in this case? >>>>>>>>> >>>>>>>>> That was my question too! >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jiangli >>>>>>>>>> >>>>>>>>>>> On Mar 17, 2016, at 2:39 PM, Coleen Phillimore >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Summary: Move trace_bytecode to InterpreterRuntime and make >>>>>>>>>>> trace_bytecode an IRT_LEAF so that safepoints are not allowed. >>>>>>>>>>> >>>>>>>>>>> open webrev at >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152065.01/webrev >>>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152065 >>>>>>>>>>> >>>>>>>>>>> Tested with test program for bug >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151256 and runThese >>>>>>>>>>> with >>>>>>>>>>> -XX:+TraceBytecodes for a few minutes (output file got too >>>>>>>>>>> big). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> From ioi.lam at oracle.com Fri Mar 18 23:04:32 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 18 Mar 2016 16:04:32 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> Message-ID: <56EC8980.4050208@oracle.com> On 3/18/16 11:52 AM, Jiangli Zhou wrote: > Hi Ioi, > >> On Mar 17, 2016, at 10:13 PM, Ioi Lam > > wrote: >> >> Hi Jiangli, >> >> Since I wrote some of the original code, I'll try to answer some of >> the questions below >> >> On 3/17/16 9:37 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> The changes look good overall. Following are my comments and questions. >>> >>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>> Please place the new CDS-only code under #if INCLUDE_CDS. >>> >>> It would be a good idea to assert the address (current pc) is >>> within the generated trampoline entry buffer. >> I am not sure what this means. Could you explain? > > > We should assert that the address is in the generated trampoline code, > but not at a random place in the shared space. If the control dumps to > an arbitrary location, it might manifest itself into a bug that?s hard > to debug. I still don't understand where you want to put the assertion. Could you tell me which file/function you want to add the assert, and what should be put in the assert? > >>> >>> - src/share/vm/interpreter/abstractInterpreter.cpp >>> It?s not necessary to put '#include for >>> memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>> >>> - src/share/vm/memory/metaspaceShared.cpp >>> I see you changed ?read_only? to false for ?mc? region. Is it >>> possible to place the trampoline code buffer in the ?md? region, so >>> the ?mc? region does not need to be writable? It?s good to keep the >>> ?mc? as read only so it would be easier to detect any ?accidental? >>> writes to the region due to future changes. The ?md? can be made >>> executable. >>> >>> - src/share/vm/oops/method.cpp >>> Method::unlink_method() is only called from >>> Method::remove_unshareable_info(), which happens at dump time only. >>> Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >> We can change the code to >> >> assert(DumpSharedSpaces, "..."); >> // Set the values to what they should be at run time. Note that >> // this Method can no longer be executed during dump time. >> _i2i_entry = Interpreter::entry_for_cds_method(this); >> _from_interpreted_entry = _i2i_entry; >> >> I think unlink_method used to be called during run time as well. See >> this assert later in unlink_method >> >> // In case of DumpSharedSpaces, _method_data should always be NULL. >> // >> // During runtime (!DumpSharedSpaces), when we are cleaning a >> // shared class that failed to load, this->link_method() may >> // have already been called (before an exception happened), so >> // this->_method_data may not be NULL. >> assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method >> data?"); >> >> So we need to remove the "!DumpSharedSpaces ||" and fix the comments. > > Ok. As part of the change, unlink_method() should be made more CDS > explicit by adding CDS_ONLY, since it?s only used for CDS. > Sounds good. >>> - src/share/vm/oops/method.hpp >>> In set_interpreter_entry(), when _i2i_entry and >>> _from_interpreted_entry are not the same as ?entry? for shared method? >> >> The purpose of the check is to avoid writing the same value into the >> shared Method (which would cause the pages to be copied-on-write, >> even if the value does not change). >> >> 475 void set_interpreter_entry(address entry) { >> 476 if (_i2i_entry != entry) { >> 477 _i2i_entry = entry; >> 478 } >> 479 if (_from_interpreted_entry != entry) { >> 480 _from_interpreted_entry = entry; >> 481 } >> 482 } > > I see set_interpreter_entry() is called from Method initializing code > and link_method(). For a shared method, we should change the if check > to be an assert. Would there be any case where the entry is not the > same as the one in the shared method? I am actually not sure if for shared methods the i2i_entry and from_interpreter_entry would be set to any other values. E.g., in the future, someone may add a new tracing facility that requires modifying these 2 fields. I'd rather play safe so we don't overwrite into the shared Method most of the time, but if it does happen it will continue to work. Thanks - Ioi > >> >>> - src/share/vm/runtime/sharedRuntime.cpp >>> Please add a comment for the change at line 2537 >>> 2537 if (!DumpSharedSpaces && >>> CodeCacheExtensions::skip_compiler_support()) { >>> - src/share/vm/oops/constMethod.hpp >>> >>> ConstMethod does not seem to be the right place for >>> ?_adapter_trampoline? since it?s set at runtime. >> >> The pointer ConstMethod::_adapter_trampoline never changes at run >> time. Only the content pointed to by _adapter_trampoline can change. > > > Ok. > > Thanks, > Jiangli > >> >> Thanks >> - Ioi >>> Do you have estimate about the size increase with the generated >>> trampolines for the shared methods? >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>>> > wrote: >>>> >>>> Dean, Ioi, >>>> >>>> Thanks for the review and discussions. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>> >>>> >>>> Changes in this webrev: >>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>>> Return if it is in the middle of a trampoline call. >>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>>> metaspaceShared.cpp; >>>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>> >>>> The last 2 changes are required due to the test failure with the >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> test. >>>> >>>> Testing: >>>> JPRT with testset hotspot >>>> jtreg tests under hotspot/runtime on all platforms >>>> >>>> thanks, >>>> Calvin >>>> >>>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>>> >>>> >>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>> >>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>> Hi Ioi, comments inlined below. >>>>>> >>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>> Hi Dean, >>>>>>> >>>>>>> Thanks for raising this issue. >>>>>>> >>>>>>> My first impression is this probably shouldn't matter (or >>>>>>> somehow we can get away with this). >>>>>>> >>>>>>> Today, the CDS archive already contains executable code in the >>>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>>> the suspended PC lands in this section. >>>>>>> >>>>>> OK, so you're saying that the trampolines don't make things any >>>>>> worse :-) >>>>> Well, theoretically the i2i and c2i entries would be executed more >>>>> frequently than the vtable patching code, so if there was a >>>>> problem, it could be aggravated. >>>>>>> The code is generated inside >>>>>>> MetaspaceShared::generate_vtable_methods and looks like this >>>>>>> when you run with -Xshare:on: >>>>>>> >>>>>>> (gdb) x/5i 0x802400000 >>>>>>> 0x802400000: mov $0x0,%eax >>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>> 0x802400014: mov $0x2,%eax >>>>>>> .... >>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>> 0x8024084d0: push %rsi >>>>>>> 0x8024084d1: push %rdi >>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>> 0x8024084ed: pop %rdi >>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>> 0x8024084ff: pop %rsi >>>>>>> 0x802408500: mov (%rax),%rax >>>>>>> 0x802408503: jmpq *%rax >>>>>>> >>>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>>> >>>>>>> (gdb) where >>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>>> thread=0x7ffff08ce000) >>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>>> #2 0x00007ffff69d70be in >>>>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>> isInJava=true) >>>>>>> >>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>>>> cause frame::safe_for_sender() to return false, and thus would >>>>>>> prevent the profiler from doing any stack walking. >>>>>>> >>>>>> Was the reason safe_for_sender() failed something that we can >>>>>> rely on 100%? I looked at safe_for_sender, and it's not obvious >>>>>> why it would fail, unless the frame pointer was invalid, and I >>>>>> think that depends on the platform and flags like >>>>>> PreserveFramePointer. How about filing a separate bug to track >>>>>> this issue? >>>>>> >>>>> OK, I fill a new bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> dl >>>>>> >>>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>>> are tail calls, so you will never find a PC in them except for >>>>>>> the top-most frame. This means the check in >>>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>>> additional checks after we have started stack walking. >>>>>>> >>>>>>> I think the chance of landing in the CDS vtable patching >>>>>>> methods, or in the trampolines, is pretty small, so that >>>>>>> shouldn't bother the sampling profiler too much. >>>>>>> >>>>>>> Anyway, as part of this bug, we should add a regression test >>>>>>> with the profiler enabled, and keep calling a method in the CDS >>>>>>> archive in a tight loop (and manually disable compilation of >>>>>>> that method using command-line options). The test should never >>>>>>> crash, and if possible, it should also check that we don't have >>>>>>> too many "unknown" samples. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>> We have profiling code that will suspend a thread at random >>>>>>>> points and try to walk the stack. >>>>>>>> I think frame::sender() will get confused if you happen to >>>>>>>> catch a thread in the trampoline, >>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>> >>>>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>>>> that are actually written into during runtime. >>>>>>>>> >>>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>>> (ioi.lam at oracle.com). >>>>>>>>> I helped porting it to other platforms. >>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>>> provided the changes to the ppc platform. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT with testset hotspot >>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>> built on the Zero platform >>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>> refworkload on various platform (please refer to bug report >>>>>>>>> for data) >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >> > From claes.redestad at oracle.com Fri Mar 18 23:38:05 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 19 Mar 2016 00:38:05 +0100 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56EC6D36.6000109@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> Message-ID: <56EC915D.8040004@oracle.com> Hi, sorry for being a bit out of the loop, but according to the most recent published spec[1] I could find the manifest attribute names needs to be treated case-insensitively. Has JEP-238 made necessary specification updates to allow deviation from this rule for new attribute names? Thanks! /Claes [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html On 2016-03-18 22:03, Calvin Cheung wrote: > Typo in the email: > "Multi-release" -> "Multi-Release" > > Testing: > JPRT -testset hotspot > all tests under the hotspot_runtime testlist > > thanks, > Calvin > > On 3/18/16, 1:51 PM, Calvin Cheung wrote: >> >> This fix was reviewed in Aug 2015[1] though most of the review >> comments was via internal mailing list. Recently, the JEP 238 >> (Multiple-Release jar files) has been checked into jdk9. So it is >> time to make the corresponding changes in hotspot. >> >> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >> (unfortunately the bug was marked as "confidential") >> >> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >> >> Some adjustments need to be made due to: >> - attribute name in the jar manifest has been changed to >> "Multi-release"; >> - system property has been changed to jdk.util.jar.enableMultiRelease >> and it has value of "true", "force" or "false". >> >> The diff between this patch and the reviewed patch is as follows: >> >> 11c11 >> < + const char* multi_ver = >> Arguments::get_property("jdk.util.jar.enableMultiRelease"); >> --- >> > + const char* multi_ver = >> Arguments::get_property("jdk.util.jar.multiversion"); >> 14c14 >> < + strcmp(multi_ver, "true") == 0 || >> --- >> > + strcmp(multi_ver, "enable") == 0 || >> 64c64 >> < @@ -296,6 +345,17 @@ >> --- >> > @@ -272,6 +321,17 @@ >> 72c72 >> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >> --- >> > + if (strstr(buffer, "Multiversion: true") != NULL) { >> >> thanks, >> Calvin >> >> [1]: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From jiangli.zhou at oracle.com Sat Mar 19 01:43:17 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 18 Mar 2016 18:43:17 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EC8980.4050208@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> <56EC8980.4050208@oracle.com> Message-ID: <97D60664-1133-4BA5-8D7E-E715CCFADC4B@oracle.com> Hi Ioi, > On Mar 18, 2016, at 4:04 PM, Ioi Lam wrote: > > > > On 3/18/16 11:52 AM, Jiangli Zhou wrote: >> Hi Ioi, >> >>> On Mar 17, 2016, at 10:13 PM, Ioi Lam > wrote: >>> >>> Hi Jiangli, >>> >>> Since I wrote some of the original code, I'll try to answer some of the questions below >>> >>> On 3/17/16 9:37 PM, Jiangli Zhou wrote: >>>> Hi Calvin, >>>> >>>> The changes look good overall. Following are my comments and questions. >>>> >>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>> >>>> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. >>> I am not sure what this means. Could you explain? >> >> >> We should assert that the address is in the generated trampoline code, but not at a random place in the shared space. If the control dumps to an arbitrary location, it might manifest itself into a bug that?s hard to debug. > > I still don't understand where you want to put the assertion. Could you tell me which file/function you want to add the assert, and what should be put in the assert? For example, assert the pc() is in trampoline code if we get an address in the shared space in the following code in JavaThread::pd_get_top_frame(). 69 if (UseSharedSpaces && MetaspaceShared::is_in_shared_space(addr.pc())) { 70 // In the middle of a trampoline call. Bail out for safety. 71 // This happens rarely so shouldn't affect profiling. 72 return false; 73 } Something like the following? assert(addr.pc() >= MetaspaceShared::cds_i2i_entry_code_buffers() && addr.pc() < MetaspaceShared::cds_i2i_entry_code_buffers() + MetaspaceShared::cds_i2i_entry_code_buffer_size(), ?Unexpected"); >> >>>> >>>> - src/share/vm/interpreter/abstractInterpreter.cpp >>>> It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>>> >>>> - src/share/vm/memory/metaspaceShared.cpp >>>> I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. >>>> >>>> - src/share/vm/oops/method.cpp >>>> Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >>> We can change the code to >>> >>> assert(DumpSharedSpaces, "..."); >>> // Set the values to what they should be at run time. Note that >>> // this Method can no longer be executed during dump time. >>> _i2i_entry = Interpreter::entry_for_cds_method(this); >>> _from_interpreted_entry = _i2i_entry; >>> >>> I think unlink_method used to be called during run time as well. See this assert later in unlink_method >>> >>> // In case of DumpSharedSpaces, _method_data should always be NULL. >>> // >>> // During runtime (!DumpSharedSpaces), when we are cleaning a >>> // shared class that failed to load, this->link_method() may >>> // have already been called (before an exception happened), so >>> // this->_method_data may not be NULL. >>> assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method data?"); >>> >>> So we need to remove the "!DumpSharedSpaces ||" and fix the comments. >> >> Ok. As part of the change, unlink_method() should be made more CDS explicit by adding CDS_ONLY, since it?s only used for CDS. >> > > Sounds good. > >>>> - src/share/vm/oops/method.hpp >>>> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? >>> >>> The purpose of the check is to avoid writing the same value into the shared Method (which would cause the pages to be copied-on-write, even if the value does not change). >>> >>> 475 void set_interpreter_entry(address entry) { >>> 476 if (_i2i_entry != entry) { >>> 477 _i2i_entry = entry; >>> 478 } >>> 479 if (_from_interpreted_entry != entry) { >>> 480 _from_interpreted_entry = entry; >>> 481 } >>> 482 } >> >> I see set_interpreter_entry() is called from Method initializing code and link_method(). For a shared method, we should change the if check to be an assert. Would there be any case where the entry is not the same as the one in the shared method? > > I am actually not sure if for shared methods the i2i_entry and from_interpreter_entry would be set to any other values. E.g., in the future, someone may add a new tracing facility that requires modifying these 2 fields. > > I'd rather play safe so we don't overwrite into the shared Method most of the time, but if it does happen it will continue to work. This part of the code is more critical. So, we should have a tighter control of it. If someone is setting the the entry to a different valve than the one in the Method, we need to know what is the new entry and understand why. The assertion would force us to exam each new case like the one you described in the above. Is that reasonable? Thanks, Jiangli > > Thanks > - Ioi >> >>> >>>> - src/share/vm/runtime/sharedRuntime.cpp >>>> Please add a comment for the change at line 2537 >>>> 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { >>>> - src/share/vm/oops/constMethod.hpp >>>> >>>> ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. >>> >>> The pointer ConstMethod::_adapter_trampoline never changes at run time. Only the content pointed to by _adapter_trampoline can change. >> >> >> Ok. >> >> Thanks, >> Jiangli >> >>> >>> Thanks >>> - Ioi >>>> Do you have estimate about the size increase with the generated trampolines for the shared methods? >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung > wrote: >>>>> >>>>> Dean, Ioi, >>>>> >>>>> Thanks for the review and discussions. >>>>> >>>>> Here's an updated webrev: >>>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>>> >>>>> Changes in this webrev: >>>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >>>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >>>>> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>>> >>>>> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>>>> >>>>> Testing: >>>>> JPRT with testset hotspot >>>>> jtreg tests under hotspot/runtime on all platforms >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>>>> >>>>> >>>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>>> >>>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>>> Hi Ioi, comments inlined below. >>>>>>> >>>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>>> Hi Dean, >>>>>>>> >>>>>>>> Thanks for raising this issue. >>>>>>>> >>>>>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>>>>> >>>>>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>>>>> >>>>>>> OK, so you're saying that the trampolines don't make things any worse :-) >>>>>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>>>>> >>>>>>>> (gdb) x/5i 0x802400000 >>>>>>>> 0x802400000: mov $0x0,%eax >>>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>>> 0x802400014: mov $0x2,%eax >>>>>>>> .... >>>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>>> 0x8024084d0: push %rsi >>>>>>>> 0x8024084d1: push %rdi >>>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>>> 0x8024084ed: pop %rdi >>>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>>> 0x8024084ff: pop %rsi >>>>>>>> 0x802408500: mov (%rax),%rax >>>>>>>> 0x802408503: jmpq *%rax >>>>>>>> >>>>>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>>>>> >>>>>>>> (gdb) where >>>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>>> isInJava=true) >>>>>>>> >>>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>>>>> >>>>>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>>>>> >>>>>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> dl >>>>>>> >>>>>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>>>>> >>>>>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>>>>> >>>>>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>>> >>>>>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>>>>> >>>>>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com ). >>>>>>>>>> I helped porting it to other platforms. >>>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com ) who provided the changes to the ppc platform. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> JPRT with testset hotspot >>>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>>> built on the Zero platform >>>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Calvin >>> >> > From david.holmes at oracle.com Sat Mar 19 02:37:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Mar 2016 12:37:15 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56EC77D5.4080603@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> Message-ID: <56ECBB5B.9070008@oracle.com> Objections withdrawn. Code Reviewed. Thanks, David On 19/03/2016 7:49 AM, David Holmes wrote: > On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >> >> >> On 3/18/16 8:45 AM, David Holmes wrote: >>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>> version in >>>>>> the table might be helpful for documentation purposes so we know in >>>>>> the >>>>>> future when to remove the line from the table. I agree with your >>>>>> implementation choice to have an additional table rather than >>>>>> twisting >>>>>> the other table to cover this use case. >>>>> >>>>> I don't I'm afraid - it is yet another special case and no automatic >>>>> dropping of the message when we switch to JDK 10. Can't it be folded >>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>> conversion of the non-product flags to UL has to be handled >>>>> differently to the product ones ?? >>>> >>>> The deprecation of non-product flags has always been different than >>>> product flags. The AliasedLogging flags alias the old option with the >>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>> removed. Non-product flags can be removed without deprecation. This >>>> new >>>> table is just to improve the error message temporarily for non-product >>>> flags. >>>> >>>> It can't be handled with the aliased logging flag table because they >>>> convert the option. It is the intent to remove these options. >>>>> >>>>> Aren't these just deprecated flags? We internally convert them to >>>>> their replacement form and issue a warning that they are going away? >>>> >>>> The intent was to make a nice error message for the non-product >>>> flags we >>>> removed to help internal users. i thought you agreed to this in >>>> concept. >>> >>> Concept yes but I'm frustrated by the mechanism - we have too many >>> special cases with all this option processing, and too many tables. >>> >>> As you said above non-product flags can be removed without >>> deprecation, but all deprecation does is produce a nice error message >>> when you use the flag, and you want to add a nice error message for >>> this case so you have in fact turned it back into a deprecation! >> >> Deprecation is ignore and run the JVM. This is going to exit the JVM >> with unrecognized option with a nicer message. > > So it is a special case of "expired" which means it isn't really expired > because the VM still has to know about it. Hence yet-another-kind-of-flag. > > Seems to me this would all be a lot simpler if we treated the > non-product flags the same as product and just aliased and deprecated > them in 9, then expire in 10. There seems to be no benefit in what we > are doing only added complexity. > > David > >> Coleen >>> >>> David >>> >>>> Coleen >>>> >>>>> >>>>> >>>>> David >>>>> >>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I think Harold's refactoring makes sense and I think the #endif // >>>>>> PRODUCT >>>>>> >>>>>> } >>>>>> *+ #ifndef PRODUCT* >>>>>> *+ else if ((replacement = >>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>>>> replacement);* >>>>>> *+ return false;* >>>>>> *+ #endif* >>>>>> *+ }* >>>>>> >>>>>> >>>>>> I think this should be like this so the {} match inside of #ifndef >>>>>> PRODUCT: >>>>>> >>>>>> *+ #ifndef PRODUCT* >>>>>> *+ } else if ((replacement = >>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>> *+ "%s has been removed. Please use %s instead.\n", stripped_argname, >>>>>> replacement);* >>>>>> *+ return false;* >>>>>> *+ #endif* >>>>>> *+ }* >>>>>> >>>>>> >>>>>> Or refactor as Harold suggested. >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>> I did, but it blended in with the rest of the text >>>>>>> >>>>>>> My response: "Seems appropriate to report a specific error message >>>>>>> for >>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>> Version >>>>>>> in the table to keep track of when each entry needs to be deleted, >>>>>>> like what is done in the table of obsolete flags. " >>>>>>> >>>>>>> >>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> You should also answer David's concern. >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>> >>>>>>>>> Comments below. >>>>>>>>> >>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>> Hello again everyone! >>>>>>>>>>> >>>>>>>>>>> Please review this change which adds better error messages for >>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>> >>>>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>>>> vm to >>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>> command >>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>> >>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>> -Xlog:classinit >>>>>>>>>>> instead." >>>>>>>>>>> >>>>>>>>>>> The entire output looks like this: >>>>>>>>>>> >>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>> -Xlog:classinit >>>>>>>>>>> instead. >>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>> >>>>>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>> should >>>>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>>>> flag >>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>> then in >>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>> then >>>>>>>>> remove it for 10. If it would help, we can store a Version in the >>>>>>>>> table to keep track of when each entry needs to be deleted, like >>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>> appropriate >>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>> converted to >>>>>>>>>>> logging. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From Alan.Bateman at oracle.com Sat Mar 19 07:41:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Mar 2016 07:41:36 +0000 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56EC915D.8040004@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> Message-ID: <56ED02B0.9000008@oracle.com> On 18/03/2016 23:38, Claes Redestad wrote: > Hi, > > sorry for being a bit out of the loop, but according to the most > recent published spec[1] I could find the manifest attribute names > needs to be treated case-insensitively. Has JEP-238 made necessary > specification updates to allow deviation from this rule for new > attribute names? Good point, attributes names have always been case insensitive. I don't recall anything in JEP 238 that proposes otherwise. -Alan From coleen.phillimore at oracle.com Sat Mar 19 12:57:18 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 19 Mar 2016 08:57:18 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall Message-ID: <56ED4CAE.7010009@oracle.com> Summary: Deferred code review cleanups This was a review comment I had when the StackWalk API was integrated. There were too many of this same code pattern in the middle of universe_post_init. The only real change here is that if the method isn't found and doesn't have the right linkage because of a mismatch in JDK version, we can vm_exit_during_initialization() rather than try to return JNI_ERR. This avoids ugly code to check initialize_known_method's boolean result for each call. We can't throw an exception here. Because of the EXCEPTION_MARK in universe_post_init, any exception gets turned into vm_exit_during_initialization anyway. But this wouldn't be a user error, so vm_exit_during_initialization seemed like the cleanest choice. Also, I want to get the code to not have to include method names (and field names) in vmSymbols.cpp. I verified that this code won't merge conflict with jigsaw. There are many additional cleanups that can be done here. universe_post_init should really be a method belonging to Universe since it sets many static fields in Universe, but to avoid merge conflicts, I didn't do that. Tested with JPRT and colocated tests. open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8143269 Thanks, Coleen From calvin.cheung at oracle.com Sat Mar 19 17:24:54 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Sat, 19 Mar 2016 10:24:54 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56ED02B0.9000008@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> <56ED02B0.9000008@oracle.com> Message-ID: <56ED8B66.6070900@oracle.com> On 3/19/16, 12:41 AM, Alan Bateman wrote: > > > On 18/03/2016 23:38, Claes Redestad wrote: >> Hi, >> >> sorry for being a bit out of the loop, but according to the most >> recent published spec[1] I could find the manifest attribute names >> needs to be treated case-insensitively. Has JEP-238 made necessary >> specification updates to allow deviation from this rule for new >> attribute names? > Good point, attributes names have always been case insensitive. I > don't recall anything in JEP 238 that proposes otherwise. Currently, the jdk code only honors "Multi-Release" as the attribute name for multi-release jar. I ran the following test: jdk/test/jdk/nio/zipfs/MultiReleaseJarTest.java It created a multi-release.jar. Running the jar file manually: java -cp ./multi-release.jar version.Main gives the following output: I am running on version 9 Then, I expanded the jar file and modified the manifest entry from "Multi-Release" to "multi-Release" and created another jar file. Running the new jar file shows: I am running on version 8 The code in JarFileSystem.java seems to confirm my findings: private boolean isMultiReleaseJar() { try (InputStream is = newInputStream(getBytes("META-INF/MANIFEST.MF"))) { return (new Manifest(is)).getMainAttributes() .containsKey(new Attributes.Name("Multi-Release")); // fixme change line above after JarFile integration to contain Attributes.Name.MULTI_RELEASE } catch (IOException x) { return false; } } To be consistent, I think hotspot should wait until jdk side has a fix to handle case insensitive "Multi-Release" attribute name. What do you think? thanks, Calvin From david.holmes at oracle.com Sun Mar 20 03:12:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 20 Mar 2016 13:12:39 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EB1B6C.4030101@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <56E9E417.3020503@oracle.com> <56EA0BCD.4080106@oracle.com> <56EB1B6C.4030101@oracle.com> Message-ID: <56EE1527.2010408@oracle.com> Can I please get two re-reviews for this second version of the code. (I'm heading off on vacation mid-week and would like to get this in before I go.) Thanks, David On 18/03/2016 7:02 AM, David Holmes wrote: > On 17/03/2016 11:51 PM, Gerard Ziemski wrote: >> David, >> >> If we were to move the initialization code off the startup path, we >> wouldn?t need to bother with this optimization. >> >> I?m in favor of ?defer until needed?, as I suggested earlier, as >> opposed to the ?eagerly initialize? approach taken here. > > That would make things worse. During startup we will call > set_native_thread_name multiple times. > > David > >> >> cheers >> >>> On Mar 16, 2016, at 8:43 PM, David Holmes >>> wrote: >>> >>> Hi James, >>> >>> On 17/03/2016 8:54 AM, james cheng wrote: >>>> Hi David, >>>> >>>> Thanks for implementing this RFE. >>>> >>>> A Solaris Linker guru suggested what we do something like this: >>>> >>>> my_pthread_setname_np(...) >>>> { >>>> static (*fptr)() = NULL; >>>> void *handle; >>>> >>>> if ((fptr == NULL) && >>>> ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) && >>>> ((fptr = dlsym(handle, "pthread_setname_np")) == NULL)) >>>> fptr = noop_setname; >>>> >>>> (*fptr)(...); >>>> } >>>> >>>> So using libc.so.1 without a path should be okay. But I don't see >>>> you have >>>> a null check for the return of dlsym(). >>> >>> We initialize _pthread_setname_np using dlopen+dlsym as above at VM >>> startup - we don't want to do the lookup on each use. The NULL check >>> happens in the actual os::set_native_thread_name() function. >>> >>> Glad to hear using the libc.so.1 path is okay (as we already use it) >>> but was wondering if we can assume /usr/lib/libc.so.1 and so shorten >>> the search time even further? >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> -James >>>> >>>> On 3/15/2016 9:24 PM, David Holmes wrote: >>>>> cc'ing James as initial requestor for this. >>>>> >>>>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>>>> >>>>>>> On Mar 15, 2016, at 4:31 PM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>>> Couldn?t we look it up on as needed basis in the implementation of >>>>>>>> "void os::set_native_thread_name(const char *name)? instead? >>>>>>> >>>>>>> AFAIK we never lookup anything as-needed but always handle it at VM >>>>>>> initialization time. A quick grep will show that we are using >>>>>>> RTLD_DEFAULT in a few places across >>>>>>> different platforms. Elsewhere we know what library we have to >>>>>>> search. I can try finding out which library it should be if you >>>>>>> think that is preferable? >>>>>> >>>>>> Sure, either that or we find out the performance impact on the >>>>>> startup time, so then we can decide if it?s an issue or not. >>>>> >>>>> Some numbers in the bug report. It seems to me if we know the library >>>>> that will contain the symbol then we should just open it. I filed a >>>>> RFE: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>>>> >>>>> to look at use of RTLD_DEFAULT in general. >>>>> >>>>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>>>> >>>>> Not 100% sure whether dlopen should be also relying on the search path >>>>> dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 >>>>> should be hard-wired? I'm not >>>>> familiar enough with solaris library management to know whether we >>>>> will always find libc on that exact path? We have one existing >>>>> /usr/lib/libc.so.1 dlopen on Solaris x86, >>>>> but most dlopens just take the base name. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> thanks >> From kim.barrett at oracle.com Sun Mar 20 04:24:19 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Mar 2016 00:24:19 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E8DFF5.608@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> Message-ID: <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> > On Mar 16, 2016, at 12:24 AM, David Holmes wrote: > > cc'ing James as initial requestor for this. > > On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >> >>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>> >>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>> >>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >> >> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. > > Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: > > https://bugs.openjdk.java.net/browse/JDK-8151953 > > to look at use of RTLD_DEFAULT in general. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ > > Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. A couple of quibbles. Nearly all of the similar places nearby declare a typedef for the function type near the variable, and use that typedef in both the variable declaration and the assignment cast. I found one place in os_solaris.cpp that didn't do that, but the variable declaration and the cast are right next to each other in that case, rather than far apart. Of course, if the cast is wrong, the assignment will fail to compile. Many (but I think not all) of the casts of a dlsym result to a function pointer use CAST_TO_FN_PTR. Functionality looks ok to me. From kim.barrett at oracle.com Sun Mar 20 18:11:19 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Mar 2016 14:11:19 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> Message-ID: <3C1AA7BA-DA77-47EF-A4CB-04C3DDC326A4@oracle.com> > On Mar 20, 2016, at 12:24 AM, Kim Barrett wrote: > > A couple of quibbles. > I forgot to mention: 445 if (Solaris::_pthread_setname_np) { violates the no implicit bools rule from the style guide. From david.holmes at oracle.com Sun Mar 20 21:02:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Mar 2016 07:02:54 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> Message-ID: <56EF0FFE.7040300@oracle.com> Hi Kim, Thanks for taking a look at this. Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ Comments below. On 20/03/2016 2:24 PM, Kim Barrett wrote: >> On Mar 16, 2016, at 12:24 AM, David Holmes wrote: >> >> cc'ing James as initial requestor for this. >> >> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>> >>>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>>> >>>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>>> >>>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >>> >>> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. >> >> Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: >> >> https://bugs.openjdk.java.net/browse/JDK-8151953 >> >> to look at use of RTLD_DEFAULT in general. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >> >> Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. > > A couple of quibbles. > > Nearly all of the similar places nearby declare a typedef for the > function type near the variable, and use that typedef in both the > variable declaration and the assignment cast. I found one place in > os_solaris.cpp that didn't do that, but the variable declaration and > the cast are right next to each other in that case, rather than far > apart. Of course, if the cast is wrong, the assignment will fail to > compile. I added the typedef. Note that I copied this "pattern" from the os_linux.cpp version and on Linux we tend to have fewer dynamic lookups and fewer typedefs. Also I found a range of practices employed in this area on Solaris. For example os_solaris.cpp has this sure enough: typedef struct sigaction *(*get_signal_t)(int); get_signal_t os::Solaris::get_signal_action = NULL; but the os_solaris.hpp header has this: static struct sigaction *(*get_signal_action)(int); so the typedef seems somewhat misplaced. > Many (but I think not all) of the casts of a dlsym result to a > function pointer use CAST_TO_FN_PTR. No not all by any means. There seems to be no rhyme or reason as to when CAST_TO_FN_PTR is used and when it is not. I also can not see what purpose it serves when used in conjunction with dlsym, which returns a void*. With CAST_TO_FN_PTR we go from void* -> uintptr_t -> real-func-ptr-type. I suspect there is some ancient history here. I chose not to change this as it seems pointless. BTW this, arguably, may be the more "correct" approach: ./os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: func = reinterpret_cast(dlsym(_dl_handle, name)); > I forgot to mention: > > 445 if (Solaris::_pthread_setname_np) { > > violates the no implicit bools rule from the style guide. Fixed (also copied from Linux version). > Functionality looks ok to me. Thanks. David From kim.barrett at oracle.com Mon Mar 21 00:01:58 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Mar 2016 20:01:58 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EF0FFE.7040300@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> Message-ID: <5EE90D0A-F876-4729-B504-681A94A92C8E@oracle.com> > On Mar 20, 2016, at 5:02 PM, David Holmes wrote: > > Hi Kim, > > Thanks for taking a look at this. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ Looks good. > Comments below. I may have some followup discussion, but don?t want to hold things up while I think about that, since you said you were going on vacation shortly. From david.holmes at oracle.com Mon Mar 21 00:22:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Mar 2016 10:22:06 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <5EE90D0A-F876-4729-B504-681A94A92C8E@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <5EE90D0A-F876-4729-B504-681A94A92C8E@oracle.com> Message-ID: <56EF3EAE.7050603@oracle.com> On 21/03/2016 10:01 AM, Kim Barrett wrote: >> On Mar 20, 2016, at 5:02 PM, David Holmes wrote: >> >> Hi Kim, >> >> Thanks for taking a look at this. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ > > Looks good. > >> Comments below. > > I may have some followup discussion, but don?t want to hold things up > while I think about that, since you said you were going on vacation shortly. Okay - thanks. David ----- From david.holmes at oracle.com Mon Mar 21 05:12:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Mar 2016 15:12:54 +1000 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56ED4CAE.7010009@oracle.com> References: <56ED4CAE.7010009@oracle.com> Message-ID: <56EF82D6.7020605@oracle.com> Hi Coleen, On 19/03/2016 10:57 PM, Coleen Phillimore wrote: > Summary: Deferred code review cleanups > > This was a review comment I had when the StackWalk API was integrated. > There were too many of this same code pattern in the middle of > universe_post_init. The only real change here is that if the method > isn't found and doesn't have the right linkage because of a mismatch in > JDK version, we can vm_exit_during_initialization() rather than try to > return JNI_ERR. This avoids ugly code to check > initialize_known_method's boolean result for each call. We can't throw > an exception here. Because of the EXCEPTION_MARK in universe_post_init, > any exception gets turned into vm_exit_during_initialization anyway. But > this wouldn't be a user error, so vm_exit_during_initialization seemed > like the cleanest choice. Our initialization code is truly awful. Until the VM is initialized any/all exceptions have to convert back to a different form of error because there will be no thread (or JVM for that matter) on which the user code could ask if an exception occurred. It then comes down to whether an error should be reported to the caller of JNI_CreateJavaVM so the host program doesn't get terminated, or we abort everything with vm_exit_during_initialization. And we're sliding further and further into always doing the latter. So in an absolute sense the new code is incompatible with the old because it will terminate host applications that wouldn't previously have been terminated - but in a practical sense this is unlikely to make any real difference to anything. That said something about all this is really bugging me. If we can do: ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); which purports to allow an exception to have been posted then how is it the immediately following code: ! Method* m = SystemDictionary::Finalizer_klass()->find_method( ! vmSymbols::register_method_name(), ! vmSymbols::register_method_signature()); ! if (m == NULL || !m->is_static()) { ! tty->print_cr("Unable to link/verify Finalizer.register method"); ! return false; // initialization failed (cannot throw exception yet) ! } can not throw an exception yet? Either both can throw or neither can throw AFAICS. So maybe the refactored link() call should not be using CHECK_ but also exit immediately? > Also, I want to get the code to not have to include method names (and > field names) in vmSymbols.cpp. > > I verified that this code won't merge conflict with jigsaw. There are > many additional cleanups that can be done here. universe_post_init > should really be a method belonging to Universe since it sets many > static fields in Universe, but to avoid merge conflicts, I didn't do that. If you do that cleanup some time there are some very inaccurate comments in relation to the initialization code in init.cpp that could do with correcting. And I also spotted two paths to Interpreter::initialize. Thanks, David ----- > > Tested with JPRT and colocated tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8143269 > > Thanks, > Coleen From Alan.Bateman at oracle.com Mon Mar 21 07:19:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 07:19:48 +0000 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56ED8B66.6070900@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> <56ED02B0.9000008@oracle.com> <56ED8B66.6070900@oracle.com> Message-ID: <56EFA094.1020009@oracle.com> On 19/03/2016 17:24, Calvin Cheung wrote: > > : > > To be consistent, I think hotspot should wait until jdk side has a fix > to handle case insensitive "Multi-Release" attribute name. > > What do you think? That should be fine, just make sure to create an issue to JIRA to track it as it is something that could easier get forgotten. -Alan From robbin.ehn at oracle.com Mon Mar 21 08:18:59 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 21 Mar 2016 09:18:59 +0100 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> Message-ID: <56EFAE73.7040106@oracle.com> Hi Cheleswer, On 03/18/2016 08:54 AM, 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. > > 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(const > 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 looks good, thanks for fixing. /Robbin (not a reviewer) (I must admit I'm very curious why anyone would have a thread name that long) > > This will ensure presence of closing quotation mark always. > > Regards, > > Cheleswer > From staffan.larsen at oracle.com Mon Mar 21 08:26:59 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Mar 2016 09:26:59 +0100 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EF0FFE.7040300@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> Message-ID: Still ok with me! /Staffan > On 20 mars 2016, at 22:02, David Holmes wrote: > > Hi Kim, > > Thanks for taking a look at this. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ > > Comments below. > > On 20/03/2016 2:24 PM, Kim Barrett wrote: >>> On Mar 16, 2016, at 12:24 AM, David Holmes wrote: >>> >>> cc'ing James as initial requestor for this. >>> >>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>> >>>>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>>>> >>>>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>>>> >>>>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >>>> >>>> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. >>> >>> Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>> >>> to look at use of RTLD_DEFAULT in general. >>> >>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>> >>> Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. >> >> A couple of quibbles. >> >> Nearly all of the similar places nearby declare a typedef for the >> function type near the variable, and use that typedef in both the >> variable declaration and the assignment cast. I found one place in >> os_solaris.cpp that didn't do that, but the variable declaration and >> the cast are right next to each other in that case, rather than far >> apart. Of course, if the cast is wrong, the assignment will fail to >> compile. > > I added the typedef. Note that I copied this "pattern" from the os_linux.cpp version and on Linux we tend to have fewer dynamic lookups and fewer typedefs. Also I found a range of practices employed in this area on Solaris. For example os_solaris.cpp has this sure enough: > > typedef struct sigaction *(*get_signal_t)(int); > get_signal_t os::Solaris::get_signal_action = NULL; > > but the os_solaris.hpp header has this: > > static struct sigaction *(*get_signal_action)(int); > > so the typedef seems somewhat misplaced. > >> Many (but I think not all) of the casts of a dlsym result to a >> function pointer use CAST_TO_FN_PTR. > > No not all by any means. There seems to be no rhyme or reason as to when CAST_TO_FN_PTR is used and when it is not. I also can not see what purpose it serves when used in conjunction with dlsym, which returns a void*. With CAST_TO_FN_PTR we go from void* -> uintptr_t -> real-func-ptr-type. I suspect there is some ancient history here. I chose not to change this as it seems pointless. > > BTW this, arguably, may be the more "correct" approach: > > ./os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: > func = reinterpret_cast(dlsym(_dl_handle, name)); > >> I forgot to mention: >> >> 445 if (Solaris::_pthread_setname_np) { >> >> violates the no implicit bools rule from the style guide. > > Fixed (also copied from Linux version). > >> Functionality looks ok to me. > > Thanks. > > David > From dmitry.samersoff at oracle.com Mon Mar 21 08:39:45 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 21 Mar 2016 11:39:45 +0300 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EC7506.902@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> Message-ID: <56EFB351.7010707@oracle.com> 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. 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(const >>>>> 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 >>>>> >> >> -- 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 Mar 21 08:53:52 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 21 Mar 2016 09:53:52 +0100 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EFAE73.7040106@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EFAE73.7040106@oracle.com> Message-ID: <56EFB6A0.8090104@oracle.com> Hi, sorry for the unnecessary review, My mail-client spitted the mail thread into two different folders. /Robbin On 03/21/2016 09:18 AM, Robbin Ehn wrote: > Hi Cheleswer, > > On 03/18/2016 08:54 AM, 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. >> >> 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(const >> 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 looks good, thanks for fixing. > > /Robbin (not a reviewer) > > (I must admit I'm very curious why anyone would have a thread name that > long) > >> >> This will ensure presence of closing quotation mark always. >> >> Regards, >> >> Cheleswer >> From rainer.jung at kippdata.de Mon Mar 21 09:05:23 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 21 Mar 2016 10:05:23 +0100 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EFAE73.7040106@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EFAE73.7040106@oracle.com> Message-ID: <56EFB953.3010803@kippdata.de> Am 21.03.2016 um 09:18 schrieb Robbin Ehn: > (I must admit I'm very curious why anyone would have a thread name that > long) Since thread dumps are very useful for problem analysis but only contain stacks but no data, sometimes people switch the thread name on every new workload the thread handles, so that the thread name in the dump contains the info, kind of side-channel to tunnel data into the dump. For example: in a web container one might append the request info (HTTP method, URI, query string, time the request began) with a separator to the original thread name at the beginning of the request, and strip it at the end. So if things hang or get slow and you take a thread dump, the info on what type or request each thread is working is present in that dump. I'm not arguing whether this is a good pattern or not, but I have seen this pattern in production. Still, 1996 characters isn't easily reached even with this pattern. Regards, Rainer From david.holmes at oracle.com Mon Mar 21 09:38:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Mar 2016 19:38:27 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> Message-ID: <56EFC113.3000700@oracle.com> Thanks Staffan! David On 21/03/2016 6:26 PM, Staffan Larsen wrote: > Still ok with me! > > /Staffan > >> On 20 mars 2016, at 22:02, David Holmes wrote: >> >> Hi Kim, >> >> Thanks for taking a look at this. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ >> >> Comments below. >> >> On 20/03/2016 2:24 PM, Kim Barrett wrote: >>>> On Mar 16, 2016, at 12:24 AM, David Holmes wrote: >>>> >>>> cc'ing James as initial requestor for this. >>>> >>>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>>> >>>>>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>>>>> >>>>>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>>>>> >>>>>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >>>>> >>>>> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. >>>> >>>> Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>>> >>>> to look at use of RTLD_DEFAULT in general. >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>>> >>>> Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. >>> >>> A couple of quibbles. >>> >>> Nearly all of the similar places nearby declare a typedef for the >>> function type near the variable, and use that typedef in both the >>> variable declaration and the assignment cast. I found one place in >>> os_solaris.cpp that didn't do that, but the variable declaration and >>> the cast are right next to each other in that case, rather than far >>> apart. Of course, if the cast is wrong, the assignment will fail to >>> compile. >> >> I added the typedef. Note that I copied this "pattern" from the os_linux.cpp version and on Linux we tend to have fewer dynamic lookups and fewer typedefs. Also I found a range of practices employed in this area on Solaris. For example os_solaris.cpp has this sure enough: >> >> typedef struct sigaction *(*get_signal_t)(int); >> get_signal_t os::Solaris::get_signal_action = NULL; >> >> but the os_solaris.hpp header has this: >> >> static struct sigaction *(*get_signal_action)(int); >> >> so the typedef seems somewhat misplaced. >> >>> Many (but I think not all) of the casts of a dlsym result to a >>> function pointer use CAST_TO_FN_PTR. >> >> No not all by any means. There seems to be no rhyme or reason as to when CAST_TO_FN_PTR is used and when it is not. I also can not see what purpose it serves when used in conjunction with dlsym, which returns a void*. With CAST_TO_FN_PTR we go from void* -> uintptr_t -> real-func-ptr-type. I suspect there is some ancient history here. I chose not to change this as it seems pointless. >> >> BTW this, arguably, may be the more "correct" approach: >> >> ./os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: >> func = reinterpret_cast(dlsym(_dl_handle, name)); >> >>> I forgot to mention: >>> >>> 445 if (Solaris::_pthread_setname_np) { >>> >>> violates the no implicit bools rule from the style guide. >> >> Fixed (also copied from Linux version). >> >>> Functionality looks ok to me. >> >> Thanks. >> >> David >> > From kirk at kodewerk.com Mon Mar 21 10:38:17 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Mon, 21 Mar 2016 11:38:17 +0100 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EFB953.3010803@kippdata.de> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EFAE73.7040106@oracle.com> <56EFB953.3010803@kippdata.de> Message-ID: <57E6DDD9-DE2F-4156-8DEB-9D2ED78070F4@kodewerk.com> > On Mar 21, 2016, at 10:05 AM, Rainer Jung wrote: > > Am 21.03.2016 um 09:18 schrieb Robbin Ehn: >> (I must admit I'm very curious why anyone would have a thread name that >> long) I am also curious but that said, if the API allows for it, the tooling should do the right thing with the data. Regards, Kirk From coleen.phillimore at oracle.com Mon Mar 21 14:05:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Mar 2016 10:05:28 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56EF82D6.7020605@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> Message-ID: <56EFFFA8.30600@oracle.com> On 3/21/16 1:12 AM, David Holmes wrote: > Hi Coleen, > > On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >> Summary: Deferred code review cleanups >> >> This was a review comment I had when the StackWalk API was integrated. >> There were too many of this same code pattern in the middle of >> universe_post_init. The only real change here is that if the method >> isn't found and doesn't have the right linkage because of a mismatch in >> JDK version, we can vm_exit_during_initialization() rather than try to >> return JNI_ERR. This avoids ugly code to check >> initialize_known_method's boolean result for each call. We can't throw >> an exception here. Because of the EXCEPTION_MARK in universe_post_init, >> any exception gets turned into vm_exit_during_initialization anyway. But >> this wouldn't be a user error, so vm_exit_during_initialization seemed >> like the cleanest choice. > > Our initialization code is truly awful. Until the VM is initialized > any/all exceptions have to convert back to a different form of error > because there will be no thread (or JVM for that matter) on which the > user code could ask if an exception occurred. It then comes down to > whether an error should be reported to the caller of JNI_CreateJavaVM > so the host program doesn't get terminated, or we abort everything > with vm_exit_during_initialization. And we're sliding further and > further into always doing the latter. > > So in an absolute sense the new code is incompatible with the old > because it will terminate host applications that wouldn't previously > have been terminated - but in a practical sense this is unlikely to > make any real difference to anything. > > That said something about all this is really bugging me. If we can do: > > ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); > > which purports to allow an exception to have been posted then how is > it the immediately following code: > > ! Method* m = SystemDictionary::Finalizer_klass()->find_method( > ! vmSymbols::register_method_name(), > ! vmSymbols::register_method_signature()); > ! if (m == NULL || !m->is_static()) { > ! tty->print_cr("Unable to link/verify Finalizer.register method"); > ! return false; // initialization failed (cannot throw exception yet) > ! } > > can not throw an exception yet? Either both can throw or neither can > throw AFAICS. So maybe the refactored link() call should not be using > CHECK_ but also exit immediately? I don't think we should refactor InstanceKlass::link_class() for this. I can rewrite so that every initialize_known_method call does: bool ok; ok = initialize_known_method(, CHECK); if (!ok) return ok; ok = initialize_known_method(, CHECK); if (!ok) return ok; ... return true; Which I thought was really ugly and meaningless, since as I said, this case is really an assert that the library doesn't match. I could change it to an assert. Which is your preference? This is not my preference. Thanks, Coleen > >> Also, I want to get the code to not have to include method names (and >> field names) in vmSymbols.cpp. >> >> I verified that this code won't merge conflict with jigsaw. There are >> many additional cleanups that can be done here. universe_post_init >> should really be a method belonging to Universe since it sets many >> static fields in Universe, but to avoid merge conflicts, I didn't do >> that. > > If you do that cleanup some time there are some very inaccurate > comments in relation to the initialization code in init.cpp that could > do with correcting. And I also spotted two paths to > Interpreter::initialize. > > Thanks, > David > ----- > >> >> Tested with JPRT and colocated tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >> >> Thanks, >> Coleen From james.cheng at oracle.com Wed Mar 16 22:54:15 2016 From: james.cheng at oracle.com (james cheng) Date: Wed, 16 Mar 2016 15:54:15 -0700 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56E8DFF5.608@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> Message-ID: <56E9E417.3020503@oracle.com> Hi David, Thanks for implementing this RFE. A Solaris Linker guru suggested what we do something like this: my_pthread_setname_np(...) { static (*fptr)() = NULL; void *handle; if ((fptr == NULL) && ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) && ((fptr = dlsym(handle, "pthread_setname_np")) == NULL)) fptr = noop_setname; (*fptr)(...); } So using libc.so.1 without a path should be okay. But I don't see you have a null check for the return of dlsym(). Thanks, -James On 3/15/2016 9:24 PM, David Holmes wrote: > cc'ing James as initial requestor for this. > > On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >> >>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>> >>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>> >>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across >>> different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >> >> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. > > Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: > > https://bugs.openjdk.java.net/browse/JDK-8151953 > > to look at use of RTLD_DEFAULT in general. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ > > Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not > familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, > but most dlopens just take the base name. > > Thanks, > David > ----- > >> >> thanks >> From steve.drach at oracle.com Sat Mar 19 18:02:08 2016 From: steve.drach at oracle.com (Steve Drach) Date: Sat, 19 Mar 2016 11:02:08 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56ED8B66.6070900@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> <56ED02B0.9000008@oracle.com> <56ED8B66.6070900@oracle.com> Message-ID: <05628509-F005-44EE-A897-3281CCE5F2CF@oracle.com> Yes, it?s a bug. I?m currently working on another bug that requires me to change manifest processing. It will be case insensitive. > On Mar 19, 2016, at 10:24 AM, Calvin Cheung wrote: > > > > On 3/19/16, 12:41 AM, Alan Bateman wrote: >> >> >> On 18/03/2016 23:38, Claes Redestad wrote: >>> Hi, >>> >>> sorry for being a bit out of the loop, but according to the most recent published spec[1] I could find the manifest attribute names needs to be treated case-insensitively. Has JEP-238 made necessary specification updates to allow deviation from this rule for new attribute names? >> Good point, attributes names have always been case insensitive. I don't recall anything in JEP 238 that proposes otherwise. > > Currently, the jdk code only honors "Multi-Release" as the attribute name for multi-release jar. > > I ran the following test: jdk/test/jdk/nio/zipfs/MultiReleaseJarTest.java > > It created a multi-release.jar. > Running the jar file manually: > java -cp ./multi-release.jar version.Main > gives the following output: > I am running on version 9 > > Then, I expanded the jar file and modified the manifest entry from "Multi-Release" to "multi-Release" and created another jar file. > Running the new jar file shows: > I am running on version 8 > > The code in JarFileSystem.java seems to confirm my findings: > > private boolean isMultiReleaseJar() { > try (InputStream is = newInputStream(getBytes("META-INF/MANIFEST.MF"))) { > return (new Manifest(is)).getMainAttributes() > .containsKey(new Attributes.Name("Multi-Release")); > // fixme change line above after JarFile integration to contain Attributes.Name.MULTI_RELEASE > } catch (IOException x) { > return false; > } > } > > To be consistent, I think hotspot should wait until jdk side has a fix to handle case insensitive "Multi-Release" attribute name. > > What do you think? > > thanks, > Calvin > From robbin.ehn at oracle.com Mon Mar 21 16:26:21 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 21 Mar 2016 17:26:21 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com> References: <56E952A5.6050708@oracle.com> <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com> <56EA5250.8090001@oracle.com> <2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com> Message-ID: <56F020AD.6000708@oracle.com> Hi Kim, On 03/17/2016 11:33 PM, Kim Barrett wrote: >> On Mar 17, 2016, at 2:44 AM, Robbin Ehn wrote: >> On 03/16/2016 05:13 PM, Kim Barrett wrote: >>>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn wrote: >>>> >>>> Hi, please review this small change. >>>> >>>> This also change allocation methods. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >>>> >>>> Thanks! >>>> >>>> /Robbin >>> >>> ------------------------------------------------------------------------------ >>> src/share/vm/logging/log.hpp >>> Changing this: >>> 138 char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging); >>> to this: >>> 137 char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging); >>> >>> New code is missing out of memory handling that was present in the old >>> code. New code will just try to use newbuf, with bad results if the >>> allocation failed. >> >> Yes >> >>> >>> New code is missing ASSERT-conditionalized PrintMallocFree support >>> that was present in the old. I don't know how important this is, >>> given that we also have PrintMalloc. (And I have to wonder why we >>> have both PrintMalloc (develop) and PrintMallocFree (notproduct).) >>> >>> ------------------------------------------------------------------------------ >>> >> >> I wonder if this is even is the right path, we have 25 hpp including allocation.inline. >> The other ones seem to do their allocation from their inline.hpp file. >> >> Making me believe that we should either ignore this or do log.inline.hpp. >> >> Either way this patch should be dropped, thoughts? > > I don't think ignoring is the right long-term approach, though is > probably ok in the short term. In particular, I think adding > log.inline.hpp would touch a lot of files, which seems like a bad > thing to do just now, with largish changes coming soon that would need > to be merged. And I'm not convinced log.inline.hpp is the right long > term approach anyway. Ok, > > Rather, I prefer Carsten's suggestion of an out of line slow-path > function in a .cpp. This approach is possible, even though we're > dealing with templates, by using type-erasure. The generic > (non-templated) slow-path function would need to receive a couple of > function pointers from the vwrite template, e.g. the prefix and puts > functions that are referenced by the present template code. The > function pointer types don't refer to template parameters, e.g. the > prefix function's type is > > size_t (*prefix_fn)(char*, size_t) > > and puts is > > void (*puts_fn)(LogLevelType, const char*) > > I wanted to avoid introducing a lot of things not directly related to removing the include. Thanks for your input! /Robbin From daniel.daugherty at oracle.com Mon Mar 21 16:31:40 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 21 Mar 2016 10:31:40 -0600 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56EFB351.7010707@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> Message-ID: <56F021EC.4010105@oracle.com> 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); 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(const >>>>>> 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 Mon Mar 21 16:34:11 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 21 Mar 2016 17:34:11 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <56E952A5.6050708@oracle.com> References: <56E952A5.6050708@oracle.com> Message-ID: <56F02283.10908@oracle.com> Hi all, please review this a somewhat bigger change-set. Updated with the feedback. New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ Tested with jprt hotspot and I added 2 internal vm tests. (also 2 bugs fixed, missing va_end and a potential race when calling prefix function twice (very unlikely)) Thanks! /Robbin On 03/16/2016 01:33 PM, Robbin Ehn wrote: > Hi, please review this small change. > > This also change allocation methods. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ > > Thanks! > > /Robbin From ioi.lam at oracle.com Mon Mar 21 16:40:46 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 21 Mar 2016 09:40:46 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <97D60664-1133-4BA5-8D7E-E715CCFADC4B@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> <56EC8980.4050208@oracle.com> <97D60664-1133-4BA5-8D7E-E715CCFADC4B@oracle.com> Message-ID: <56F0240E.5010501@oracle.com> On 3/18/16 6:43 PM, Jiangli Zhou wrote: > Hi Ioi, > >> On Mar 18, 2016, at 4:04 PM, Ioi Lam > > wrote: >> >> >> >> On 3/18/16 11:52 AM, Jiangli Zhou wrote: >>> >>>>> >>>>> The changes look good overall. Following are my comments and >>>>> questions. >>>>> >>>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>>> >>>>> It would be a good idea to assert the address (current pc) is >>>>> within the generated trampoline entry buffer. >>>> I am not sure what this means. Could you explain? >>> >>> >>> We should assert that the address is in the generated trampoline >>> code, but not at a random place in the shared space. If the control >>> dumps to an arbitrary location, it might manifest itself into a bug >>> that?s hard to debug. >> >> I still don't understand where you want to put the assertion. Could >> you tell me which file/function you want to add the assert, and what >> should be put in the assert? > > > For example, assert the pc() is in trampoline code if we get an > address in the shared space in the following code in > JavaThread::pd_get_top_frame(). > > 69 if (UseSharedSpaces && MetaspaceShared::is_in_shared_space(addr.pc())) { > 70 // In the middle of a trampoline call. Bail out for safety. > 71 // This happens rarely so shouldn't affect profiling. > 72 return false; > 73 } > Something like the following? > > assert(addr.pc() >= MetaspaceShared::cds_i2i_entry_code_buffers() && > addr.pc() < MetaspaceShared::cds_i2i_entry_code_buffers() + > MetaspaceShared::cds_i2i_entry_code_buffer_size(), > ?Unexpected"); > The address range you listed is just part of the trampolines (for the "standard" method entries). More trampolines can be allocated here -- these are entries that are associated with specific method signatures. 3021 void CDSAdapterHandlerEntry::init() { 3022 assert(DumpSharedSpaces, "used during dump time only"); 3023 _c2i_entry_trampoline = (address)MetaspaceShared::misc_code_space_alloc(SharedRuntime::trampoline_size()); 3024 _adapter_trampoline = (AdapterHandlerEntry**)MetaspaceShared::misc_data_space_alloc(sizeof(AdapterHandlerEntry*)); 3025 }; In addition, addr.pc() can also be one of the vtable patching methods. So, instead of adding an assert, I think it's better to narrow the check to something like: if (UseSharedSpaces && MetaspaceShared::is_in_shared_misc_code_space(addr.pc())) { [...snip...] >> >>>>> - src/share/vm/oops/method.hpp >>>>> In set_interpreter_entry(), when _i2i_entry and >>>>> _from_interpreted_entry are not the same as ?entry? for shared method? >>>> >>>> The purpose of the check is to avoid writing the same value into >>>> the shared Method (which would cause the pages to be >>>> copied-on-write, even if the value does not change). >>>> >>>> 475 void set_interpreter_entry(address entry) { >>>> 476 if (_i2i_entry != entry) { >>>> 477 _i2i_entry = entry; >>>> 478 } >>>> 479 if (_from_interpreted_entry != entry) { >>>> 480 _from_interpreted_entry = entry; >>>> 481 } >>>> 482 } >>> >>> I see set_interpreter_entry() is called from Method initializing >>> code and link_method(). For a shared method, we should change the if >>> check to be an assert. Would there be any case where the entry is >>> not the same as the one in the shared method? >> >> I am actually not sure if for shared methods the i2i_entry and >> from_interpreter_entry would be set to any other values. E.g., in the >> future, someone may add a new tracing facility that requires >> modifying these 2 fields. >> >> I'd rather play safe so we don't overwrite into the shared Method >> most of the time, but if it does happen it will continue to work. > > This part of the code is more critical. So, we should have a tighter > control of it. If someone is setting the the entry to a different > valve than the one in the Method, we need to know what is the new > entry and understand why. The assertion would force us to exam each > new case like the one you described in the above. Is that reasonable? > Sounds good. I think we should add the assert so we will catch such new cases in non-product builds. But for safety, in product builds, we should set the values as requested. We don't want assumptions made by this optimization to affect functional correctness. 475 void set_interpreter_entry(address entry) { if (is_shared()) { assert(_i2i_entry != entry && _from_interpreted_entry != entry, "must be"); } 476 if (_i2i_entry != entry) { 477 _i2i_entry = entry; 478 } 479 if (_from_interpreted_entry != entry) { 480 _from_interpreted_entry = entry; 481 } 482 } From calvin.cheung at oracle.com Mon Mar 21 17:18:07 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 21 Mar 2016 10:18:07 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56EFA094.1020009@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> <56ED02B0.9000008@oracle.com> <56ED8B66.6070900@oracle.com> <56EFA094.1020009@oracle.com> Message-ID: <56F02CCF.8010000@oracle.com> On 3/21/16, 12:19 AM, Alan Bateman wrote: > > > On 19/03/2016 17:24, Calvin Cheung wrote: >> >> : >> >> To be consistent, I think hotspot should wait until jdk side has a >> fix to handle case insensitive "Multi-Release" attribute name. >> >> What do you think? > That should be fine, just make sure to create an issue to JIRA to > track it as it is something that could easier get forgotten. > I've filed https://bugs.openjdk.java.net/browse/JDK-8152329 to track this issue. thanks, Calvin From jiangli.zhou at oracle.com Mon Mar 21 18:24:24 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 21 Mar 2016 11:24:24 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56F0240E.5010501@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> <56EC8980.4050208@oracle.com> <97D60664-1133-4BA5-8D7E-E715CCFADC4B@oracle.com> <56F0240E.5010501@oracle.com> Message-ID: > On Mar 21, 2016, at 9:40 AM, Ioi Lam wrote: > > > > On 3/18/16 6:43 PM, Jiangli Zhou wrote: >> Hi Ioi, >> >>> On Mar 18, 2016, at 4:04 PM, Ioi Lam > wrote: >>> >>> >>> >>> On 3/18/16 11:52 AM, Jiangli Zhou wrote: >>>> >>>>>> >>>>>> The changes look good overall. Following are my comments and questions. >>>>>> >>>>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>>>> >>>>>> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. >>>>> I am not sure what this means. Could you explain? >>>> >>>> >>>> We should assert that the address is in the generated trampoline code, but not at a random place in the shared space. If the control dumps to an arbitrary location, it might manifest itself into a bug that?s hard to debug. >>> >>> I still don't understand where you want to put the assertion. Could you tell me which file/function you want to add the assert, and what should be put in the assert? >> >> >> For example, assert the pc() is in trampoline code if we get an address in the shared space in the following code in JavaThread::pd_get_top_frame(). >> >> 69 if (UseSharedSpaces && MetaspaceShared::is_in_shared_space(addr.pc())) { >> 70 // In the middle of a trampoline call. Bail out for safety. >> 71 // This happens rarely so shouldn't affect profiling. >> 72 return false; >> 73 } >> Something like the following? >> >> assert(addr.pc() >= MetaspaceShared::cds_i2i_entry_code_buffers() && >> addr.pc() < MetaspaceShared::cds_i2i_entry_code_buffers() + MetaspaceShared::cds_i2i_entry_code_buffer_size(), >> ?Unexpected"); >> > The address range you listed is just part of the trampolines (for the "standard" method entries). More trampolines can be allocated here -- these are entries that are associated with specific method signatures. > > 3021 void CDSAdapterHandlerEntry::init() { > 3022 assert(DumpSharedSpaces, "used during dump time only"); > 3023 _c2i_entry_trampoline = (address)MetaspaceShared::misc_code_space_alloc(SharedRuntime::trampoline_size()); > 3024 _adapter_trampoline = (AdapterHandlerEntry**)MetaspaceShared::misc_data_space_alloc(sizeof(AdapterHandlerEntry*)); > 3025 }; > > In addition, addr.pc() can also be one of the vtable patching methods. > > So, instead of adding an assert, I think it's better to narrow the check to something like: > > if (UseSharedSpaces && MetaspaceShared::is_in_shared_misc_code_space(addr.pc())) { Ok. BTW, one of my comments in first email suggested to not map the ?mc? space RW. We should either allocate the trampoline buffer in the ?md? space. Another solution would be to add a new read-write-executable space for the trampoline code. So the above check would check if the 'add.pc()' is in the ?md? space or the new space. I?m in favor of adding a new read-write-executable space for the runtime generated code. Thanks, Jiangli > > > [...snip...] > >>> >>>>>> - src/share/vm/oops/method.hpp >>>>>> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? >>>>> >>>>> The purpose of the check is to avoid writing the same value into the shared Method (which would cause the pages to be copied-on-write, even if the value does not change). >>>>> >>>>> 475 void set_interpreter_entry(address entry) { >>>>> 476 if (_i2i_entry != entry) { >>>>> 477 _i2i_entry = entry; >>>>> 478 } >>>>> 479 if (_from_interpreted_entry != entry) { >>>>> 480 _from_interpreted_entry = entry; >>>>> 481 } >>>>> 482 } >>>> >>>> I see set_interpreter_entry() is called from Method initializing code and link_method(). For a shared method, we should change the if check to be an assert. Would there be any case where the entry is not the same as the one in the shared method? >>> >>> I am actually not sure if for shared methods the i2i_entry and from_interpreter_entry would be set to any other values. E.g., in the future, someone may add a new tracing facility that requires modifying these 2 fields. >>> >>> I'd rather play safe so we don't overwrite into the shared Method most of the time, but if it does happen it will continue to work. >> >> This part of the code is more critical. So, we should have a tighter control of it. If someone is setting the the entry to a different valve than the one in the Method, we need to know what is the new entry and understand why. The assertion would force us to exam each new case like the one you described in the above. Is that reasonable? >> > Sounds good. I think we should add the assert so we will catch such new cases in non-product builds. But for safety, in product builds, we should set the values as requested. We don't want assumptions made by this optimization to affect functional correctness. > > 475 void set_interpreter_entry(address entry) { > if (is_shared()) { > assert(_i2i_entry != entry && _from_interpreted_entry != entry, "must be"); > } > 476 if (_i2i_entry != entry) { > 477 _i2i_entry = entry; > 478 } > 479 if (_from_interpreted_entry != entry) { > 480 _from_interpreted_entry = entry; > 481 } > 482 } > > From coleen.phillimore at oracle.com Mon Mar 21 21:11:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Mar 2016 17:11:32 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java Message-ID: <56F06384.4060508@oracle.com> Summary: Fix code broken with compact Strings. One of the failure modes of an intermittent bug (but this failure is not intermittent). Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8144940 Thanks, Coleen From ioi.lam at oracle.com Mon Mar 21 21:19:08 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 21 Mar 2016 14:19:08 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> <56EC8980.4050208@oracle.com> <97D60664-1133-4BA5-8D7E-E715CCFADC4B@oracle.com> <56F0240E.5010501@oracle.com> Message-ID: <56F0654C.3020604@oracle.com> On 3/21/16 11:24 AM, Jiangli Zhou wrote: > >> On Mar 21, 2016, at 9:40 AM, Ioi Lam > > wrote: >> >> >> >> On 3/18/16 6:43 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>>> On Mar 18, 2016, at 4:04 PM, Ioi Lam >>> > wrote: >>>> >>>> >>>> >>>> On 3/18/16 11:52 AM, Jiangli Zhou wrote: >>>>> >>>>>>> >>>>>>> The changes look good overall. Following are my comments and >>>>>>> questions. >>>>>>> >>>>>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>>>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>>>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>>>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>>>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>>>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>>>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>>>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>>>>> >>>>>>> It would be a good idea to assert the address (current pc) is >>>>>>> within the generated trampoline entry buffer. >>>>>> I am not sure what this means. Could you explain? >>>>> >>>>> >>>>> We should assert that the address is in the generated trampoline >>>>> code, but not at a random place in the shared space. If the >>>>> control dumps to an arbitrary location, it might manifest itself >>>>> into a bug that?s hard to debug. >>>> >>>> I still don't understand where you want to put the assertion. Could >>>> you tell me which file/function you want to add the assert, and >>>> what should be put in the assert? >>> >>> >>> For example, assert the pc() is in trampoline code if we get an >>> address in the shared space in the following code in >>> JavaThread::pd_get_top_frame(). >>> >>> 69 if (UseSharedSpaces && MetaspaceShared::is_in_shared_space(addr.pc())) { >>> 70 // In the middle of a trampoline call. Bail out for safety. >>> 71 // This happens rarely so shouldn't affect profiling. >>> 72 return false; >>> 73 } >>> Something like the following? >>> >>> assert(addr.pc() >= MetaspaceShared::cds_i2i_entry_code_buffers() && >>> addr.pc() < MetaspaceShared::cds_i2i_entry_code_buffers() >>> + MetaspaceShared::cds_i2i_entry_code_buffer_size(), >>> ?Unexpected"); >>> >> The address range you listed is just part of the trampolines (for the >> "standard" method entries). More trampolines can be allocated here -- >> these are entries that are associated with specific method signatures. >> >> 3021 void CDSAdapterHandlerEntry::init() { >> 3022 assert(DumpSharedSpaces, "used during dump time only"); >> 3023 _c2i_entry_trampoline = >> (address)MetaspaceShared::misc_code_space_alloc(SharedRuntime::trampoline_size()); >> 3024 _adapter_trampoline = >> (AdapterHandlerEntry**)MetaspaceShared::misc_data_space_alloc(sizeof(AdapterHandlerEntry*)); >> 3025 }; >> >> In addition, addr.pc() can also be one of the vtable patching methods. >> >> So, instead of adding an assert, I think it's better to narrow the >> check to something like: >> >> if (UseSharedSpaces && >> MetaspaceShared::is_in_shared_misc_code_space(addr.pc())) { > > Ok. > > BTW, one of my comments in first email suggested to not map the ?mc? > space RW. We should either allocate the trampoline buffer in the ?md? > space. Another solution would be to add a new read-write-executable > space for the trampoline code. So the above check would check if the > 'add.pc()' is in the ?md? space or the new space. I?m in favor of > adding a new read-write-executable space for the runtime generated code. > > That sounds reasonable. Maybe that can be done in a separate RFE, since the changes for trampolines are quite complex already? Thanks - Ioi > Thanks, > Jiangli > >> >> >> [...snip...] >> >>>> >>>>>>> - src/share/vm/oops/method.hpp >>>>>>> In set_interpreter_entry(), when _i2i_entry and >>>>>>> _from_interpreted_entry are not the same as ?entry? for shared >>>>>>> method? >>>>>> >>>>>> The purpose of the check is to avoid writing the same value into >>>>>> the shared Method (which would cause the pages to be >>>>>> copied-on-write, even if the value does not change). >>>>>> >>>>>> 475 void set_interpreter_entry(address entry) { >>>>>> 476 if (_i2i_entry != entry) { >>>>>> 477 _i2i_entry = entry; >>>>>> 478 } >>>>>> 479 if (_from_interpreted_entry != entry) { >>>>>> 480 _from_interpreted_entry = entry; >>>>>> 481 } >>>>>> 482 } >>>>> >>>>> I see set_interpreter_entry() is called from Method initializing >>>>> code and link_method(). For a shared method, we should change the >>>>> if check to be an assert. Would there be any case where the entry >>>>> is not the same as the one in the shared method? >>>> >>>> I am actually not sure if for shared methods the i2i_entry and >>>> from_interpreter_entry would be set to any other values. E.g., in >>>> the future, someone may add a new tracing facility that requires >>>> modifying these 2 fields. >>>> >>>> I'd rather play safe so we don't overwrite into the shared Method >>>> most of the time, but if it does happen it will continue to work. >>> >>> This part of the code is more critical. So, we should have a tighter >>> control of it. If someone is setting the the entry to a different >>> valve than the one in the Method, we need to know what is the new >>> entry and understand why. The assertion would force us to exam each >>> new case like the one you described in the above. Is that reasonable? >>> >> Sounds good. I think we should add the assert so we will catch such >> new cases in non-product builds. But for safety, in product builds, >> we should set the values as requested. We don't want assumptions made >> by this optimization to affect functional correctness. >> >> 475 void set_interpreter_entry(address entry) { >> if (is_shared()) { >> assert(_i2i_entry != entry && _from_interpreted_entry != >> entry, "must be"); >> } >> 476 if (_i2i_entry != entry) { >> 477 _i2i_entry = entry; >> 478 } >> 479 if (_from_interpreted_entry != entry) { >> 480 _from_interpreted_entry = entry; >> 481 } >> 482 } >> >> > From david.holmes at oracle.com Mon Mar 21 21:24:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Mar 2016 07:24:00 +1000 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56F021EC.4010105@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> Message-ID: <56F06670.5030802@oracle.com> 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(const >>>>>>> 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 kim.barrett at oracle.com Mon Mar 21 21:36:08 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Mar 2016 17:36:08 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EF0FFE.7040300@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> Message-ID: <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> > On Mar 20, 2016, at 5:02 PM, David Holmes wrote: > > Hi Kim, > > Thanks for taking a look at this. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ > > Comments below. > > On 20/03/2016 2:24 PM, Kim Barrett wrote: >>> On Mar 16, 2016, at 12:24 AM, David Holmes wrote: >>> >>> cc'ing James as initial requestor for this. >>> >>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>> >>>>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>>>> >>>>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>>>> >>>>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >>>> >>>> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. >>> >>> Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>> >>> to look at use of RTLD_DEFAULT in general. >>> >>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>> >>> Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. >> >> A couple of quibbles. >> >> Nearly all of the similar places nearby declare a typedef for the >> function type near the variable, and use that typedef in both the >> variable declaration and the assignment cast. I found one place in >> os_solaris.cpp that didn't do that, but the variable declaration and >> the cast are right next to each other in that case, rather than far >> apart. Of course, if the cast is wrong, the assignment will fail to >> compile. > > I added the typedef. Note that I copied this "pattern" from the os_linux.cpp version and on Linux we tend to have fewer dynamic lookups and fewer typedefs. Also I found a range of practices employed in this area on Solaris. For example os_solaris.cpp has this sure enough: > > typedef struct sigaction *(*get_signal_t)(int); > get_signal_t os::Solaris::get_signal_action = NULL; > > but the os_solaris.hpp header has this: > > static struct sigaction *(*get_signal_action)(int); > > so the typedef seems somewhat misplaced. > >> Many (but I think not all) of the casts of a dlsym result to a >> function pointer use CAST_TO_FN_PTR. > > No not all by any means. There seems to be no rhyme or reason as to when CAST_TO_FN_PTR is used and when it is not. I also can not see what purpose it serves when used in conjunction with dlsym, which returns a void*. With CAST_TO_FN_PTR we go from void* -> uintptr_t -> real-func-ptr-type. I suspect there is some ancient history here. I chose not to change this as it seems pointless. > > BTW this, arguably, may be the more "correct" approach: > > ./os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: > func = reinterpret_cast(dlsym(_dl_handle, name)); reinterpret_cast (and all the C-style casts involved are really reinterpret_casts) can be used to convert a function pointer to a different function pointer type. It can also be used to convert between any pointer (including function pointers) and (appropriate) integer types. No other conversions involving function pointers are allowed. (C++11 adds "Converting a function pointer to an object pointer type or vice versa is conditionally-supported.") Since void* is not a function pointer type, there's no specified direct conversion from a void* to a function pointer. That's the raison d'etre for CAST_TO_FN_PTR. (Although conversion to an integer then to some other type (not back to the original type) and then use is implementation-defined.) However, it seems that some compilers (including the Solaris versions we've been using) allow direct void* -> function pointer conversions. From ioi.lam at oracle.com Mon Mar 21 21:51:30 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 21 Mar 2016 14:51:30 -0700 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F06384.4060508@oracle.com> References: <56F06384.4060508@oracle.com> Message-ID: <56F06CE2.4010205@oracle.com> Hi Coleen, Just to double check that my understanding is correct -- the code that you added affects only non-product builds, when the string table is verified. There's no impact on the lookup or insertion of the StringTable. If that's the case, the changes look good to me. It's a little slower than before, but it only slows down non-product builds. Thanks - Ioi On 3/21/16 2:11 PM, Coleen Phillimore wrote: > Summary: Fix code broken with compact Strings. > > One of the failure modes of an intermittent bug (but this failure is > not intermittent). > > Tested with the failing test cases that exercise this code. Also, > testing in order to find linked bugs. > > open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8144940 > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Mar 21 23:05:04 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Mar 2016 19:05:04 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F06CE2.4010205@oracle.com> References: <56F06384.4060508@oracle.com> <56F06CE2.4010205@oracle.com> Message-ID: <56F07E20.8090300@oracle.com> On 3/21/16 5:51 PM, Ioi Lam wrote: > Hi Coleen, > > Just to double check that my understanding is correct -- the code that > you added affects only non-product builds, when the string table is > verified. There's no impact on the lookup or insertion of the > StringTable. Yes, it is only verification code, which is enabled in product builds but is not turned on by default unless you use one of the Verify{Before,After,During}GC or VerifyBeforeExit options. > > If that's the case, the changes look good to me. It's a little slower > than before, but it only slows down non-product builds. Yes, I guess it is but it has to be correct. String::intern() uses the unicode representation of the string for the hash. Thanks! Coleen > > Thanks > - Ioi > > On 3/21/16 2:11 PM, Coleen Phillimore wrote: >> Summary: Fix code broken with compact Strings. >> >> One of the failure modes of an intermittent bug (but this failure is >> not intermittent). >> >> Tested with the failing test cases that exercise this code. Also, >> testing in order to find linked bugs. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >> >> Thanks, >> Coleen > From jiangli.zhou at Oracle.COM Mon Mar 21 23:39:44 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Mon, 21 Mar 2016 16:39:44 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56EC409A.1070202@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56EB8E8E.4020209@oracle.com> <56EC409A.1070202@oracle.com> Message-ID: <8FDCFA83-1844-4B39-9A3B-E7FCC0BA0A49@oracle.com> Hi Calvin, > On Mar 18, 2016, at 10:53 AM, Calvin Cheung wrote: > > Hi Jiangli, > > Thanks for your quick review. > > Let me try to answer the remaining questions below. > > On 3/17/16, 10:13 PM, Ioi Lam wrote: >> Hi Jiangli, >> >> Since I wrote some of the original code, I'll try to answer some of the questions below >> >> On 3/17/16 9:37 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> The changes look good overall. Following are my comments and questions. >>> >>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>> Please place the new CDS-only code under #if INCLUDE_CDS. >>> >>> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. >> I am not sure what this means. Could you explain? >>> >>> - src/share/vm/interpreter/abstractInterpreter.cpp >>> It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. > I'll fix that. >>> >>> - src/share/vm/memory/metaspaceShared.cpp >>> I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. > But putting code in the md region and making md region executable is confusing too. > I'd prefer leaving it as is for now. Ok. How about adding a new region for the trampoline code, or separating the ?mc? into to ?writable? and ?non-writable? regions? I refer to not making the entire ?mc? region writable. Thanks, Jiangli >>> >>> - src/share/vm/oops/method.cpp >>> Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >> We can change the code to >> >> assert(DumpSharedSpaces, "..."); >> // Set the values to what they should be at run time. Note that >> // this Method can no longer be executed during dump time. >> _i2i_entry = Interpreter::entry_for_cds_method(this); >> _from_interpreted_entry = _i2i_entry; >> >> I think unlink_method used to be called during run time as well. See this assert later in unlink_method >> >> // In case of DumpSharedSpaces, _method_data should always be NULL. >> // >> // During runtime (!DumpSharedSpaces), when we are cleaning a >> // shared class that failed to load, this->link_method() may >> // have already been called (before an exception happened), so >> // this->_method_data may not be NULL. >> assert(!DumpSharedSpaces || _method_data == NULL, "unexpected method data?"); >> >> So we need to remove the "!DumpSharedSpaces ||" and fix the comments. >>> - src/share/vm/oops/method.hpp >>> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? >> >> The purpose of the check is to avoid writing the same value into the shared Method (which would cause the pages to be copied-on-write, even if the value does not change). >> >> 475 void set_interpreter_entry(address entry) { >> 476 if (_i2i_entry != entry) { >> 477 _i2i_entry = entry; >> 478 } >> 479 if (_from_interpreted_entry != entry) { >> 480 _from_interpreted_entry = entry; >> 481 } >> 482 } >> >>> - src/share/vm/runtime/sharedRuntime.cpp >>> Please add a comment for the change at line 2537 >>> 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { > I believe this is for handling the case when compiler is disabled during dumping. > I'll work with Ioi to come up with some comments. >>> - src/share/vm/oops/constMethod.hpp >>> >>> ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. >> >> The pointer ConstMethod::_adapter_trampoline never changes at run time. Only the content pointed to by _adapter_trampoline can change. >> >> Thanks >> - Ioi >>> Do you have estimate about the size increase with the generated trampolines for the shared methods? > IIRC, the CDSAdapterHandlerEntry::init() is being called around 670 times during dump time using the default classlist. So for 64-bit, the size increase for md is around 50k. > > thanks, > Calvin >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung wrote: >>>> >>>> Dean, Ioi, >>>> >>>> Thanks for the review and discussions. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>> >>>> Changes in this webrev: >>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >>>> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>> >>>> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>>> >>>> Testing: >>>> JPRT with testset hotspot >>>> jtreg tests under hotspot/runtime on all platforms >>>> >>>> thanks, >>>> Calvin >>>> >>>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>>> >>>> >>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>> >>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>> Hi Ioi, comments inlined below. >>>>>> >>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>> Hi Dean, >>>>>>> >>>>>>> Thanks for raising this issue. >>>>>>> >>>>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>>>> >>>>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>>>> >>>>>> OK, so you're saying that the trampolines don't make things any worse :-) >>>>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>>>> >>>>>>> (gdb) x/5i 0x802400000 >>>>>>> 0x802400000: mov $0x0,%eax >>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>> 0x802400014: mov $0x2,%eax >>>>>>> .... >>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>> 0x8024084d0: push %rsi >>>>>>> 0x8024084d1: push %rdi >>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>> 0x8024084ed: pop %rdi >>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>> 0x8024084ff: pop %rsi >>>>>>> 0x802408500: mov (%rax),%rax >>>>>>> 0x802408503: jmpq *%rax >>>>>>> >>>>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>>>> >>>>>>> (gdb) where >>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>> isInJava=true) >>>>>>> >>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>>>> >>>>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>>>> >>>>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> dl >>>>>> >>>>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>>>> >>>>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>>>> >>>>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>> >>>>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>>>> >>>>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com). >>>>>>>>> I helped porting it to other platforms. >>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided the changes to the ppc platform. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT with testset hotspot >>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>> built on the Zero platform >>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >> From david.holmes at oracle.com Tue Mar 22 00:00:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Mar 2016 10:00:39 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> Message-ID: <56F08B27.9000604@oracle.com> On 22/03/2016 7:36 AM, Kim Barrett wrote: >> On Mar 20, 2016, at 5:02 PM, David Holmes wrote: >> >> Hi Kim, >> >> Thanks for taking a look at this. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ >> >> Comments below. >> >> On 20/03/2016 2:24 PM, Kim Barrett wrote: >>>> On Mar 16, 2016, at 12:24 AM, David Holmes wrote: >>>> >>>> cc'ing James as initial requestor for this. >>>> >>>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote: >>>>> >>>>>> On Mar 15, 2016, at 4:31 PM, David Holmes wrote: >>>>>> >>>>>>> Couldn?t we look it up on as needed basis in the implementation of "void os::set_native_thread_name(const char *name)? instead? >>>>>> >>>>>> AFAIK we never lookup anything as-needed but always handle it at VM initialization time. A quick grep will show that we are using RTLD_DEFAULT in a few places across different platforms. Elsewhere we know what library we have to search. I can try finding out which library it should be if you think that is preferable? >>>>> >>>>> Sure, either that or we find out the performance impact on the startup time, so then we can decide if it?s an issue or not. >>>> >>>> Some numbers in the bug report. It seems to me if we know the library that will contain the symbol then we should just open it. I filed a RFE: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8151953 >>>> >>>> to look at use of RTLD_DEFAULT in general. >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/ >>>> >>>> Not 100% sure whether dlopen should be also relying on the search path dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1 should be hard-wired? I'm not familiar enough with solaris library management to know whether we will always find libc on that exact path? We have one existing /usr/lib/libc.so.1 dlopen on Solaris x86, but most dlopens just take the base name. >>> >>> A couple of quibbles. >>> >>> Nearly all of the similar places nearby declare a typedef for the >>> function type near the variable, and use that typedef in both the >>> variable declaration and the assignment cast. I found one place in >>> os_solaris.cpp that didn't do that, but the variable declaration and >>> the cast are right next to each other in that case, rather than far >>> apart. Of course, if the cast is wrong, the assignment will fail to >>> compile. >> >> I added the typedef. Note that I copied this "pattern" from the os_linux.cpp version and on Linux we tend to have fewer dynamic lookups and fewer typedefs. Also I found a range of practices employed in this area on Solaris. For example os_solaris.cpp has this sure enough: >> >> typedef struct sigaction *(*get_signal_t)(int); >> get_signal_t os::Solaris::get_signal_action = NULL; >> >> but the os_solaris.hpp header has this: >> >> static struct sigaction *(*get_signal_action)(int); >> >> so the typedef seems somewhat misplaced. >> >>> Many (but I think not all) of the casts of a dlsym result to a >>> function pointer use CAST_TO_FN_PTR. >> >> No not all by any means. There seems to be no rhyme or reason as to when CAST_TO_FN_PTR is used and when it is not. I also can not see what purpose it serves when used in conjunction with dlsym, which returns a void*. With CAST_TO_FN_PTR we go from void* -> uintptr_t -> real-func-ptr-type. I suspect there is some ancient history here. I chose not to change this as it seems pointless. >> >> BTW this, arguably, may be the more "correct" approach: >> >> ./os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp: >> func = reinterpret_cast(dlsym(_dl_handle, name)); > > reinterpret_cast (and all the C-style casts involved are really > reinterpret_casts) can be used to convert a function pointer to a > different function pointer type. It can also be used to convert > between any pointer (including function pointers) and (appropriate) > integer types. No other conversions involving function pointers are > allowed. (C++11 adds "Converting a function pointer to an object > pointer type or vice versa is conditionally-supported.") > > Since void* is not a function pointer type, there's no specified > direct conversion from a void* to a function pointer. That's the > raison d'etre for CAST_TO_FN_PTR. (Although conversion to an integer > then to some other type (not back to the original type) and then use > is implementation-defined.) > > However, it seems that some compilers (including the Solaris versions > we've been using) allow direct void* -> function pointer conversions. I thought any pointer type could be converted to void* and back again? David From david.holmes at oracle.com Tue Mar 22 02:07:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Mar 2016 12:07:11 +1000 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56EFFFA8.30600@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> Message-ID: <56F0A8CF.4090502@oracle.com> On 22/03/2016 12:05 AM, Coleen Phillimore wrote: > On 3/21/16 1:12 AM, David Holmes wrote: >> Hi Coleen, >> >> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>> Summary: Deferred code review cleanups >>> >>> This was a review comment I had when the StackWalk API was integrated. >>> There were too many of this same code pattern in the middle of >>> universe_post_init. The only real change here is that if the method >>> isn't found and doesn't have the right linkage because of a mismatch in >>> JDK version, we can vm_exit_during_initialization() rather than try to >>> return JNI_ERR. This avoids ugly code to check >>> initialize_known_method's boolean result for each call. We can't throw >>> an exception here. Because of the EXCEPTION_MARK in universe_post_init, >>> any exception gets turned into vm_exit_during_initialization anyway. But >>> this wouldn't be a user error, so vm_exit_during_initialization seemed >>> like the cleanest choice. >> >> Our initialization code is truly awful. Until the VM is initialized >> any/all exceptions have to convert back to a different form of error >> because there will be no thread (or JVM for that matter) on which the >> user code could ask if an exception occurred. It then comes down to >> whether an error should be reported to the caller of JNI_CreateJavaVM >> so the host program doesn't get terminated, or we abort everything >> with vm_exit_during_initialization. And we're sliding further and >> further into always doing the latter. >> >> So in an absolute sense the new code is incompatible with the old >> because it will terminate host applications that wouldn't previously >> have been terminated - but in a practical sense this is unlikely to >> make any real difference to anything. >> >> That said something about all this is really bugging me. If we can do: >> >> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >> >> which purports to allow an exception to have been posted then how is >> it the immediately following code: >> >> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >> ! vmSymbols::register_method_name(), >> ! vmSymbols::register_method_signature()); >> ! if (m == NULL || !m->is_static()) { >> ! tty->print_cr("Unable to link/verify Finalizer.register method"); >> ! return false; // initialization failed (cannot throw exception yet) >> ! } >> >> can not throw an exception yet? Either both can throw or neither can >> throw AFAICS. So maybe the refactored link() call should not be using >> CHECK_ but also exit immediately? > > I don't think we should refactor InstanceKlass::link_class() for this. I wasn't suggesting that. As I said either both bits of code can throw exceptions or neither can, and I would have to assume it is the latter. link_class can be replaced by link_class_or_fail ie this: ik->link_class(CHECK); TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); Method* m = ik->find_method(name, signature); if (m == NULL || is_static != m->is_static()) { ResourceMark rm(THREAD); vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s method", ik->name()->as_C_string(), method)); } becomes (hope I get this right): TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); Method* m = NULL; if (!ik->link_class_or_fail(THREAD) || ((m = ik->find_method(name, signature)) == NULL) || is_static != m->is_static()) { ResourceMark rm(THREAD); vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s method", ik->name()->as_C_string(), method)); } The CHECK on new_symbol is still a pretense but ... > I can rewrite so that every initialize_known_method call does: > > bool ok; > ok = initialize_known_method(, CHECK); > if (!ok) return ok; > > ok = initialize_known_method(, CHECK); > if (!ok) return ok; > > ... > > return true; > > Which I thought was really ugly and meaningless, since as I said, this > case is really an assert that the library doesn't match. I'm not sure why you are suggesting that. It would only make sense if if there were no vm_exit_during_initialization. ?? It would be interesting to see exactly when java_lang_Class is linked in relation to this code executing, so we could see when it would be possible to just throw the exceptions in all cases. Pity there seems to be no logging for class linking. > I could change it to an assert. > > Which is your preference? This is not my preference. I'm not sure what you would assert and where ?? Thanks, David > Thanks, > Coleen >> >>> Also, I want to get the code to not have to include method names (and >>> field names) in vmSymbols.cpp. >>> >>> I verified that this code won't merge conflict with jigsaw. There are >>> many additional cleanups that can be done here. universe_post_init >>> should really be a method belonging to Universe since it sets many >>> static fields in Universe, but to avoid merge conflicts, I didn't do >>> that. >> >> If you do that cleanup some time there are some very inaccurate >> comments in relation to the initialization code in init.cpp that could >> do with correcting. And I also spotted two paths to >> Interpreter::initialize. >> >> Thanks, >> David >> ----- >> >>> >>> Tested with JPRT and colocated tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>> >>> Thanks, >>> Coleen > From kim.barrett at oracle.com Tue Mar 22 03:21:43 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Mar 2016 23:21:43 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56F08B27.9000604@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> <56F08B27.9000604@oracle.com> Message-ID: <1779D36F-2CD1-4509-B273-C76377A98DE3@oracle.com> > On Mar 21, 2016, at 8:00 PM, David Holmes wrote: >> >> reinterpret_cast (and all the C-style casts involved are really >> reinterpret_casts) can be used to convert a function pointer to a >> different function pointer type. It can also be used to convert >> between any pointer (including function pointers) and (appropriate) >> integer types. No other conversions involving function pointers are >> allowed. (C++11 adds "Converting a function pointer to an object >> pointer type or vice versa is conditionally-supported.") >> >> Since void* is not a function pointer type, there's no specified >> direct conversion from a void* to a function pointer. That's the >> raison d'etre for CAST_TO_FN_PTR. (Although conversion to an integer >> then to some other type (not back to the original type) and then use >> is implementation-defined.) >> >> However, it seems that some compilers (including the Solaris versions >> we've been using) allow direct void* -> function pointer conversions. > > I thought any pointer type could be converted to void* and back again? Only for object pointers, not for function pointers. Note, however, that the POSIX description of dlsym says (in the non-normative ?Application Usage? section): Note that conversion from a void * pointer to a function pointer as in: fptr = (int (*)(int))dlsym(handle, "my_function"); is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations. I only noticed this today. So maybe CAST_TO_FN_PTR is not needed in Unix/POSIX-specific code? Unfortunately, the description of CAST_TO_FN_PTR is kind of vague, so it?s unclear who the culprit(s) that led to it might be. It would be easy enough to simplify the macro definition and see if any currently supported compilers complain. And there are only 136 occurrences to clean up if that becomes a thing to do. From kim.barrett at oracle.com Tue Mar 22 03:32:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Mar 2016 23:32:34 -0400 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <56F02283.10908@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> Message-ID: <5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com> > On Mar 21, 2016, at 12:34 PM, Robbin Ehn wrote: > > Hi all, please review this a somewhat bigger change-set. > > Updated with the feedback. > > New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ > > Tested with jprt hotspot and I added 2 internal vm tests. > > (also 2 bugs fixed, missing va_end and a potential race when calling prefix function twice (very unlikely)) I prefer this new approach to what was in the original RFR. A few comments: ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp 91 class LogWrite : AllStatic { I think the name LogWrite is too generic and potentially useful in the future for this facility. I'd prefer something longer and more descriptive, e.g. something like LogWriteLarge{Impl,Helper}. ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp 89 // Non-template helper class for implementing write-slowpath in cpp 90 template class Log; 91 class LogWrite : AllStatic { 92 private: 93 template friend class Log; The really long lines and lack of whitespace here makes this hard to read and confusing. It took several tries for me to spot the "class Log" on line 90 and on line 93. Only knowing that the LogWrite class and the write_large function couldn't possibly have template specs eventually helped me find them. So I think it would help readability to break up the declarations into shorter lines with the "[friend] class Log" parts on their own line, with some whitespace around them. And attach the "Non-template helper class" comment to the LogWrite class rather than the forward declaration. Aside: I keep wishing there were some macros for the various template parameter sequences that are really just workarounds for the lack of variadic templates. But that's a different problem. ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp 95 static void write_large(LogTagSet& lts, Passing in the tagset is much better than my suggestion of some function pointers. Good. ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp 156 va_end(saved_args); Good catch. ------------------------------------------------------------------------------ src/share/vm/logging/log.cpp Thanks for new tests. However, I'm not sure it's safe to assume we can create and remove files from the current directory when running these tests. Maybe mkstemp with a file in os::get_temp_directory()? Or maybe there's something like this already packaged up in hotspot? tmpfile would be ideal if there were a way to configure logging to use a file descriptor, but I don't see anything like that. ------------------------------------------------------------------------------ src/share/vm/logging/log.hpp 148 int msg_len = os::log_vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args); 149 assert(msg_len >= 0, "Log message buffer issue"); I think I would prefer the pre-change int res = ...; assert(res >= 0, ...); followed by size_t msg_len = res; and eliminate the casts of msg_len. But I dislike casts... ------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Mar 22 04:13:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Mar 2016 14:13:49 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <1779D36F-2CD1-4509-B273-C76377A98DE3@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> <56F08B27.9000604@oracle.com> <1779D36F-2CD1-4509-B273-C76377A98DE3@oracle.com> Message-ID: <56F0C67D.5060306@oracle.com> On 22/03/2016 1:21 PM, Kim Barrett wrote: >> On Mar 21, 2016, at 8:00 PM, David Holmes wrote: >>> >>> reinterpret_cast (and all the C-style casts involved are really >>> reinterpret_casts) can be used to convert a function pointer to a >>> different function pointer type. It can also be used to convert >>> between any pointer (including function pointers) and (appropriate) >>> integer types. No other conversions involving function pointers are >>> allowed. (C++11 adds "Converting a function pointer to an object >>> pointer type or vice versa is conditionally-supported.") >>> >>> Since void* is not a function pointer type, there's no specified >>> direct conversion from a void* to a function pointer. That's the >>> raison d'etre for CAST_TO_FN_PTR. (Although conversion to an integer >>> then to some other type (not back to the original type) and then use >>> is implementation-defined.) >>> >>> However, it seems that some compilers (including the Solaris versions >>> we've been using) allow direct void* -> function pointer conversions. >> >> I thought any pointer type could be converted to void* and back again? > > Only for object pointers, not for function pointers. Ah! > Note, however, that the POSIX description of dlsym says (in the non-normative ?Application Usage? section): > > Note that conversion from a void * pointer to a function pointer as in: > > fptr = (int (*)(int))dlsym(handle, "my_function"); > > is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations. > > I only noticed this today. So maybe CAST_TO_FN_PTR is not needed in Unix/POSIX-specific code? You pre-empted my next question: given dlsym returns void* and has to be converted to a function ptr there would have to be some legal way to achieve this. :) Kind of interesting though that POSIX puts an obligation on the compiler writer. Looking at the C standard, given any function-ptr can be converted to another type of function-ptr and back without change, it seems to me that the return type of dlsym (and related library calls) should be void(*)(void) to be strictly correct wrt the language standards. But in practice as long as pointers are all the same size (which seems the obvious and common implementation [ but by no means guaranteed ]) then the conversion works correctly with no actual changes to the bits. > Unfortunately, the description of CAST_TO_FN_PTR is kind of vague, so it?s unclear who the culprit(s) that led to it might be. It would be easy enough to simplify the macro definition and see if any currently supported compilers complain. And there are only 136 occurrences to clean up if that becomes a thing to do. The comment seems clear enough, though without naming problematic compilers: // // ANSI C++ does not allow casting from one pointer type to a function pointer // directly without at best a warning. This macro accomplishes it silently // In every case that is present at this point the value be cast is a pointer // to a C linkage function. In some case the type used for the cast reflects // that linkage and a picky compiler would not complain. In other cases because // there is no convenient place to place a typedef with extern C linkage (i.e // a platform dependent header file) it doesn't. At this point no compiler seems // picky enough to catch these instances (which are few). It is possible that // using templates could fix these for all cases. This use of templates is likely // so far from the middle of the road that it is likely to be problematic in // many C++ compilers. // but that dates back to pre-1999 so ... :) In any case it seems CAST_TO_FN_PTR is really for shared code and in platform specific code we should know whether supported compilers have an issue or not. Of course it would have been better to have been consistent about this throughout the codebase, but when writing platform-specific code it is rarely obvious when something like CAST_TO_FN_PTR is needed, if the "obvious" coding pattern works. Just for fun I'll do a JPRT run to see if anything complains if CAST_TO_FN_PTR(type,val) simply does ((type)(val)). Cheers, David From tobias.hartmann at oracle.com Tue Mar 22 08:04:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Mar 2016 09:04:10 +0100 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F06384.4060508@oracle.com> References: <56F06384.4060508@oracle.com> Message-ID: <56F0FC7A.1000708@oracle.com> Hi Coleen, On 21.03.2016 22:11, Coleen Phillimore wrote: > Summary: Fix code broken with compact Strings. > > One of the failure modes of an intermittent bug (but this failure is not intermittent). > > Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. > > open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8144940 I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? Now we don't need the StringTable::hash_string version anymore, right? Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. Thanks for fixing this! Best regards, Tobias > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Mar 22 12:18:37 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 08:18:37 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56F0A8CF.4090502@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> <56F0A8CF.4090502@oracle.com> Message-ID: <56F1381D.7040009@oracle.com> Hi David, Thank you for reviewing. On 3/21/16 10:07 PM, David Holmes wrote: > On 22/03/2016 12:05 AM, Coleen Phillimore wrote: >> On 3/21/16 1:12 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>>> Summary: Deferred code review cleanups >>>> >>>> This was a review comment I had when the StackWalk API was integrated. >>>> There were too many of this same code pattern in the middle of >>>> universe_post_init. The only real change here is that if the method >>>> isn't found and doesn't have the right linkage because of a >>>> mismatch in >>>> JDK version, we can vm_exit_during_initialization() rather than try to >>>> return JNI_ERR. This avoids ugly code to check >>>> initialize_known_method's boolean result for each call. We can't >>>> throw >>>> an exception here. Because of the EXCEPTION_MARK in >>>> universe_post_init, >>>> any exception gets turned into vm_exit_during_initialization >>>> anyway. But >>>> this wouldn't be a user error, so vm_exit_during_initialization seemed >>>> like the cleanest choice. >>> >>> Our initialization code is truly awful. Until the VM is initialized >>> any/all exceptions have to convert back to a different form of error >>> because there will be no thread (or JVM for that matter) on which the >>> user code could ask if an exception occurred. It then comes down to >>> whether an error should be reported to the caller of JNI_CreateJavaVM >>> so the host program doesn't get terminated, or we abort everything >>> with vm_exit_during_initialization. And we're sliding further and >>> further into always doing the latter. >>> >>> So in an absolute sense the new code is incompatible with the old >>> because it will terminate host applications that wouldn't previously >>> have been terminated - but in a practical sense this is unlikely to >>> make any real difference to anything. >>> >>> That said something about all this is really bugging me. If we can do: >>> >>> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >>> >>> which purports to allow an exception to have been posted then how is >>> it the immediately following code: >>> >>> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >>> ! vmSymbols::register_method_name(), >>> ! vmSymbols::register_method_signature()); >>> ! if (m == NULL || !m->is_static()) { >>> ! tty->print_cr("Unable to link/verify Finalizer.register method"); >>> ! return false; // initialization failed (cannot throw exception >>> yet) >>> ! } >>> >>> can not throw an exception yet? Either both can throw or neither can >>> throw AFAICS. So maybe the refactored link() call should not be using >>> CHECK_ but also exit immediately? >> >> I don't think we should refactor InstanceKlass::link_class() for this. > > I wasn't suggesting that. As I said either both bits of code can throw > exceptions or neither can, and I would have to assume it is the > latter. link_class can be replaced by link_class_or_fail ie this: > > ik->link_class(CHECK); > TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); > Method* m = ik->find_method(name, signature); > if (m == NULL || is_static != m->is_static()) { > ResourceMark rm(THREAD); > vm_exit_during_initialization(err_msg("Unable to link/verify > %s.%s method", > ik->name()->as_C_string(), method)); > } > > becomes (hope I get this right): > > TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); > Method* m = NULL; > if (!ik->link_class_or_fail(THREAD) || > ((m = ik->find_method(name, signature)) == NULL) || > is_static != m->is_static()) { > ResourceMark rm(THREAD); > vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s > method", > ik->name()->as_C_string(), method)); > } > > The CHECK on new_symbol is still a pretense but ... > Yes, the CHECK in link_class is also a pretense. I added some dummy code to throw a VerifyError and it got the assertion: # assert(resolved_method->method_holder()->is_linked()) failed: must be linked From trying to call the Throwable.. I thought we had fixed the jvm to handle this better. I think the code I had is easier to read, but in appreciation for your code reviews, I've changed it to your if statement and retested. http://cr.openjdk.java.net/~coleenp/8143269.02/webrev >> I can rewrite so that every initialize_known_method call does: >> >> bool ok; >> ok = initialize_known_method(, CHECK); >> if (!ok) return ok; >> >> ok = initialize_known_method(, CHECK); >> if (!ok) return ok; >> >> ... >> >> return true; >> >> Which I thought was really ugly and meaningless, since as I said, this >> case is really an assert that the library doesn't match. > > I'm not sure why you are suggesting that. It would only make sense if > if there were no vm_exit_during_initialization. ?? Right, which I thought was the objection. > > It would be interesting to see exactly when java_lang_Class is linked > in relation to this code executing, so we could see when it would be > possible to just throw the exceptions in all cases. Pity there seems > to be no logging for class linking. > >> I could change it to an assert. >> >> Which is your preference? This is not my preference. > > I'm not sure what you would assert and where ?? > I meant a fatal() call instead of vm_exit_during_initialization() since the case that I'm calling it is an error in the JVM, not really from a users perspective. And YES, initialization is a messy business. Kim filed this bug a while ago for one aspect of initialization. Throwing exceptions and/or returning JNI_ERR is another aspect that makes it messy. Returning JNI_ERR to some process embedding the JVM means that we've cleaned up memory that we've allocated, of course, we haven't done that. I think we have other bugs like that too. https://bugs.openjdk.java.net/browse/JDK-8068392 Thanks, Coleen > Thanks, > David > >> Thanks, >> Coleen >>> >>>> Also, I want to get the code to not have to include method names (and >>>> field names) in vmSymbols.cpp. >>>> >>>> I verified that this code won't merge conflict with jigsaw. There are >>>> many additional cleanups that can be done here. universe_post_init >>>> should really be a method belonging to Universe since it sets many >>>> static fields in Universe, but to avoid merge conflicts, I didn't do >>>> that. >>> >>> If you do that cleanup some time there are some very inaccurate >>> comments in relation to the initialization code in init.cpp that could >>> do with correcting. And I also spotted two paths to >>> Interpreter::initialize. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Tested with JPRT and colocated tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>>> >>>> Thanks, >>>> Coleen >> From robbin.ehn at oracle.com Tue Mar 22 12:25:34 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 22 Mar 2016 13:25:34 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp In-Reply-To: <5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> <5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com> Message-ID: <56F139BE.6010605@oracle.com> Hi Kim, On 03/22/2016 04:32 AM, Kim Barrett wrote: >> On Mar 21, 2016, at 12:34 PM, Robbin Ehn wrote: >> >> Hi all, please review this a somewhat bigger change-set. >> >> Updated with the feedback. >> >> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ >> >> Tested with jprt hotspot and I added 2 internal vm tests. >> >> (also 2 bugs fixed, missing va_end and a potential race when calling prefix function twice (very unlikely)) > > I prefer this new approach to what was in the original RFR. A few > comments: > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > 91 class LogWrite : AllStatic { > > I think the name LogWrite is too generic and potentially useful in the > future for this facility. I'd prefer something longer and more > descriptive, e.g. something like LogWriteLarge{Impl,Helper}. Fixed > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > 89 // Non-template helper class for implementing write-slowpath in cpp > 90 template class Log; > 91 class LogWrite : AllStatic { > 92 private: > 93 template friend class Log; > > The really long lines and lack of whitespace here makes this hard to > read and confusing. It took several tries for me to spot the "class > Log" on line 90 and on line 93. Only knowing that the LogWrite class > and the write_large function couldn't possibly have template specs > eventually helped me find them. > > So I think it would help readability to break up the declarations into > shorter lines with the "[friend] class Log" parts on their own line, > with some whitespace around them. And attach the "Non-template helper > class" comment to the LogWrite class rather than the forward > declaration. Fixed > > Aside: I keep wishing there were some macros for the various template > parameter sequences that are really just workarounds for the lack of > variadic templates. But that's a different problem. > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > 95 static void write_large(LogTagSet& lts, > > Passing in the tagset is much better than my suggestion of some > function pointers. Good. > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > 156 va_end(saved_args); > > Good catch. > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.cpp > > Thanks for new tests. However, I'm not sure it's safe to assume we can > create and remove files from the current directory when running these > tests. Maybe mkstemp with a file in os::get_temp_directory()? Or maybe > there's something like this already packaged up in hotspot? tmpfile > would be ideal if there were a way to configure logging to use a file > descriptor, but I don't see anything like that. I used "os::get_temp_directory()" but generated 'naive' filename using pid and test name. Using mkstemp and from fd lookup filename we need os dependent code, so I skipped this. (we could use tempnam in this case, but it creates a warning since it's deprecated) > > ------------------------------------------------------------------------------ > src/share/vm/logging/log.hpp > 148 int msg_len = os::log_vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args); > 149 assert(msg_len >= 0, "Log message buffer issue"); > > I think I would prefer the pre-change > > int res = ...; > assert(res >= 0, ...); > > followed by > > size_t msg_len = res; > > and eliminate the casts of msg_len. But I dislike casts... Fixed > > ------------------------------------------------------------------------------ > Here is the webrev: http://cr.openjdk.java.net/~rehn/8151993/v3/webrev/ Btw what's the normal workflow creating incrementals using hg mq ? Thanks ! /Robbin From coleen.phillimore at oracle.com Tue Mar 22 12:40:20 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 08:40:20 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F0FC7A.1000708@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> Message-ID: <56F13D34.9020202@oracle.com> On 3/22/16 4:04 AM, Tobias Hartmann wrote: > Hi Coleen, > > On 21.03.2016 22:11, Coleen Phillimore wrote: >> Summary: Fix code broken with compact Strings. >> >> One of the failure modes of an intermittent bug (but this failure is not intermittent). >> >> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 > I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? Yes, I believe it is. > > Now we don't need the StringTable::hash_string version anymore, right? This one is used by Symbol* which are jbyte. > Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. Thank you, I'll remove it. > > Thanks for fixing this! Thanks for reviewing it! Coleen > > Best regards, > Tobias > >> Thanks, >> Coleen From paul.sandoz at oracle.com Tue Mar 22 13:19:58 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 22 Mar 2016 14:19:58 +0100 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <05628509-F005-44EE-A897-3281CCE5F2CF@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56EC6D36.6000109@oracle.com> <56EC915D.8040004@oracle.com> <56ED02B0.9000008@oracle.com> <56ED8B66.6070900@oracle.com> <05628509-F005-44EE-A897-3281CCE5F2CF@oracle.com> Message-ID: > On 19 Mar 2016, at 19:02, Steve Drach wrote: > > Yes, it?s a bug. Not quite sure why that is failing within JarFile given the Attributes.MULTI_RELEASE Name instance is used as the key isMultiRelease = result = (man != null) && man.getMainAttributes().containsKey(MULTI_RELEASE) ? Boolean.TRUE : Boolean.FALSE; Or even the following should work: new Attributes.Name("Multi-Release?) since the Attributes.Name.equals/hashCode operate with case insensitivity. What am i missing? > I?m currently working on another bug that requires me to change manifest processing. It will be case insensitive. > But it has to be consistent with look up using Attributes.MULTI_RELEASE or new Attributes.Name("Multi-Release?). Also, the value of the ?Multi-Release? attribute is not important, it?s the presence of that attribute name in the manifest that signals whether the JAR is a MR-JAR or not, the value is ignored. Paul. From gerard.ziemski at oracle.com Tue Mar 22 14:00:45 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Mar 2016 09:00:45 -0500 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56EF0FFE.7040300@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> Message-ID: <50227666-E7AF-4CEE-9788-3A3EE28F2F3C@oracle.com> Looks good. Thank you again for implementing this and taking the time to look into the optimization. cheers > On Mar 20, 2016, at 4:02 PM, David Holmes wrote: > > Hi Kim, > > Thanks for taking a look at this. > > Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ From rachel.protacio at oracle.com Tue Mar 22 14:08:54 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 22 Mar 2016 10:08:54 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL Message-ID: <56F151F6.70804@oracle.com> Hello, Please review this fix removing PrintOopAddress as a command line flag. The printing functionality has been made default, except for one block which has been removed (see bug description for justification). A compatibility request has been accepted with respect to this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ Passes JPRT and RBT hotspot and non-colo testing. Thank you, Rachel From harold.seigel at oracle.com Tue Mar 22 14:23:47 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 10:23:47 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call Message-ID: <56F15573.6090508@oracle.com> Hi, Please review this small change to fix bug 8140665. Instead of asserting or getting a SIGSEGV when trying to define an anonymous class when the host class is a primitive type, this fix throws an IllegalArgumentException. Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 The fix was tested with JCK Lang and VM java_lang tests, the UTE non-collated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util and JFR JTreg tests, and the test included in this RFR. Thanks, Harold From robbin.ehn at oracle.com Tue Mar 22 14:24:39 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 22 Mar 2016 15:24:39 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56EBFCCC.1080701@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> Message-ID: <56F155A7.7060609@oracle.com> Hi Marcus, On 03/18/2016 02:04 PM, Marcus Larsson wrote: > Updated patch after feedback. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ > > Tested with internal VM tests through RBT. > > Changes: > * Rotation filecount is now limited to 1000 files. > * Removed loop in os::compare_file_modified_times. > * Added a check before rotating/truncating an existing log file, and > will only do so if it's a regular file. > * Added test case to check that logging to a directory gives the > intended error message. > * Fixed test help method to handle arbitrary length log lines. I tested this and it works fine. Code looks good to me. Thanks for fixing this! /Robbin > > Thanks, > Marcus > > On 03/11/2016 03:21 PM, Marcus Larsson wrote: >> Third time's the charm. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >> >> This patch makes log file rotation the default. Default thresholds are >> 5 rotated files with a target size of 20MiB. Truncating behavior can >> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >> >> If a log file already exists during log file initialization it will be >> rotated. If any of the target file names (file.0 to file.4 in the >> default case) are available, that filename will be used for the >> existing log. If all names are taken the VM will attempt to overwrite >> the oldest file. >> >> This should prevent unlimited log file creations and avoid accidental >> loss of log files from previous runs. The default thresholds (5 files, >> 20MiB each) is just a suggestion. If you think it should be >> higher/lower let me know. >> >> Tested with included internal VM tests through RBT. >> >> Thanks, >> Marcus >> >> On 2016-03-01 15:05, Marcus Larsson wrote: >>> Hi, >>> >>> After some offline discussions I'm withdrawing this patch. I will >>> instead investigate if I can achieve similar behavior using log >>> rotation as the default. >>> >>> Thanks, >>> Marcus >>> >>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Taking a different approach to this. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>> >>>> Existing files will now by default be renamed/archived with a .X >>>> suffix where X is the lowest number such that the resulting file >>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>> controlling this behavior has been added as well. It can be set to >>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>> >>>> Tested with included jtreg test through JPRT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to make sure UL truncates >>>>> existing log files before writing to them. Since files are opened >>>>> in append mode, truncation isn't done automatically, so instead the >>>>> patch adds an attempt to remove the log file before opening it. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>> >>>>> Testing: >>>>> Included test through JPRT >>>>> >>>>> Thanks, >>>>> Marcus >>>> >>> >> > From karen.kinnear at oracle.com Tue Mar 22 14:57:04 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 22 Mar 2016 10:57:04 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: <56F15573.6090508@oracle.com> References: <56F15573.6090508@oracle.com> Message-ID: <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> Harold, Thank you for fixing this. Looks good. One question - 1. If you were to pass in a null host_class in product - what happens? The way I read the resolve_non_null, it asserts in debug that you did not pass in a null, which suggests to me that it assumes we have already made that check. I would expect and if (host_class == NULL) || ? 0> IllegalArgumentException ? thanks, Karen > On Mar 22, 2016, at 10:23 AM, harold seigel wrote: > > Hi, > > Please review this small change to fix bug 8140665. > > Instead of asserting or getting a SIGSEGV when trying to define an anonymous class when the host class is a primitive type, this fix throws an IllegalArgumentException. > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 > > The fix was tested with JCK Lang and VM java_lang tests, the UTE non-collated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util and JFR JTreg tests, and the test included in this RFR. > > Thanks, Harold From harold.seigel at oracle.com Tue Mar 22 15:19:17 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 11:19:17 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> References: <56F15573.6090508@oracle.com> <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> Message-ID: <56F16275.5090508@oracle.com> Hi Karen, Thanks for looking at the changes. The JDK caller of Unsafe_DefineAnonymousClass_impl() is in java.base/share/classes/jdk/internal/misc/Unsafe.java. It checks for NULL args and throws NPE: public Class defineAnonymousClass(Class hostClass, byte[] data, Object[] cpPatches) { if (hostClass == null || data == null) { throw new NullPointerException(); } return defineAnonymousClass0(hostClass, data, cpPatches); } If somehow a null host_class was passed to Unsafe_DefineAnonymousClass_impl() then it would probably seg fault in product. Perhaps that's okay because it is an Unsafe_... API. Thanks, Harold On 3/22/2016 10:57 AM, Karen Kinnear wrote: > Harold, > > Thank you for fixing this. Looks good. > > One question - > > 1. If you were to pass in a null host_class in product - what happens? > The way I read the resolve_non_null, it asserts in debug that you did not pass in a null, which suggests to me that it assumes > we have already made that check. I would expect and if (host_class == NULL) || ? 0> IllegalArgumentException ? > > thanks, > Karen > >> On Mar 22, 2016, at 10:23 AM, harold seigel wrote: >> >> Hi, >> >> Please review this small change to fix bug 8140665. >> >> Instead of asserting or getting a SIGSEGV when trying to define an anonymous class when the host class is a primitive type, this fix throws an IllegalArgumentException. >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 >> >> The fix was tested with JCK Lang and VM java_lang tests, the UTE non-collated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util and JFR JTreg tests, and the test included in this RFR. >> >> Thanks, Harold From coleen.phillimore at oracle.com Tue Mar 22 15:36:36 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 11:36:36 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: <56F16275.5090508@oracle.com> References: <56F15573.6090508@oracle.com> <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> <56F16275.5090508@oracle.com> Message-ID: <56F16684.8060704@oracle.com> Hi Harold, This looks good but a single line comment that primitive types have NULL Klass* fields in their java.lang.Class instances would be helpful, especially if this is changed in the future. Since the hostClass is checked in the caller, my vote is to not add another check in the vm. In the test, is there going to be another way to get to Unsafe in the future, or present? Thanks, Coleen On 3/22/16 11:19 AM, harold seigel wrote: > Hi Karen, > > Thanks for looking at the changes. The JDK caller of > Unsafe_DefineAnonymousClass_impl() is in > java.base/share/classes/jdk/internal/misc/Unsafe.java. It checks for > NULL args and throws NPE: > > public Class defineAnonymousClass(Class hostClass, byte[] > data, Object[] cpPatches) { > if (hostClass == null || data == null) { > throw new NullPointerException(); > } > return defineAnonymousClass0(hostClass, data, cpPatches); > } > > If somehow a null host_class was passed to > Unsafe_DefineAnonymousClass_impl() then it would probably seg fault in > product. Perhaps that's okay because it is an Unsafe_... API. > > Thanks, Harold > > On 3/22/2016 10:57 AM, Karen Kinnear wrote: >> Harold, >> >> Thank you for fixing this. Looks good. >> >> One question - >> >> 1. If you were to pass in a null host_class in product - what happens? >> The way I read the resolve_non_null, it asserts in debug that you did >> not pass in a null, which suggests to me that it assumes >> we have already made that check. I would expect and if (host_class == >> NULL) || ? 0> IllegalArgumentException ? >> >> thanks, >> Karen >> >>> On Mar 22, 2016, at 10:23 AM, harold seigel >>> wrote: >>> >>> Hi, >>> >>> Please review this small change to fix bug 8140665. >>> >>> Instead of asserting or getting a SIGSEGV when trying to define an >>> anonymous class when the host class is a primitive type, this fix >>> throws an IllegalArgumentException. >>> >>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 >>> >>> The fix was tested with JCK Lang and VM java_lang tests, the UTE >>> non-collated quick tests, and the hotspot, JDK vm, java/io, >>> java/lang, java/util and JFR JTreg tests, and the test included in >>> this RFR. >>> >>> Thanks, Harold > From marcus.larsson at oracle.com Tue Mar 22 15:49:06 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 22 Mar 2016 16:49:06 +0100 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56F155A7.7060609@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> <56F155A7.7060609@oracle.com> Message-ID: <56F16972.9010306@oracle.com> Thanks for reviewing, Robbin! Marcus On 03/22/2016 03:24 PM, Robbin Ehn wrote: > Hi Marcus, > > On 03/18/2016 02:04 PM, Marcus Larsson wrote: >> Updated patch after feedback. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ >> >> Tested with internal VM tests through RBT. >> >> Changes: >> * Rotation filecount is now limited to 1000 files. >> * Removed loop in os::compare_file_modified_times. >> * Added a check before rotating/truncating an existing log file, and >> will only do so if it's a regular file. >> * Added test case to check that logging to a directory gives the >> intended error message. >> * Fixed test help method to handle arbitrary length log lines. > > I tested this and it works fine. > > Code looks good to me. > > Thanks for fixing this! > > /Robbin > >> >> Thanks, >> Marcus >> >> On 03/11/2016 03:21 PM, Marcus Larsson wrote: >>> Third time's the charm. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>> >>> This patch makes log file rotation the default. Default thresholds are >>> 5 rotated files with a target size of 20MiB. Truncating behavior can >>> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >>> >>> If a log file already exists during log file initialization it will be >>> rotated. If any of the target file names (file.0 to file.4 in the >>> default case) are available, that filename will be used for the >>> existing log. If all names are taken the VM will attempt to overwrite >>> the oldest file. >>> >>> This should prevent unlimited log file creations and avoid accidental >>> loss of log files from previous runs. The default thresholds (5 files, >>> 20MiB each) is just a suggestion. If you think it should be >>> higher/lower let me know. >>> >>> Tested with included internal VM tests through RBT. >>> >>> Thanks, >>> Marcus >>> >>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>> Hi, >>>> >>>> After some offline discussions I'm withdrawing this patch. I will >>>> instead investigate if I can achieve similar behavior using log >>>> rotation as the default. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>> Hi again, >>>>> >>>>> Taking a different approach to this. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>> >>>>> Existing files will now by default be renamed/archived with a .X >>>>> suffix where X is the lowest number such that the resulting file >>>>> name is available (jvm.log becomes jvm.log.0). A mode option for >>>>> controlling this behavior has been added as well. It can be set to >>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>> >>>>> Tested with included jtreg test through JPRT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to make sure UL truncates >>>>>> existing log files before writing to them. Since files are opened >>>>>> in append mode, truncation isn't done automatically, so instead the >>>>>> patch adds an attempt to remove the log file before opening it. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>> >>>>>> Testing: >>>>>> Included test through JPRT >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>> >>>> >>> >> From harold.seigel at oracle.com Tue Mar 22 15:59:48 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 11:59:48 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: <56F16684.8060704@oracle.com> References: <56F15573.6090508@oracle.com> <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> <56F16275.5090508@oracle.com> <56F16684.8060704@oracle.com> Message-ID: <56F16BF4.6040208@oracle.com> Hi Coleen, Thanks for the review. I'll add the comment. I don't know about future plans for accessing Unsafe. Harold On 3/22/2016 11:36 AM, Coleen Phillimore wrote: > > Hi Harold, This looks good but a single line comment that primitive > types have NULL Klass* fields in their java.lang.Class instances would > be helpful, especially if this is changed in the future. > > Since the hostClass is checked in the caller, my vote is to not add > another check in the vm. > > In the test, is there going to be another way to get to Unsafe in the > future, or present? > > Thanks, > Coleen > > > On 3/22/16 11:19 AM, harold seigel wrote: >> Hi Karen, >> >> Thanks for looking at the changes. The JDK caller of >> Unsafe_DefineAnonymousClass_impl() is in >> java.base/share/classes/jdk/internal/misc/Unsafe.java. It checks for >> NULL args and throws NPE: >> >> public Class defineAnonymousClass(Class hostClass, byte[] >> data, Object[] cpPatches) { >> if (hostClass == null || data == null) { >> throw new NullPointerException(); >> } >> return defineAnonymousClass0(hostClass, data, cpPatches); >> } >> >> If somehow a null host_class was passed to >> Unsafe_DefineAnonymousClass_impl() then it would probably seg fault >> in product. Perhaps that's okay because it is an Unsafe_... API. >> >> Thanks, Harold >> >> On 3/22/2016 10:57 AM, Karen Kinnear wrote: >>> Harold, >>> >>> Thank you for fixing this. Looks good. >>> >>> One question - >>> >>> 1. If you were to pass in a null host_class in product - what happens? >>> The way I read the resolve_non_null, it asserts in debug that you >>> did not pass in a null, which suggests to me that it assumes >>> we have already made that check. I would expect and if (host_class >>> == NULL) || ? 0> IllegalArgumentException ? >>> >>> thanks, >>> Karen >>> >>>> On Mar 22, 2016, at 10:23 AM, harold seigel >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review this small change to fix bug 8140665. >>>> >>>> Instead of asserting or getting a SIGSEGV when trying to define an >>>> anonymous class when the host class is a primitive type, this fix >>>> throws an IllegalArgumentException. >>>> >>>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 >>>> >>>> The fix was tested with JCK Lang and VM java_lang tests, the UTE >>>> non-collated quick tests, and the hotspot, JDK vm, java/io, >>>> java/lang, java/util and JFR JTreg tests, and the test included in >>>> this RFR. >>>> >>>> Thanks, Harold >> > From coleen.phillimore at oracle.com Tue Mar 22 16:09:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 12:09:59 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F151F6.70804@oracle.com> References: <56F151F6.70804@oracle.com> Message-ID: <56F16E57.2060507@oracle.com> Hi Rachel, http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html I think the line *-if (PrintOopAddress)print_address_on(st);* should be removed. For the case of a String that is in output for logging, it doesn't seem like it adds anything and then you wouldn't have to change the tests. Thanks, Coleen On 3/22/16 10:08 AM, Rachel Protacio wrote: > Hello, > > Please review this fix removing PrintOopAddress as a command line > flag. The printing functionality has been made default, except for one > block which has been removed (see bug description for justification). > A compatibility request has been accepted with respect to this change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ > > Passes JPRT and RBT hotspot and non-colo testing. > > Thank you, > Rachel From tobias.hartmann at oracle.com Tue Mar 22 16:21:19 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Mar 2016 17:21:19 +0100 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F13D34.9020202@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> Message-ID: <56F170FF.5040101@oracle.com> Hi Coleen, On 22.03.2016 13:40, Coleen Phillimore wrote: > On 3/22/16 4:04 AM, Tobias Hartmann wrote: >> Hi Coleen, >> >> On 21.03.2016 22:11, Coleen Phillimore wrote: >>> Summary: Fix code broken with compact Strings. >>> >>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>> >>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? > > Yes, I believe it is. Okay, thanks for checking. >> Now we don't need the StringTable::hash_string version anymore, right? > > This one is used by Symbol* which are jbyte. I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. >> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. > > Thank you, I'll remove it. Thanks! Best regards, Tobias >> >> Thanks for fixing this! > > Thanks for reviewing it! > Coleen >> >> Best regards, >> Tobias >> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Tue Mar 22 16:50:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 12:50:57 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F170FF.5040101@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> Message-ID: <56F177F1.8000005@oracle.com> On 3/22/16 12:21 PM, Tobias Hartmann wrote: > Hi Coleen, > > On 22.03.2016 13:40, Coleen Phillimore wrote: >> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>> Hi Coleen, >>> >>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>> Summary: Fix code broken with compact Strings. >>>> >>>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>>> >>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? >> Yes, I believe it is. > Okay, thanks for checking. > >>> Now we don't need the StringTable::hash_string version anymore, right? >> This one is used by Symbol* which are jbyte. > I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. You're right. I was thinking of hash_symbol. Thanks! Coleen > >>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. >> Thank you, I'll remove it. > Thanks! > > Best regards, > Tobias > >>> Thanks for fixing this! >> Thanks for reviewing it! >> Coleen >>> Best regards, >>> Tobias >>> >>>> Thanks, >>>> Coleen From max.ockner at oracle.com Tue Mar 22 16:52:48 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 22 Mar 2016 12:52:48 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56ECBB5B.9070008@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> <56ECBB5B.9070008@oracle.com> Message-ID: <56F17860.3020604@oracle.com> Thanks David. I have another webrev which moved the delcaration of "replacement" inside of the #ifndef PRODUCT. http://cr.openjdk.java.net/~mockner/8146632.03/ Max On 3/18/2016 10:37 PM, David Holmes wrote: > Objections withdrawn. Code Reviewed. > > Thanks, > David > > On 19/03/2016 7:49 AM, David Holmes wrote: >> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >>> >>> >>> On 3/18/16 8:45 AM, David Holmes wrote: >>>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>>> version in >>>>>>> the table might be helpful for documentation purposes so we know in >>>>>>> the >>>>>>> future when to remove the line from the table. I agree with your >>>>>>> implementation choice to have an additional table rather than >>>>>>> twisting >>>>>>> the other table to cover this use case. >>>>>> >>>>>> I don't I'm afraid - it is yet another special case and no automatic >>>>>> dropping of the message when we switch to JDK 10. Can't it be folded >>>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>>> conversion of the non-product flags to UL has to be handled >>>>>> differently to the product ones ?? >>>>> >>>>> The deprecation of non-product flags has always been different than >>>>> product flags. The AliasedLogging flags alias the old option with >>>>> the >>>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>>> removed. Non-product flags can be removed without deprecation. This >>>>> new >>>>> table is just to improve the error message temporarily for >>>>> non-product >>>>> flags. >>>>> >>>>> It can't be handled with the aliased logging flag table because they >>>>> convert the option. It is the intent to remove these options. >>>>>> >>>>>> Aren't these just deprecated flags? We internally convert them to >>>>>> their replacement form and issue a warning that they are going away? >>>>> >>>>> The intent was to make a nice error message for the non-product >>>>> flags we >>>>> removed to help internal users. i thought you agreed to this in >>>>> concept. >>>> >>>> Concept yes but I'm frustrated by the mechanism - we have too many >>>> special cases with all this option processing, and too many tables. >>>> >>>> As you said above non-product flags can be removed without >>>> deprecation, but all deprecation does is produce a nice error message >>>> when you use the flag, and you want to add a nice error message for >>>> this case so you have in fact turned it back into a deprecation! >>> >>> Deprecation is ignore and run the JVM. This is going to exit the JVM >>> with unrecognized option with a nicer message. >> >> So it is a special case of "expired" which means it isn't really expired >> because the VM still has to know about it. Hence >> yet-another-kind-of-flag. >> >> Seems to me this would all be a lot simpler if we treated the >> non-product flags the same as product and just aliased and deprecated >> them in 9, then expire in 10. There seems to be no benefit in what we >> are doing only added complexity. >> >> David >> >>> Coleen >>>> >>>> David >>>> >>>>> Coleen >>>>> >>>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think Harold's refactoring makes sense and I think the #endif // >>>>>>> PRODUCT >>>>>>> >>>>>>> } >>>>>>> *+ #ifndef PRODUCT* >>>>>>> *+ else if ((replacement = >>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>> stripped_argname, >>>>>>> replacement);* >>>>>>> *+ return false;* >>>>>>> *+ #endif* >>>>>>> *+ }* >>>>>>> >>>>>>> >>>>>>> I think this should be like this so the {} match inside of #ifndef >>>>>>> PRODUCT: >>>>>>> >>>>>>> *+ #ifndef PRODUCT* >>>>>>> *+ } else if ((replacement = >>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>> stripped_argname, >>>>>>> replacement);* >>>>>>> *+ return false;* >>>>>>> *+ #endif* >>>>>>> *+ }* >>>>>>> >>>>>>> >>>>>>> Or refactor as Harold suggested. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>>> I did, but it blended in with the rest of the text >>>>>>>> >>>>>>>> My response: "Seems appropriate to report a specific error message >>>>>>>> for >>>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>>> Version >>>>>>>> in the table to keep track of when each entry needs to be deleted, >>>>>>>> like what is done in the table of obsolete flags. " >>>>>>>> >>>>>>>> >>>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> You should also answer David's concern. >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>>> >>>>>>>>>> Comments below. >>>>>>>>>> >>>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>>> Hello again everyone! >>>>>>>>>>>> >>>>>>>>>>>> Please review this change which adds better error messages for >>>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>>> >>>>>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>>>>> vm to >>>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>>> command >>>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>>> >>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>> instead." >>>>>>>>>>>> >>>>>>>>>>>> The entire output looks like this: >>>>>>>>>>>> >>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>> instead. >>>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>>> >>>>>>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>>> should >>>>>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>>>>> flag >>>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>>> then in >>>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>>> then >>>>>>>>>> remove it for 10. If it would help, we can store a Version in >>>>>>>>>> the >>>>>>>>>> table to keep track of when each entry needs to be deleted, like >>>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>>> appropriate >>>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>>> converted to >>>>>>>>>>>> logging. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> From harold.seigel at oracle.com Tue Mar 22 17:04:04 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 13:04:04 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F07E20.8090300@oracle.com> References: <56F06384.4060508@oracle.com> <56F06CE2.4010205@oracle.com> <56F07E20.8090300@oracle.com> Message-ID: <56F17B04.5020204@oracle.com> Hi Coleen, The changes look good. Harold On 3/21/2016 7:05 PM, Coleen Phillimore wrote: > > > On 3/21/16 5:51 PM, Ioi Lam wrote: >> Hi Coleen, >> >> Just to double check that my understanding is correct -- the code >> that you added affects only non-product builds, when the string table >> is verified. There's no impact on the lookup or insertion of the >> StringTable. > > Yes, it is only verification code, which is enabled in product builds > but is not turned on by default unless you use one of the > Verify{Before,After,During}GC or VerifyBeforeExit options. >> >> If that's the case, the changes look good to me. It's a little slower >> than before, but it only slows down non-product builds. > > Yes, I guess it is but it has to be correct. String::intern() uses > the unicode representation of the string for the hash. > > Thanks! > Coleen >> >> Thanks >> - Ioi >> >> On 3/21/16 2:11 PM, Coleen Phillimore wrote: >>> Summary: Fix code broken with compact Strings. >>> >>> One of the failure modes of an intermittent bug (but this failure is >>> not intermittent). >>> >>> Tested with the failing test cases that exercise this code. Also, >>> testing in order to find linked bugs. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Tue Mar 22 17:07:52 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 13:07:52 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F170FF.5040101@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> Message-ID: <56F17BE8.1010407@oracle.com> Here's another webrev with the changes pointed out by Tobias and verified with -XX:+VerifyStringTableAtExit. open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev Thanks! Coleen On 3/22/16 12:21 PM, Tobias Hartmann wrote: > Hi Coleen, > > On 22.03.2016 13:40, Coleen Phillimore wrote: >> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>> Hi Coleen, >>> >>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>> Summary: Fix code broken with compact Strings. >>>> >>>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>>> >>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? >> Yes, I believe it is. > Okay, thanks for checking. > >>> Now we don't need the StringTable::hash_string version anymore, right? >> This one is used by Symbol* which are jbyte. > I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. > >>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. >> Thank you, I'll remove it. > Thanks! > > Best regards, > Tobias > >>> Thanks for fixing this! >> Thanks for reviewing it! >> Coleen >>> Best regards, >>> Tobias >>> >>>> Thanks, >>>> Coleen From coleen.phillimore at oracle.com Tue Mar 22 17:15:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 13:15:05 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F17B04.5020204@oracle.com> References: <56F06384.4060508@oracle.com> <56F06CE2.4010205@oracle.com> <56F07E20.8090300@oracle.com> <56F17B04.5020204@oracle.com> Message-ID: <56F17D99.5060009@oracle.com> Thanks Harold! Coleen On 3/22/16 1:04 PM, harold seigel wrote: > Hi Coleen, > > The changes look good. > > Harold > > On 3/21/2016 7:05 PM, Coleen Phillimore wrote: >> >> >> On 3/21/16 5:51 PM, Ioi Lam wrote: >>> Hi Coleen, >>> >>> Just to double check that my understanding is correct -- the code >>> that you added affects only non-product builds, when the string >>> table is verified. There's no impact on the lookup or insertion of >>> the StringTable. >> >> Yes, it is only verification code, which is enabled in product builds >> but is not turned on by default unless you use one of the >> Verify{Before,After,During}GC or VerifyBeforeExit options. >>> >>> If that's the case, the changes look good to me. It's a little >>> slower than before, but it only slows down non-product builds. >> >> Yes, I guess it is but it has to be correct. String::intern() uses >> the unicode representation of the string for the hash. >> >> Thanks! >> Coleen >>> >>> Thanks >>> - Ioi >>> >>> On 3/21/16 2:11 PM, Coleen Phillimore wrote: >>>> Summary: Fix code broken with compact Strings. >>>> >>>> One of the failure modes of an intermittent bug (but this failure >>>> is not intermittent). >>>> >>>> Tested with the failing test cases that exercise this code. Also, >>>> testing in order to find linked bugs. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>> >>>> Thanks, >>>> Coleen >>> >> > From harold.seigel at oracle.com Tue Mar 22 17:24:58 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 13:24:58 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56F1381D.7040009@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> <56F0A8CF.4090502@oracle.com> <56F1381D.7040009@oracle.com> Message-ID: <56F17FEA.8070809@oracle.com> Hi Coleen, Your latest changes look good. Thanks, Harold On 3/22/2016 8:18 AM, Coleen Phillimore wrote: > > Hi David, > Thank you for reviewing. > > On 3/21/16 10:07 PM, David Holmes wrote: >> On 22/03/2016 12:05 AM, Coleen Phillimore wrote: >>> On 3/21/16 1:12 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>>>> Summary: Deferred code review cleanups >>>>> >>>>> This was a review comment I had when the StackWalk API was >>>>> integrated. >>>>> There were too many of this same code pattern in the middle of >>>>> universe_post_init. The only real change here is that if the method >>>>> isn't found and doesn't have the right linkage because of a >>>>> mismatch in >>>>> JDK version, we can vm_exit_during_initialization() rather than >>>>> try to >>>>> return JNI_ERR. This avoids ugly code to check >>>>> initialize_known_method's boolean result for each call. We can't >>>>> throw >>>>> an exception here. Because of the EXCEPTION_MARK in >>>>> universe_post_init, >>>>> any exception gets turned into vm_exit_during_initialization >>>>> anyway. But >>>>> this wouldn't be a user error, so vm_exit_during_initialization >>>>> seemed >>>>> like the cleanest choice. >>>> >>>> Our initialization code is truly awful. Until the VM is initialized >>>> any/all exceptions have to convert back to a different form of error >>>> because there will be no thread (or JVM for that matter) on which the >>>> user code could ask if an exception occurred. It then comes down to >>>> whether an error should be reported to the caller of JNI_CreateJavaVM >>>> so the host program doesn't get terminated, or we abort everything >>>> with vm_exit_during_initialization. And we're sliding further and >>>> further into always doing the latter. >>>> >>>> So in an absolute sense the new code is incompatible with the old >>>> because it will terminate host applications that wouldn't previously >>>> have been terminated - but in a practical sense this is unlikely to >>>> make any real difference to anything. >>>> >>>> That said something about all this is really bugging me. If we can do: >>>> >>>> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >>>> >>>> which purports to allow an exception to have been posted then how is >>>> it the immediately following code: >>>> >>>> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >>>> ! vmSymbols::register_method_name(), >>>> ! vmSymbols::register_method_signature()); >>>> ! if (m == NULL || !m->is_static()) { >>>> ! tty->print_cr("Unable to link/verify Finalizer.register >>>> method"); >>>> ! return false; // initialization failed (cannot throw >>>> exception yet) >>>> ! } >>>> >>>> can not throw an exception yet? Either both can throw or neither can >>>> throw AFAICS. So maybe the refactored link() call should not be using >>>> CHECK_ but also exit immediately? >>> >>> I don't think we should refactor InstanceKlass::link_class() for this. >> >> I wasn't suggesting that. As I said either both bits of code can >> throw exceptions or neither can, and I would have to assume it is the >> latter. link_class can be replaced by link_class_or_fail ie this: >> >> ik->link_class(CHECK); >> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >> Method* m = ik->find_method(name, signature); >> if (m == NULL || is_static != m->is_static()) { >> ResourceMark rm(THREAD); >> vm_exit_during_initialization(err_msg("Unable to link/verify >> %s.%s method", >> ik->name()->as_C_string(), method)); >> } >> >> becomes (hope I get this right): >> >> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >> Method* m = NULL; >> if (!ik->link_class_or_fail(THREAD) || >> ((m = ik->find_method(name, signature)) == NULL) || >> is_static != m->is_static()) { >> ResourceMark rm(THREAD); >> vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s >> method", >> ik->name()->as_C_string(), method)); >> } >> >> The CHECK on new_symbol is still a pretense but ... >> > > Yes, the CHECK in link_class is also a pretense. I added some dummy > code to throw a VerifyError and it got the assertion: > > # assert(resolved_method->method_holder()->is_linked()) failed: must > be linked > > From trying to call the Throwable.. I thought we had fixed > the jvm to handle this better. > > I think the code I had is easier to read, but in appreciation for your > code reviews, I've changed it to your if statement and retested. > > http://cr.openjdk.java.net/~coleenp/8143269.02/webrev > > >>> I can rewrite so that every initialize_known_method call does: >>> >>> bool ok; >>> ok = initialize_known_method(, CHECK); >>> if (!ok) return ok; >>> >>> ok = initialize_known_method(, CHECK); >>> if (!ok) return ok; >>> >>> ... >>> >>> return true; >>> >>> Which I thought was really ugly and meaningless, since as I said, this >>> case is really an assert that the library doesn't match. >> >> I'm not sure why you are suggesting that. It would only make sense if >> if there were no vm_exit_during_initialization. ?? > > Right, which I thought was the objection. >> >> It would be interesting to see exactly when java_lang_Class is linked >> in relation to this code executing, so we could see when it would be >> possible to just throw the exceptions in all cases. Pity there seems >> to be no logging for class linking. >> >>> I could change it to an assert. >>> >>> Which is your preference? This is not my preference. >> >> I'm not sure what you would assert and where ?? >> > > I meant a fatal() call instead of vm_exit_during_initialization() > since the case that I'm calling it is an error in the JVM, not really > from a users perspective. > > And YES, initialization is a messy business. Kim filed this bug a > while ago for one aspect of initialization. Throwing exceptions > and/or returning JNI_ERR is another aspect that makes it messy. > Returning JNI_ERR to some process embedding the JVM means that we've > cleaned up memory that we've allocated, of course, we haven't done > that. I think we have other bugs like that too. > > https://bugs.openjdk.java.net/browse/JDK-8068392 > > Thanks, > Coleen > >> Thanks, >> David >> >>> Thanks, >>> Coleen >>>> >>>>> Also, I want to get the code to not have to include method names (and >>>>> field names) in vmSymbols.cpp. >>>>> >>>>> I verified that this code won't merge conflict with jigsaw. There are >>>>> many additional cleanups that can be done here. universe_post_init >>>>> should really be a method belonging to Universe since it sets many >>>>> static fields in Universe, but to avoid merge conflicts, I didn't do >>>>> that. >>>> >>>> If you do that cleanup some time there are some very inaccurate >>>> comments in relation to the initialization code in init.cpp that could >>>> do with correcting. And I also spotted two paths to >>>> Interpreter::initialize. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Tested with JPRT and colocated tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From harold.seigel at oracle.com Tue Mar 22 17:31:06 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 13:31:06 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56F17860.3020604@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> <56ECBB5B.9070008@oracle.com> <56F17860.3020604@oracle.com> Message-ID: <56F1815A.5070700@oracle.com> Hi Max, These changes look good. Harold On 3/22/2016 12:52 PM, Max Ockner wrote: > Thanks David. > > I have another webrev which moved the delcaration of "replacement" > inside of the #ifndef PRODUCT. > http://cr.openjdk.java.net/~mockner/8146632.03/ > > Max > > On 3/18/2016 10:37 PM, David Holmes wrote: >> Objections withdrawn. Code Reviewed. >> >> Thanks, >> David >> >> On 19/03/2016 7:49 AM, David Holmes wrote: >>> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/18/16 8:45 AM, David Holmes wrote: >>>>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>>>> version in >>>>>>>> the table might be helpful for documentation purposes so we >>>>>>>> know in >>>>>>>> the >>>>>>>> future when to remove the line from the table. I agree with your >>>>>>>> implementation choice to have an additional table rather than >>>>>>>> twisting >>>>>>>> the other table to cover this use case. >>>>>>> >>>>>>> I don't I'm afraid - it is yet another special case and no >>>>>>> automatic >>>>>>> dropping of the message when we switch to JDK 10. Can't it be >>>>>>> folded >>>>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>>>> conversion of the non-product flags to UL has to be handled >>>>>>> differently to the product ones ?? >>>>>> >>>>>> The deprecation of non-product flags has always been different than >>>>>> product flags. The AliasedLogging flags alias the old option >>>>>> with the >>>>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>>>> removed. Non-product flags can be removed without deprecation. This >>>>>> new >>>>>> table is just to improve the error message temporarily for >>>>>> non-product >>>>>> flags. >>>>>> >>>>>> It can't be handled with the aliased logging flag table because they >>>>>> convert the option. It is the intent to remove these options. >>>>>>> >>>>>>> Aren't these just deprecated flags? We internally convert them to >>>>>>> their replacement form and issue a warning that they are going >>>>>>> away? >>>>>> >>>>>> The intent was to make a nice error message for the non-product >>>>>> flags we >>>>>> removed to help internal users. i thought you agreed to this in >>>>>> concept. >>>>> >>>>> Concept yes but I'm frustrated by the mechanism - we have too many >>>>> special cases with all this option processing, and too many tables. >>>>> >>>>> As you said above non-product flags can be removed without >>>>> deprecation, but all deprecation does is produce a nice error message >>>>> when you use the flag, and you want to add a nice error message for >>>>> this case so you have in fact turned it back into a deprecation! >>>> >>>> Deprecation is ignore and run the JVM. This is going to exit the JVM >>>> with unrecognized option with a nicer message. >>> >>> So it is a special case of "expired" which means it isn't really >>> expired >>> because the VM still has to know about it. Hence >>> yet-another-kind-of-flag. >>> >>> Seems to me this would all be a lot simpler if we treated the >>> non-product flags the same as product and just aliased and deprecated >>> them in 9, then expire in 10. There seems to be no benefit in what we >>> are doing only added complexity. >>> >>> David >>> >>>> Coleen >>>>> >>>>> David >>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think Harold's refactoring makes sense and I think the #endif // >>>>>>>> PRODUCT >>>>>>>> >>>>>>>> } >>>>>>>> *+ #ifndef PRODUCT* >>>>>>>> *+ else if ((replacement = >>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>> stripped_argname, >>>>>>>> replacement);* >>>>>>>> *+ return false;* >>>>>>>> *+ #endif* >>>>>>>> *+ }* >>>>>>>> >>>>>>>> >>>>>>>> I think this should be like this so the {} match inside of #ifndef >>>>>>>> PRODUCT: >>>>>>>> >>>>>>>> *+ #ifndef PRODUCT* >>>>>>>> *+ } else if ((replacement = >>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>> stripped_argname, >>>>>>>> replacement);* >>>>>>>> *+ return false;* >>>>>>>> *+ #endif* >>>>>>>> *+ }* >>>>>>>> >>>>>>>> >>>>>>>> Or refactor as Harold suggested. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>>>> I did, but it blended in with the rest of the text >>>>>>>>> >>>>>>>>> My response: "Seems appropriate to report a specific error >>>>>>>>> message >>>>>>>>> for >>>>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>>>> Version >>>>>>>>> in the table to keep track of when each entry needs to be >>>>>>>>> deleted, >>>>>>>>> like what is done in the table of obsolete flags. " >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> You should also answer David's concern. >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>>>> >>>>>>>>>>> Comments below. >>>>>>>>>>> >>>>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>>>> Hello again everyone! >>>>>>>>>>>>> >>>>>>>>>>>>> Please review this change which adds better error messages >>>>>>>>>>>>> for >>>>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>>>> >>>>>>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>>>>>> vm to >>>>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>>>> command >>>>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>>>> >>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>> instead." >>>>>>>>>>>>> >>>>>>>>>>>>> The entire output looks like this: >>>>>>>>>>>>> >>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>> instead. >>>>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>>>> >>>>>>>>>>>> I'm concerned that this has introduced another variant of >>>>>>>>>>>> "flag >>>>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>>>> should >>>>>>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>>>>>> flag >>>>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>>>> then in >>>>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>>>> then >>>>>>>>>>> remove it for 10. If it would help, we can store a Version >>>>>>>>>>> in the >>>>>>>>>>> table to keep track of when each entry needs to be deleted, >>>>>>>>>>> like >>>>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>>>> appropriate >>>>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>>>> converted to >>>>>>>>>>>>> logging. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> > From jiangli.zhou at oracle.com Tue Mar 22 17:35:03 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 22 Mar 2016 10:35:03 -0700 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F17BE8.1010407@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> Message-ID: Hi Coleen, Looks good to me. I had same question as Tobias yesterday. Your answer cleared it. Thanks, Jiangli > On Mar 22, 2016, at 10:07 AM, Coleen Phillimore wrote: > > > Here's another webrev with the changes pointed out by Tobias and verified with -XX:+VerifyStringTableAtExit. > > open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev > > Thanks! > Coleen > > On 3/22/16 12:21 PM, Tobias Hartmann wrote: >> Hi Coleen, >> >> On 22.03.2016 13:40, Coleen Phillimore wrote: >>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>> Hi Coleen, >>>> >>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>> Summary: Fix code broken with compact Strings. >>>>> >>>>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>>>> >>>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? >>> Yes, I believe it is. >> Okay, thanks for checking. >> >>>> Now we don't need the StringTable::hash_string version anymore, right? >>> This one is used by Symbol* which are jbyte. >> I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. >> >>>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. >>> Thank you, I'll remove it. >> Thanks! >> >> Best regards, >> Tobias >> >>>> Thanks for fixing this! >>> Thanks for reviewing it! >>> Coleen >>>> Best regards, >>>> Tobias >>>> >>>>> Thanks, >>>>> Coleen > From coleen.phillimore at oracle.com Tue Mar 22 17:39:02 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 13:39:02 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> Message-ID: <56F18336.4070603@oracle.com> Thank you, Jiangli. Coleen On 3/22/16 1:35 PM, Jiangli Zhou wrote: > Hi Coleen, > > Looks good to me. I had same question as Tobias yesterday. Your answer cleared it. > > Thanks, > Jiangli > >> On Mar 22, 2016, at 10:07 AM, Coleen Phillimore wrote: >> >> >> Here's another webrev with the changes pointed out by Tobias and verified with -XX:+VerifyStringTableAtExit. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev >> >> Thanks! >> Coleen >> >> On 3/22/16 12:21 PM, Tobias Hartmann wrote: >>> Hi Coleen, >>> >>> On 22.03.2016 13:40, Coleen Phillimore wrote: >>>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>>> Hi Coleen, >>>>> >>>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>>> Summary: Fix code broken with compact Strings. >>>>>> >>>>>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>>>>> >>>>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? >>>> Yes, I believe it is. >>> Okay, thanks for checking. >>> >>>>> Now we don't need the StringTable::hash_string version anymore, right? >>>> This one is used by Symbol* which are jbyte. >>> I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. >>> >>>>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. >>>> Thank you, I'll remove it. >>> Thanks! >>> >>> Best regards, >>> Tobias >>> >>>>> Thanks for fixing this! >>>> Thanks for reviewing it! >>>> Coleen >>>>> Best regards, >>>>> Tobias >>>>> >>>>>> Thanks, >>>>>> Coleen From coleen.phillimore at oracle.com Tue Mar 22 18:03:01 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 14:03:01 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56F1815A.5070700@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> <56ECBB5B.9070008@oracle.com> <56F17860.3020604@oracle.com> <56F1815A.5070700@oracle.com> Message-ID: <56F188D5.5090206@oracle.com> I agree, this looks good. Coleen On 3/22/16 1:31 PM, harold seigel wrote: > Hi Max, > > These changes look good. > > Harold > > On 3/22/2016 12:52 PM, Max Ockner wrote: >> Thanks David. >> >> I have another webrev which moved the delcaration of "replacement" >> inside of the #ifndef PRODUCT. >> http://cr.openjdk.java.net/~mockner/8146632.03/ >> >> Max >> >> On 3/18/2016 10:37 PM, David Holmes wrote: >>> Objections withdrawn. Code Reviewed. >>> >>> Thanks, >>> David >>> >>> On 19/03/2016 7:49 AM, David Holmes wrote: >>>> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/18/16 8:45 AM, David Holmes wrote: >>>>>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>>>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>>>>> version in >>>>>>>>> the table might be helpful for documentation purposes so we >>>>>>>>> know in >>>>>>>>> the >>>>>>>>> future when to remove the line from the table. I agree with your >>>>>>>>> implementation choice to have an additional table rather than >>>>>>>>> twisting >>>>>>>>> the other table to cover this use case. >>>>>>>> >>>>>>>> I don't I'm afraid - it is yet another special case and no >>>>>>>> automatic >>>>>>>> dropping of the message when we switch to JDK 10. Can't it be >>>>>>>> folded >>>>>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>>>>> conversion of the non-product flags to UL has to be handled >>>>>>>> differently to the product ones ?? >>>>>>> >>>>>>> The deprecation of non-product flags has always been different than >>>>>>> product flags. The AliasedLogging flags alias the old option >>>>>>> with the >>>>>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>>>>> removed. Non-product flags can be removed without deprecation. >>>>>>> This >>>>>>> new >>>>>>> table is just to improve the error message temporarily for >>>>>>> non-product >>>>>>> flags. >>>>>>> >>>>>>> It can't be handled with the aliased logging flag table because >>>>>>> they >>>>>>> convert the option. It is the intent to remove these options. >>>>>>>> >>>>>>>> Aren't these just deprecated flags? We internally convert them to >>>>>>>> their replacement form and issue a warning that they are going >>>>>>>> away? >>>>>>> >>>>>>> The intent was to make a nice error message for the non-product >>>>>>> flags we >>>>>>> removed to help internal users. i thought you agreed to this in >>>>>>> concept. >>>>>> >>>>>> Concept yes but I'm frustrated by the mechanism - we have too many >>>>>> special cases with all this option processing, and too many tables. >>>>>> >>>>>> As you said above non-product flags can be removed without >>>>>> deprecation, but all deprecation does is produce a nice error >>>>>> message >>>>>> when you use the flag, and you want to add a nice error message for >>>>>> this case so you have in fact turned it back into a deprecation! >>>>> >>>>> Deprecation is ignore and run the JVM. This is going to exit the >>>>> JVM >>>>> with unrecognized option with a nicer message. >>>> >>>> So it is a special case of "expired" which means it isn't really >>>> expired >>>> because the VM still has to know about it. Hence >>>> yet-another-kind-of-flag. >>>> >>>> Seems to me this would all be a lot simpler if we treated the >>>> non-product flags the same as product and just aliased and deprecated >>>> them in 9, then expire in 10. There seems to be no benefit in what we >>>> are doing only added complexity. >>>> >>>> David >>>> >>>>> Coleen >>>>>> >>>>>> David >>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think Harold's refactoring makes sense and I think the >>>>>>>>> #endif // >>>>>>>>> PRODUCT >>>>>>>>> >>>>>>>>> } >>>>>>>>> *+ #ifndef PRODUCT* >>>>>>>>> *+ else if ((replacement = >>>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>>> stripped_argname, >>>>>>>>> replacement);* >>>>>>>>> *+ return false;* >>>>>>>>> *+ #endif* >>>>>>>>> *+ }* >>>>>>>>> >>>>>>>>> >>>>>>>>> I think this should be like this so the {} match inside of >>>>>>>>> #ifndef >>>>>>>>> PRODUCT: >>>>>>>>> >>>>>>>>> *+ #ifndef PRODUCT* >>>>>>>>> *+ } else if ((replacement = >>>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>>> stripped_argname, >>>>>>>>> replacement);* >>>>>>>>> *+ return false;* >>>>>>>>> *+ #endif* >>>>>>>>> *+ }* >>>>>>>>> >>>>>>>>> >>>>>>>>> Or refactor as Harold suggested. >>>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>>>>> I did, but it blended in with the rest of the text >>>>>>>>>> >>>>>>>>>> My response: "Seems appropriate to report a specific error >>>>>>>>>> message >>>>>>>>>> for >>>>>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>>>>> Version >>>>>>>>>> in the table to keep track of when each entry needs to be >>>>>>>>>> deleted, >>>>>>>>>> like what is done in the table of obsolete flags. " >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>>>>> >>>>>>>>>>> You should also answer David's concern. >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>>>>> >>>>>>>>>>>> Comments below. >>>>>>>>>>>> >>>>>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>>>>> Hello again everyone! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review this change which adds better error >>>>>>>>>>>>>> messages for >>>>>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since these options have been removed, we want still want >>>>>>>>>>>>>> the >>>>>>>>>>>>>> vm to >>>>>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>>>>> command >>>>>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>>> instead." >>>>>>>>>>>>>> >>>>>>>>>>>>>> The entire output looks like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>>> instead. >>>>>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm concerned that this has introduced another variant of >>>>>>>>>>>>> "flag >>>>>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>>>>> should >>>>>>>>>>>>> be removed. Maybe we need to add "replaced" as another >>>>>>>>>>>>> type of >>>>>>>>>>>>> flag >>>>>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>>>>> then in >>>>>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>>>>> then >>>>>>>>>>>> remove it for 10. If it would help, we can store a Version >>>>>>>>>>>> in the >>>>>>>>>>>> table to keep track of when each entry needs to be deleted, >>>>>>>>>>>> like >>>>>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>>>>> appropriate >>>>>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>>>>> converted to >>>>>>>>>>>>>> logging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >> > From gerard.ziemski at oracle.com Tue Mar 22 18:15:20 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Mar 2016 13:15:20 -0500 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56EBFCCC.1080701@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> Message-ID: hi Marcus, Thank you for incorporating the feedback. The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line. May I suggest the following implementation instead: static size_t number_of_lines_with_substring_in_file(const char* filename, const char* substr) { ResourceMark rm; size_t ret = 0; FILE* fp = fopen(filename, "r"); assert(fp, "error opening file %s: %s", filename, strerror(errno)); int buflen = 512; char* buf = NEW_RESOURCE_ARRAY(char, buflen); long int pos = 0; while (fgets(buf, buflen, fp) != NULL) { if (buf[strlen(buf) - 1] != '\n') { // rewind to the beginning of the line fseek(fp, pos, SEEK_SET); // double the buffer size and try again buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen); buflen *= 2; } else { // get current file position pos = ftell(fp); if (strstr(buf, substr) != NULL) { ret++; } } } fclose(fp); return ret; } cheers > On Mar 18, 2016, at 8:04 AM, Marcus Larsson wrote: > > Updated patch after feedback. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ > > Tested with internal VM tests through RBT. > > Changes: > * Rotation filecount is now limited to 1000 files. > * Removed loop in os::compare_file_modified_times. > * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file. > * Added test case to check that logging to a directory gives the intended error message. > * Fixed test help method to handle arbitrary length log lines. > > Thanks, > Marcus > > On 03/11/2016 03:21 PM, Marcus Larsson wrote: >> Third time's the charm. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >> >> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >> >> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >> >> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >> >> Tested with included internal VM tests through RBT. >> >> Thanks, >> Marcus >> >> On 2016-03-01 15:05, Marcus Larsson wrote: >>> Hi, >>> >>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>> >>> Thanks, >>> Marcus >>> >>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Taking a different approach to this. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>> >>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>> >>>> Tested with included jtreg test through JPRT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>> >>>>> Testing: >>>>> Included test through JPRT >>>>> >>>>> Thanks, >>>>> Marcus >>>> >>> >> > From gerard.ziemski at oracle.com Tue Mar 22 18:58:39 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Mar 2016 13:58:39 -0500 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> Message-ID: <405AC30F-15D8-403F-98B1-99926291BF2D@oracle.com> This fix has been already ?r"eviewed, but I still need a ?R"eviewer please. cheers > On Mar 16, 2016, at 11:55 AM, Gerard Ziemski wrote: > > hi all, > > This is rev2 of the fix incorporating feedback from Dmitry: > > - re-use "CommandLineFlagConstraintList::find()" > > Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) > > With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. > > > bug https://bugs.openjdk.java.net/browse/JDK-8142510 > webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 > > tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation > > > cheers From rachel.protacio at oracle.com Tue Mar 22 20:06:53 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 22 Mar 2016 16:06:53 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F16E57.2060507@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> Message-ID: <56F1A5DD.3040506@oracle.com> Hi, On 3/22/2016 12:09 PM, Coleen Phillimore wrote: > > Hi Rachel, > > http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html > > > I think the line > > *-if (PrintOopAddress)print_address_on(st);* > > > should be removed. For the case of a String that is in output for > logging, it doesn't seem like it adds anything and then you wouldn't > have to change the tests. > The part printing from the exceptions logging isn't from oop.cpp, but klass.cpp#Klass::print_on(). Should I delete it from there instead? Rachel > Thanks, > Coleen > > On 3/22/16 10:08 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix removing PrintOopAddress as a command line >> flag. The printing functionality has been made default, except for >> one block which has been removed (see bug description for >> justification). A compatibility request has been accepted with >> respect to this change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >> >> Passes JPRT and RBT hotspot and non-colo testing. >> >> Thank you, >> Rachel > From karen.kinnear at oracle.com Tue Mar 22 20:20:25 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 22 Mar 2016 16:20:25 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: <56F16BF4.6040208@oracle.com> References: <56F15573.6090508@oracle.com> <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> <56F16275.5090508@oracle.com> <56F16684.8060704@oracle.com> <56F16BF4.6040208@oracle.com> Message-ID: Agree with Coleen on both points. thanks, Karen > On Mar 22, 2016, at 11:59 AM, harold seigel wrote: > > Hi Coleen, > > Thanks for the review. I'll add the comment. > > I don't know about future plans for accessing Unsafe. > > Harold > > On 3/22/2016 11:36 AM, Coleen Phillimore wrote: >> >> Hi Harold, This looks good but a single line comment that primitive types have NULL Klass* fields in their java.lang.Class instances would be helpful, especially if this is changed in the future. >> >> Since the hostClass is checked in the caller, my vote is to not add another check in the vm. >> >> In the test, is there going to be another way to get to Unsafe in the future, or present? >> >> Thanks, >> Coleen >> >> >> On 3/22/16 11:19 AM, harold seigel wrote: >>> Hi Karen, >>> >>> Thanks for looking at the changes. The JDK caller of Unsafe_DefineAnonymousClass_impl() is in java.base/share/classes/jdk/internal/misc/Unsafe.java. It checks for NULL args and throws NPE: >>> >>> public Class defineAnonymousClass(Class hostClass, byte[] data, Object[] cpPatches) { >>> if (hostClass == null || data == null) { >>> throw new NullPointerException(); >>> } >>> return defineAnonymousClass0(hostClass, data, cpPatches); >>> } >>> >>> If somehow a null host_class was passed to Unsafe_DefineAnonymousClass_impl() then it would probably seg fault in product. Perhaps that's okay because it is an Unsafe_... API. >>> >>> Thanks, Harold >>> >>> On 3/22/2016 10:57 AM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Thank you for fixing this. Looks good. >>>> >>>> One question - >>>> >>>> 1. If you were to pass in a null host_class in product - what happens? >>>> The way I read the resolve_non_null, it asserts in debug that you did not pass in a null, which suggests to me that it assumes >>>> we have already made that check. I would expect and if (host_class == NULL) || ? 0> IllegalArgumentException ? >>>> >>>> thanks, >>>> Karen >>>> >>>>> On Mar 22, 2016, at 10:23 AM, harold seigel wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review this small change to fix bug 8140665. >>>>> >>>>> Instead of asserting or getting a SIGSEGV when trying to define an anonymous class when the host class is a primitive type, this fix throws an IllegalArgumentException. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 >>>>> >>>>> The fix was tested with JCK Lang and VM java_lang tests, the UTE non-collated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util and JFR JTreg tests, and the test included in this RFR. >>>>> >>>>> Thanks, Harold >>> >> > From harold.seigel at oracle.com Tue Mar 22 20:20:48 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Mar 2016 16:20:48 -0400 Subject: RFR(S) 8140665: SIGSEGV when a primitive type's class is used as the host class in a call to DefineAnonymousClass call In-Reply-To: References: <56F15573.6090508@oracle.com> <68ADB827-042E-4121-AD30-646C7E50A692@oracle.com> <56F16275.5090508@oracle.com> <56F16684.8060704@oracle.com> <56F16BF4.6040208@oracle.com> Message-ID: <56F1A920.6090508@oracle.com> Thanks Karen! Harold On 3/22/2016 4:20 PM, Karen Kinnear wrote: > Agree with Coleen on both points. > > thanks, > Karen > >> On Mar 22, 2016, at 11:59 AM, harold seigel wrote: >> >> Hi Coleen, >> >> Thanks for the review. I'll add the comment. >> >> I don't know about future plans for accessing Unsafe. >> >> Harold >> >> On 3/22/2016 11:36 AM, Coleen Phillimore wrote: >>> Hi Harold, This looks good but a single line comment that primitive types have NULL Klass* fields in their java.lang.Class instances would be helpful, especially if this is changed in the future. >>> >>> Since the hostClass is checked in the caller, my vote is to not add another check in the vm. >>> >>> In the test, is there going to be another way to get to Unsafe in the future, or present? >>> >>> Thanks, >>> Coleen >>> >>> >>> On 3/22/16 11:19 AM, harold seigel wrote: >>>> Hi Karen, >>>> >>>> Thanks for looking at the changes. The JDK caller of Unsafe_DefineAnonymousClass_impl() is in java.base/share/classes/jdk/internal/misc/Unsafe.java. It checks for NULL args and throws NPE: >>>> >>>> public Class defineAnonymousClass(Class hostClass, byte[] data, Object[] cpPatches) { >>>> if (hostClass == null || data == null) { >>>> throw new NullPointerException(); >>>> } >>>> return defineAnonymousClass0(hostClass, data, cpPatches); >>>> } >>>> >>>> If somehow a null host_class was passed to Unsafe_DefineAnonymousClass_impl() then it would probably seg fault in product. Perhaps that's okay because it is an Unsafe_... API. >>>> >>>> Thanks, Harold >>>> >>>> On 3/22/2016 10:57 AM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Thank you for fixing this. Looks good. >>>>> >>>>> One question - >>>>> >>>>> 1. If you were to pass in a null host_class in product - what happens? >>>>> The way I read the resolve_non_null, it asserts in debug that you did not pass in a null, which suggests to me that it assumes >>>>> we have already made that check. I would expect and if (host_class == NULL) || ? 0> IllegalArgumentException ? >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>>> On Mar 22, 2016, at 10:23 AM, harold seigel wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review this small change to fix bug 8140665. >>>>>> >>>>>> Instead of asserting or getting a SIGSEGV when trying to define an anonymous class when the host class is a primitive type, this fix throws an IllegalArgumentException. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8140665/ >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8140665 >>>>>> >>>>>> The fix was tested with JCK Lang and VM java_lang tests, the UTE non-collated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util and JFR JTreg tests, and the test included in this RFR. >>>>>> >>>>>> Thanks, Harold From daniel.daugherty at oracle.com Tue Mar 22 20:41:16 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 22 Mar 2016 14:41:16 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket Message-ID: <56F1ADEC.2050508@oracle.com> Greetings, I have fixes for the following two bugs: JDK-8077392 Stream fork/join tasks occasionally fail to complete https://bugs.openjdk.java.net/browse/JDK-8077392 JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed https://bugs.openjdk.java.net/browse/JDK-8131715 Both fixes are very, very small and will be bundled together in the same changeset for obvious reasons. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ While the fix for JDK-8077392 is a simple 1-liner, the explanation of the race is much, much longer. I've attached the detailed evaluation to this RFR; it is a copy of the same note that I added to https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached copy has all the indentation white space intact. I don't know why JBS likes to reformat the notes, but it does... :-( Testing: - the original failing test is running in a parallel stress config on my Solaris X64 server; just under 23 hours and just under 3000 iterations without a failure in either instance; I'm planning to let the stress run go for at least 72 hours. - RT/SVC nightly equivalent (in progress) As always, comments, suggestions and/or questions are welcome. Dan -------------- next part -------------- This bug has finally been chased to ground. As expected, the bug is a race condition that is only present in certain configurations. This note is an attempt to describe the race and the conditions under which the race can occur. This race is due to a bug in ObjectSynchronizer::quick_enter() which is a C2 function that was added by the "fast enter" bucket for the Contended Locking project. See: JDK-8061553 Contended Locking fast enter bucket so this bug is only present in configurations that use the Server VM (C2); configurations that use the Client VM (C1) will not observe this bug. Secondarily, Biased Locking must be enabled for the race condition to manifest. By default Biased Locking is enabled at 4 seconds so any hangs seen where the VM uptime is less than 4 seconds are not likely to be due to this bug. Lastly, there must be contention on the Java Monitor in question so there must be two or more threads using the Java Monitor that has been observed as "stranded". Here's the conditions above in check list form with a few additional conditions: - Server Compiler/C2 is in use - Biased Locking enabled (VM uptime >= 4 seconds) - Java Monitor contention - Without special options, this hang should only be observed in JDK9-B53 -> JDK9-B63; JDK-8061553 was promoted in JDK9-B53 and the fix to disable it (JDK-8079359) was promoted in JDK9-B64. - So if your hang occurred before JDK9-B53 or in JDK9-B64 or later, then this bug is not likely the cause. If you think you have a hang that is caused by this bug, then use the following diagnostic options: -XX:+UnlockExperimentalVMOptions -XX:SyncKnobs=ReportSettings=1:Verbose=1:ExitRelease=1:VerifyMatch=1 The 'VerifyMatch=1' portion of the above diagnostic options will cause output like the following when you've run into this bug: INFO: unexpected locked object: - locked <0xfffffd7be95defe0> (a java.util.stream.Nodes$CollectorTask$OfDouble) # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (synchronizer.cpp:2203), pid=19281, tid=95 # fatal error: exiting JavaThread=0x0000000004278800 unexpectedly owns ObjectMonitor=0x00000000016f2000 # # JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-dcubed_2016_03_18_18_43-b00) The diagnostic output above shows: - the unexpected locked object (0xfffffd7be95defe0) - the object's type (java.util.stream.Nodes$CollectorTask$OfDouble) - the thread that owns the lock (0x0000000004278800), - and the ObjectMonitor (0x00000000016f2000). Please note that mis-behaving programs that use JNI locking can also run into this diagnostic trap so I recommend careful use of these diagnostic options. Gory Code Details: ## ## JavaThread1 (JT1) - Part 1 ## The first JavaThread (JT1) in the race is executing this code (when the -XX:-UseOptoBiasInlining is specified): src/cpu/x86/vm/macroAssembler_x86.cpp: int MacroAssembler::biased_locking_enter(Register lock_reg, Register obj_reg, Register swap_reg, Register tmp_reg, bool swap_reg_contains_mark, Label& done, Label* slow_case, BiasedLockingCounters* counters) { movptr(tmp_reg, swap_reg); andptr(tmp_reg, markOopDesc::biased_lock_mask_in_place); cmpptr(tmp_reg, markOopDesc::biased_lock_pattern); jcc(Assembler::notEqual, cas_label); // The bias pattern is present in the object's header. Need to check // whether the bias owner and the epoch are both still current. Note: When UseOptoBiasInlining is enabled (the default), biased_locking_enter() is not used and the C2 ideal graph version of the algorithm is used; for this note, -XX:-UseOptoBiasInlining is used because it's easier to explain biased_locking_enter()'s assembly code than the C2 ideal graph code. See PhaseMacroExpand::expand_lock_node() for the C2 ideal graph code. ## ## JavaThread2 (JT2) - Part 1 ## The second JavaThread (JT2) is inflating the JavaMonitor associated with this object so it is here (for example): src/share/vm/runtime/synchronizer.cpp: void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) { lock->set_displaced_header(markOopDesc::unused_mark()); ObjectSynchronizer::inflate(THREAD, obj(), inflate_cause_monitor_enter)->enter(THREAD); Note: Don't be confused by the call to "lock->set_displaced_header(markOopDesc::unused_mark())" above; that's the BasicLock in JT2's context. JT2 has finished the inflation part using the Biased Locking "CASE: neutral" code: src/share/vm/runtime/synchronizer.cpp ObjectMonitor* ObjectSynchronizer::inflate(Thread * Self, oop object, const InflateCause cause) { // CASE: neutral // TODO-FIXME: for entry we currently inflate and then try to CAS _owner. // If we know we're inflating for entry it's better to inflate by swinging a // pre-locked objectMonitor pointer into the object header. A successful // CAS inflates the object *and* confers ownership to the inflating thread. // In the current implementation we use a 2-step mechanism where we CAS() // to inflate and then CAS() again to try to swing _owner from NULL to Self. // An inflateTry() method that we could call from fast_enter() and slow_enter() // would be useful. assert(mark->is_neutral(), "invariant"); ObjectMonitor * m = omAlloc(Self); // prepare m for installation - set monitor to initial state m->Recycle(); m->set_header(mark); m->set_owner(NULL); and is now racing with JT1 for ownership of the Java Monitor in ObjectMonitor::enter(). For our failure mode, JT2 loses the race to JT1. ## ## JavaThread1 (JT1) - Part 2 ## src/cpu/x86/vm/macroAssembler_x86.cpp: int MacroAssembler::biased_locking_enter(Register lock_reg, andptr(tmp_reg, markOopDesc::biased_lock_mask_in_place); cmpptr(tmp_reg, markOopDesc::biased_lock_pattern); jcc(Assembler::notEqual, cas_label); // The bias pattern is present in the object's header. Need to check // whether the bias owner and the epoch are both still current. if (swap_reg_contains_mark) { null_check_offset = offset(); } load_prototype_header(tmp_reg, obj_reg); orptr(tmp_reg, r15_thread); xorptr(tmp_reg, swap_reg); Register header_reg = tmp_reg; andptr(header_reg, ~((int) markOopDesc::age_mask_in_place)); if (counters != NULL) { cond_inc32(Assembler::zero, ExternalAddress((address) counters->biased_lock_entry_count_addr())); } jcc(Assembler::equal, done); // At this point we know that the header has the bias pattern and // that we are not the bias owner in the current epoch. We need to // figure out more details about the state of the header in order to // know what operations can be legally performed on the object's // header. // If the low three bits in the xor result aren't clear, that means // the prototype header is no longer biased and we have to revoke // the bias on this object. testptr(header_reg, markOopDesc::biased_lock_mask_in_place); jccb(Assembler::notZero, try_revoke_bias); // Biasing is still enabled for this data type. See whether the // epoch of the current bias is still valid, meaning that the epoch // bits of the mark word are equal to the epoch bits of the // prototype header. (Note that the prototype header's epoch bits // only change at a safepoint.) If not, attempt to rebias the object // toward the current thread. Note that we must be absolutely sure // that the current epoch is invalid in order to do this because // otherwise the manipulations it performs on the mark word are // illegal. testptr(header_reg, markOopDesc::epoch_mask_in_place); jccb(Assembler::notZero, try_rebias); // The epoch of the current bias is still valid but we know nothing // about the owner; it might be set or it might be clear. Try to // acquire the bias of the object using an atomic operation. If this // fails we will go in to the runtime to revoke the object's bias. // Note that we first construct the presumed unbiased header so we // don't accidentally blow away another thread's valid bias. NOT_LP64( movptr(swap_reg, saved_mark_addr); ) andptr(swap_reg, markOopDesc::biased_lock_mask_in_place | markOopDesc::age_mask_in_place | markOopDesc::epoch_mask_in_place); #ifdef _LP64 movptr(tmp_reg, swap_reg); orptr(tmp_reg, r15_thread); #else get_thread(tmp_reg); orptr(tmp_reg, swap_reg); #endif if (os::is_MP()) { lock(); } cmpxchgptr(tmp_reg, mark_addr); // compare tmp_reg and swap_reg // If the biasing toward our thread failed, this means that // another thread succeeded in biasing it toward itself and we // need to revoke that bias. The revocation will occur in the // interpreter runtime in the slow case. if (counters != NULL) { cond_inc32(Assembler::zero, ExternalAddress((address) counters->anonymously_biased_lock_entry_count_addr())); } if (slow_case != NULL) { jcc(Assembler::notZero, *slow_case); } jmp(done); src/share/vm/runtime/synchronizer.cpp: bool ObjectSynchronizer::quick_enter(oop obj, Thread * Self, BasicLock * Lock) { if (mark->has_monitor()) { if (owner == Self) { if (owner == NULL && Atomic::cmpxchg_ptr(Self, &(m->_owner), NULL) == NULL) { <_displaced_header field value to something other than NULL. This> assert(m->_recursions == 0, "invariant"); assert(m->_owner == Self, "invariant"); return true; } To recap: - JT1 calls C2 fast_lock() which calls biased_locking_enter() - JT2 inflates the Java Monitor - JT1 bails biased_locking_enter() after making it past the first check which results in an early bail from fast_lock() - JT1 makes a slow path call to complete_monitor_enter_C() - JT1 makes a last ditch call to quick_enter() before doing the real slow path work The early bail code path in biased_locking_enter() and fast_lock() results in the BasicLock's _displaced_header field value remaining NULL which marks this entry as recursive. If JT2's inflation had happened a little earlier, then JT1 would have taken the first bail point in biased_locking_enter() which would have resulted in a regular fast_lock() code path which does initialize the BasicLock's _displaced_header field. The fix for this problem is a 1-liner: --- a/src/share/vm/runtime/synchronizer.cpp +++ b/src/share/vm/runtime/synchronizer.cpp @@ -229,6 +229,9 @@ bool ObjectSynchronizer::quick_enter(oop if (owner == NULL && Atomic::cmpxchg_ptr(Self, &(m->_owner), NULL) == NULL) { + // Make the displaced header non-NULL so this BasicLock is + // not seen as recursive. + Lock->set_displaced_header(markOopDesc::unused_mark()); assert(m->_recursions == 0, "invariant"); assert(m->_owner == Self, "invariant"); return true; So when quick_enter() succeeds at its last ditch optimization, it needs to mark the BasicLock's _displaced_header field with a non-zero value (like the other lock grabbing code paths). From daniel.daugherty at oracle.com Tue Mar 22 21:35:44 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 22 Mar 2016 15:35:44 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 Message-ID: <56F1BAB0.2000001@oracle.com> Greetings, As a follow on to my fix for the following bugs: JDK-8077392 Stream fork/join tasks occasionally fail to complete https://bugs.openjdk.java.net/browse/JDK-8077392 JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed https://bugs.openjdk.java.net/browse/JDK-8131715 I have a fix for the following bug: JDK-8152358 code and comment cleanups found during the hunt for 8077392 https://bugs.openjdk.java.net/browse/JDK-8152358 These cleanups are pretty straight forward so I'm not going to include the usual long, detailed analysis... :-) Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ This webrev is a superset of the webrev for the JDK-8077392 and JDK-8131715 fixes and is the code that I'm currently testing... Testing: - the original failing test is running in a parallel stress config on my Solaris X64 server; just under 23 hours and just under 3000 iterations without a failure in either instance; I'm planning to let the stress run go for at least 72 hours. - RT/SVC nightly equivalent (in progress) As always, comments, suggestions and/or questions are welcome. Dan From coleen.phillimore at oracle.com Tue Mar 22 21:50:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 17:50:39 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56F17FEA.8070809@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> <56F0A8CF.4090502@oracle.com> <56F1381D.7040009@oracle.com> <56F17FEA.8070809@oracle.com> Message-ID: <56F1BE2F.8020409@oracle.com> Thank you, Harold! Coleen On 3/22/16 1:24 PM, harold seigel wrote: > Hi Coleen, > > Your latest changes look good. > > Thanks, Harold > > On 3/22/2016 8:18 AM, Coleen Phillimore wrote: >> >> Hi David, >> Thank you for reviewing. >> >> On 3/21/16 10:07 PM, David Holmes wrote: >>> On 22/03/2016 12:05 AM, Coleen Phillimore wrote: >>>> On 3/21/16 1:12 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>>>>> Summary: Deferred code review cleanups >>>>>> >>>>>> This was a review comment I had when the StackWalk API was >>>>>> integrated. >>>>>> There were too many of this same code pattern in the middle of >>>>>> universe_post_init. The only real change here is that if the method >>>>>> isn't found and doesn't have the right linkage because of a >>>>>> mismatch in >>>>>> JDK version, we can vm_exit_during_initialization() rather than >>>>>> try to >>>>>> return JNI_ERR. This avoids ugly code to check >>>>>> initialize_known_method's boolean result for each call. We can't >>>>>> throw >>>>>> an exception here. Because of the EXCEPTION_MARK in >>>>>> universe_post_init, >>>>>> any exception gets turned into vm_exit_during_initialization >>>>>> anyway. But >>>>>> this wouldn't be a user error, so vm_exit_during_initialization >>>>>> seemed >>>>>> like the cleanest choice. >>>>> >>>>> Our initialization code is truly awful. Until the VM is initialized >>>>> any/all exceptions have to convert back to a different form of error >>>>> because there will be no thread (or JVM for that matter) on which the >>>>> user code could ask if an exception occurred. It then comes down to >>>>> whether an error should be reported to the caller of JNI_CreateJavaVM >>>>> so the host program doesn't get terminated, or we abort everything >>>>> with vm_exit_during_initialization. And we're sliding further and >>>>> further into always doing the latter. >>>>> >>>>> So in an absolute sense the new code is incompatible with the old >>>>> because it will terminate host applications that wouldn't previously >>>>> have been terminated - but in a practical sense this is unlikely to >>>>> make any real difference to anything. >>>>> >>>>> That said something about all this is really bugging me. If we can >>>>> do: >>>>> >>>>> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >>>>> >>>>> which purports to allow an exception to have been posted then how is >>>>> it the immediately following code: >>>>> >>>>> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >>>>> ! vmSymbols::register_method_name(), >>>>> ! vmSymbols::register_method_signature()); >>>>> ! if (m == NULL || !m->is_static()) { >>>>> ! tty->print_cr("Unable to link/verify Finalizer.register >>>>> method"); >>>>> ! return false; // initialization failed (cannot throw >>>>> exception yet) >>>>> ! } >>>>> >>>>> can not throw an exception yet? Either both can throw or neither can >>>>> throw AFAICS. So maybe the refactored link() call should not be using >>>>> CHECK_ but also exit immediately? >>>> >>>> I don't think we should refactor InstanceKlass::link_class() for this. >>> >>> I wasn't suggesting that. As I said either both bits of code can >>> throw exceptions or neither can, and I would have to assume it is >>> the latter. link_class can be replaced by link_class_or_fail ie this: >>> >>> ik->link_class(CHECK); >>> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >>> Method* m = ik->find_method(name, signature); >>> if (m == NULL || is_static != m->is_static()) { >>> ResourceMark rm(THREAD); >>> vm_exit_during_initialization(err_msg("Unable to link/verify >>> %s.%s method", >>> ik->name()->as_C_string(), method)); >>> } >>> >>> becomes (hope I get this right): >>> >>> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >>> Method* m = NULL; >>> if (!ik->link_class_or_fail(THREAD) || >>> ((m = ik->find_method(name, signature)) == NULL) || >>> is_static != m->is_static()) { >>> ResourceMark rm(THREAD); >>> vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s >>> method", >>> ik->name()->as_C_string(), method)); >>> } >>> >>> The CHECK on new_symbol is still a pretense but ... >>> >> >> Yes, the CHECK in link_class is also a pretense. I added some dummy >> code to throw a VerifyError and it got the assertion: >> >> # assert(resolved_method->method_holder()->is_linked()) failed: must >> be linked >> >> From trying to call the Throwable.. I thought we had fixed >> the jvm to handle this better. >> >> I think the code I had is easier to read, but in appreciation for >> your code reviews, I've changed it to your if statement and retested. >> >> http://cr.openjdk.java.net/~coleenp/8143269.02/webrev >> >> >>>> I can rewrite so that every initialize_known_method call does: >>>> >>>> bool ok; >>>> ok = initialize_known_method(, CHECK); >>>> if (!ok) return ok; >>>> >>>> ok = initialize_known_method(, CHECK); >>>> if (!ok) return ok; >>>> >>>> ... >>>> >>>> return true; >>>> >>>> Which I thought was really ugly and meaningless, since as I said, this >>>> case is really an assert that the library doesn't match. >>> >>> I'm not sure why you are suggesting that. It would only make sense >>> if if there were no vm_exit_during_initialization. ?? >> >> Right, which I thought was the objection. >>> >>> It would be interesting to see exactly when java_lang_Class is >>> linked in relation to this code executing, so we could see when it >>> would be possible to just throw the exceptions in all cases. Pity >>> there seems to be no logging for class linking. >>> >>>> I could change it to an assert. >>>> >>>> Which is your preference? This is not my preference. >>> >>> I'm not sure what you would assert and where ?? >>> >> >> I meant a fatal() call instead of vm_exit_during_initialization() >> since the case that I'm calling it is an error in the JVM, not really >> from a users perspective. >> >> And YES, initialization is a messy business. Kim filed this bug a >> while ago for one aspect of initialization. Throwing exceptions >> and/or returning JNI_ERR is another aspect that makes it messy. >> Returning JNI_ERR to some process embedding the JVM means that we've >> cleaned up memory that we've allocated, of course, we haven't done >> that. I think we have other bugs like that too. >> >> https://bugs.openjdk.java.net/browse/JDK-8068392 >> >> Thanks, >> Coleen >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>>> >>>>>> Also, I want to get the code to not have to include method names >>>>>> (and >>>>>> field names) in vmSymbols.cpp. >>>>>> >>>>>> I verified that this code won't merge conflict with jigsaw. There >>>>>> are >>>>>> many additional cleanups that can be done here. universe_post_init >>>>>> should really be a method belonging to Universe since it sets many >>>>>> static fields in Universe, but to avoid merge conflicts, I didn't do >>>>>> that. >>>>> >>>>> If you do that cleanup some time there are some very inaccurate >>>>> comments in relation to the initialization code in init.cpp that >>>>> could >>>>> do with correcting. And I also spotted two paths to >>>>> Interpreter::initialize. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Tested with JPRT and colocated tests. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> > From coleen.phillimore at oracle.com Tue Mar 22 22:16:27 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Mar 2016 18:16:27 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F1A5DD.3040506@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> Message-ID: <56F1C43B.9020001@oracle.com> On 3/22/16 4:06 PM, Rachel Protacio wrote: > Hi, > > On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >> >> Hi Rachel, >> >> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >> >> >> I think the line >> >> *-if (PrintOopAddress)print_address_on(st);* >> >> >> should be removed. For the case of a String that is in output for >> logging, it doesn't seem like it adds anything and then you wouldn't >> have to change the tests. >> > The part printing from the exceptions logging isn't from oop.cpp, but > klass.cpp#Klass::print_on(). Should I delete it from there instead? Ah, thank you for correcting my mistake. I think the address shouldn't be printed in the logging statement because these are used by people for debugging Java code, and not jvm code. So, yes, I think it should be deleted there also. I don't think printing these addresses are useful for debugging anymore, since we removed PermGen. Thanks, Coleen > > Rachel > >> Thanks, >> Coleen >> >> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this fix removing PrintOopAddress as a command line >>> flag. The printing functionality has been made default, except for >>> one block which has been removed (see bug description for >>> justification). A compatibility request has been accepted with >>> respect to this change. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>> >>> Passes JPRT and RBT hotspot and non-colo testing. >>> >>> Thank you, >>> Rachel >> > From david.holmes at oracle.com Wed Mar 23 00:50:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Mar 2016 10:50:03 +1000 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <50227666-E7AF-4CEE-9788-3A3EE28F2F3C@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <50227666-E7AF-4CEE-9788-3A3EE28F2F3C@oracle.com> Message-ID: <56F1E83B.1080201@oracle.com> On 23/03/2016 12:00 AM, Gerard Ziemski wrote: > Looks good. Thank you again for implementing this and taking the time to look into the optimization. Thanks Gerard. I'll wait to push this upon my return from vacation in two weeks - just in case :) David ----- > > cheers > >> On Mar 20, 2016, at 4:02 PM, David Holmes wrote: >> >> Hi Kim, >> >> Thanks for taking a look at this. >> >> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v3/ > From kim.barrett at oracle.com Wed Mar 23 01:43:02 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Mar 2016 21:43:02 -0400 Subject: RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris In-Reply-To: <56F0C67D.5060306@oracle.com> References: <56E7AABA.4000707@oracle.com> <14A9C71E-CA54-40CE-86B2-10643D0A9FA6@oracle.com> <56E87F36.6070300@oracle.com> <56E8DFF5.608@oracle.com> <0EBF8BA4-5E21-4D2F-9396-29726DC593D0@oracle.com> <56EF0FFE.7040300@oracle.com> <3846DF1F-ABF6-4955-B0C8-9901B003C070@oracle.com> <56F08B27.9000604@oracle.com> <1779D36F-2CD1-4509-B273-C76377A98DE3@oracle.com> <56F0C67D.5060306@oracle.com> Message-ID: <3F7A0C73-E93D-4513-AF99-2F74A17474E5@oracle.com> > On Mar 22, 2016, at 12:13 AM, David Holmes wrote: > > On 22/03/2016 1:21 PM, Kim Barrett wrote: >> Note, however, that the POSIX description of dlsym says (in the non-normative ?Application Usage? section): >> >> Note that conversion from a void * pointer to a function pointer as in: >> >> fptr = (int (*)(int))dlsym(handle, "my_function"); >> >> is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations. >> >> I only noticed this today. So maybe CAST_TO_FN_PTR is not needed in Unix/POSIX-specific code? > > You pre-empted my next question: given dlsym returns void* and has to be converted to a function ptr there would have to be some legal way to achieve this. :) Kind of interesting though that POSIX puts an obligation on the compiler writer. > > Looking at the C standard, given any function-ptr can be converted to another type of function-ptr and back without change, it seems to me that the return type of dlsym (and related library calls) should be void(*)(void) to be strictly correct wrt the language standards. That wouldn?t work. Not everything dlsym returns is a function pointer; it can also return pointers to variables. > But in practice as long as pointers are all the same size (which seems the obvious and common implementation [ but by no means guaranteed ]) then the conversion works correctly with no actual changes to the bits. It?s been a really long time, but I think some MS-DOS data models had the property that function pointers and data pointers had different sizes. Ah, internet to the rescue: http://www.scit.wlv.ac.uk/~in8297/CP4044/cbook/chap6/chap6.msdos.memory.html - medium. Near addresses are used for data but far addresses are used for code. This restricts the data space to 64 KByte and the code space to 256 MByte. This suggests a large complex program manipulating a small amount of data. - compact. Far addresses are used for data but near addresses are used for code. This restricts the data space to 256 MByte and the code space to 64 KByte. This suggests a small simple program manipulating a massive amount of data. Note: 256 MBytes == "massive amount of data" :-) > Just for fun I'll do a JPRT run to see if anything complains if CAST_TO_FN_PTR(type,val) simply does ((type)(val)). Which I see worked. Starter bug? Oh, but did you try #define CAST_TO_FN_PTR(type, val) reinterpret_cast(val) I found some discussions that suggest some C++ compilers allow void* -> function pointer conversion with a C-style cast and disallow with a reinterpret_cast. In other words, in some implementations there is a conversion that can *only* be done with a C-style cast, not with any C++ cast operator. Feh! Oh, and in case you are interested, here?s the C++ committee discussion: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#195 So the reinterpret_cast is conditionally supported in C++11. And I think that?s far enough down this rabbit hole for me. From ioi.lam at oracle.com Wed Mar 23 02:05:20 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 22 Mar 2016 19:05:20 -0700 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F18336.4070603@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> <56F18336.4070603@oracle.com> Message-ID: <56F1F9E0.3070307@oracle.com> I've done a little investigation on Latin1 encoding of java.lang.String and how that relates to this bug. Here's what I found: * Latin1 is is a 8-bit encoding of characters. * The first 256 Unicode characters are exactly the same as the Latin1 encoding. * So if all the jchars in a java.lang.String are <= 0xff, it can be stored in (logically) an unsigned byte array with the upper 16 bits truncated. o I am not sure if it's REQUIRED for such strings to be stored in a byte array. It might be possible to create an equivalent String with jchar[] storage. You can certainly do that with Unsafe + reflection. This function, which you removed, should return the exact same hashcode regardless whether the String was stored as a byte[] or jchar[] unsigned int java_lang_String::hash_string(oop java_string) { int length = java_lang_String::length(java_string); // Zero length string doesn't necessarily hash to zero. if (length == 0) { return StringTable::hash_string((jchar*) NULL, 0); } typeArrayOop value = java_lang_String::value(java_string); bool is_latin1 = java_lang_String::is_latin1(java_string); if (is_latin1) { return StringTable::hash_string(value->byte_at_addr(0), length); } else { return StringTable::hash_string(value->char_at_addr(0), length); } } That's because these two functions should produce the exact same result (if all the unsigned arithmetics are correct ...) static unsigned int hash_code(const jchar* s, int len) { unsigned int h = 0; while (len-- > 0) { h = 31*h + (unsigned int) *s; s++; } return h; } static unsigned int hash_code(const jbyte* s, int len) { unsigned int h = 0; while (len-- > 0) { h = 31*h + (((unsigned int) *s) & 0xFF); s++; } return h; } For shared interned strings, we actually use the version during dump time (writing into shared strings table), and the version at run time (look up from shared string table). I wrote a test and validated that the the two hashcodes are identical. So, I believe your fix for 8144940 works not because you force the body to be converted to jchar. Rather, it's because java_lang_String::hash_string does not consider StringTable::use_alternate_hashcode(). Also, I am glad that you removed the version of this template: template unsigned int StringTable::hash_string(const T* s, int len) { return use_alternate_hashcode() ? AltHashing::murmur3_32(seed(), s, len) : java_lang_String::hash_code(s, len); } // Explicit instantiation for all supported types. template unsigned int StringTable::hash_string(const jchar* s, int len); template unsigned int StringTable::hash_string(const jbyte* s, int len); Otherwise, someone is likely to call it with a UTF8 string and get unexpected results. I am not even sure if it would give identical results as the version if the input was encoded in Latin1. Thanks - Ioi On 3/22/16 10:39 AM, Coleen Phillimore wrote: > > Thank you, Jiangli. > Coleen > > On 3/22/16 1:35 PM, Jiangli Zhou wrote: >> Hi Coleen, >> >> Looks good to me. I had same question as Tobias yesterday. Your >> answer cleared it. >> >> Thanks, >> Jiangli >> >>> On Mar 22, 2016, at 10:07 AM, Coleen Phillimore >>> wrote: >>> >>> >>> Here's another webrev with the changes pointed out by Tobias and >>> verified with -XX:+VerifyStringTableAtExit. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev >>> >>> Thanks! >>> Coleen >>> >>> On 3/22/16 12:21 PM, Tobias Hartmann wrote: >>>> Hi Coleen, >>>> >>>> On 22.03.2016 13:40, Coleen Phillimore wrote: >>>>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>>>> Summary: Fix code broken with compact Strings. >>>>>>> >>>>>>> One of the failure modes of an intermittent bug (but this >>>>>>> failure is not intermittent). >>>>>>> >>>>>>> Tested with the failing test cases that exercise this code. >>>>>>> Also, testing in order to find linked bugs. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>>>> I wonder why the result is different if you first convert the >>>>>> latin1 String to Unicode and then use the jchar hash_string() >>>>>> version compared to just using the jbyte hash_string() version? >>>>>> Is it because the jbyte version of AltHashing::murmur3_32() is used? >>>>> Yes, I believe it is. >>>> Okay, thanks for checking. >>>> >>>>>> Now we don't need the StringTable::hash_string version >>>>>> anymore, right? >>>>> This one is used by Symbol* which are jbyte. >>>> I only see jchar uses of StringTable::hash_string() (after your >>>> fix). Are you confusing it with java_lang_String::hash_code() which >>>> also has a jbyte and jchar version? This one is indeed used by the >>>> SymbolTable. >>>> >>>>>> Just noticed that there is an unused "latin1_hash_code" in >>>>>> javaClasses.hpp which can be removed as well. >>>>> Thank you, I'll remove it. >>>> Thanks! >>>> >>>> Best regards, >>>> Tobias >>>> >>>>>> Thanks for fixing this! >>>>> Thanks for reviewing it! >>>>> Coleen >>>>>> Best regards, >>>>>> Tobias >>>>>> >>>>>>> Thanks, >>>>>>> Coleen > From tobias.hartmann at oracle.com Wed Mar 23 07:15:55 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Mar 2016 08:15:55 +0100 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F1F9E0.3070307@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> <56F18336.4070603@oracle.com> <56F1F9E0.3070307@oracle.com> Message-ID: <56F242AB.9060201@oracle.com> Hi Ioi, On 23.03.2016 03:05, Ioi Lam wrote: > I've done a little investigation on Latin1 encoding of java.lang.String and how that relates to this bug. Here's what I found: > > * Latin1 is is a 8-bit encoding of characters. > * The first 256 Unicode characters are exactly the same as the Latin1 > encoding. > * So if all the jchars in a java.lang.String are <= 0xff, it can be > stored in (logically) an unsigned byte array with the upper 16 bits > truncated. > o I am not sure if it's REQUIRED for such strings to be stored in > a byte array. It might be possible to create an equivalent > String with jchar[] storage. You can certainly do that with > Unsafe + reflection. With Compact Strings enabled, it is required that all Latin1 encoded Strings are "compressed", i.e., all jchars are truncated to jbytes and String.coder == LATIN1. For example, String.equals() relies on this by returning false if the coders are different (without looking at the actual content of the Strings). Of course, you can break this with reflection. > This function, which you removed, should return the exact same hashcode regardless whether the String was stored as a byte[] or jchar[] > > unsigned int java_lang_String::hash_string(oop java_string) { > int length = java_lang_String::length(java_string); > // Zero length string doesn't necessarily hash to zero. > if (length == 0) { > return StringTable::hash_string((jchar*) NULL, 0); > } > > typeArrayOop value = java_lang_String::value(java_string); > bool is_latin1 = java_lang_String::is_latin1(java_string); > if (is_latin1) { > return StringTable::hash_string(value->byte_at_addr(0), length); > } else { > return StringTable::hash_string(value->char_at_addr(0), length); > } > } > > That's because these two functions should produce the exact same result (if all the unsigned arithmetics are correct ...) > > static unsigned int hash_code(const jchar* s, int len) { > unsigned int h = 0; > while (len-- > 0) { > h = 31*h + (unsigned int) *s; > s++; > } > return h; > } > > static unsigned int hash_code(const jbyte* s, int len) { > unsigned int h = 0; > while (len-- > 0) { > h = 31*h + (((unsigned int) *s) & 0xFF); > s++; > } > return h; > } > > For shared interned strings, we actually use the version during dump time (writing into shared strings table), and the version at run time (look up from shared string table). I wrote a test and validated that the the two hashcodes are identical. > > So, I believe your fix for 8144940 works not because you force the body to be converted to jchar. Rather, it's because java_lang_String::hash_string does not consider StringTable::use_alternate_hashcode(). > > Also, I am glad that you removed the version of this template: > > template > unsigned int StringTable::hash_string(const T* s, int len) { > return use_alternate_hashcode() ? AltHashing::murmur3_32(seed(), > s, len) : > java_lang_String::hash_code(s, > len); > } > > // Explicit instantiation for all supported types. > template unsigned int StringTable::hash_string(const jchar* > s, int len); > template unsigned int StringTable::hash_string(const jbyte* > s, int len); > > Otherwise, someone is likely to call it with a UTF8 string and get unexpected results. I am not even sure if it would give identical results as the version if the input was encoded in Latin1. Yes, that's what I meant by "Is it because the jbyte version of AltHashing::murmur3_32() is used?". Thanks for clarifying. Best regards, Tobias > > Thanks > - Ioi > > On 3/22/16 10:39 AM, Coleen Phillimore wrote: >> >> Thank you, Jiangli. >> Coleen >> >> On 3/22/16 1:35 PM, Jiangli Zhou wrote: >>> Hi Coleen, >>> >>> Looks good to me. I had same question as Tobias yesterday. Your answer cleared it. >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 22, 2016, at 10:07 AM, Coleen Phillimore wrote: >>>> >>>> >>>> Here's another webrev with the changes pointed out by Tobias and verified with -XX:+VerifyStringTableAtExit. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev >>>> >>>> Thanks! >>>> Coleen >>>> >>>> On 3/22/16 12:21 PM, Tobias Hartmann wrote: >>>>> Hi Coleen, >>>>> >>>>> On 22.03.2016 13:40, Coleen Phillimore wrote: >>>>>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>>>>> Summary: Fix code broken with compact Strings. >>>>>>>> >>>>>>>> One of the failure modes of an intermittent bug (but this failure is not intermittent). >>>>>>>> >>>>>>>> Tested with the failing test cases that exercise this code. Also, testing in order to find linked bugs. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>>>>> I wonder why the result is different if you first convert the latin1 String to Unicode and then use the jchar hash_string() version compared to just using the jbyte hash_string() version? Is it because the jbyte version of AltHashing::murmur3_32() is used? >>>>>> Yes, I believe it is. >>>>> Okay, thanks for checking. >>>>> >>>>>>> Now we don't need the StringTable::hash_string version anymore, right? >>>>>> This one is used by Symbol* which are jbyte. >>>>> I only see jchar uses of StringTable::hash_string() (after your fix). Are you confusing it with java_lang_String::hash_code() which also has a jbyte and jchar version? This one is indeed used by the SymbolTable. >>>>> >>>>>>> Just noticed that there is an unused "latin1_hash_code" in javaClasses.hpp which can be removed as well. >>>>>> Thank you, I'll remove it. >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>>>> Thanks for fixing this! >>>>>> Thanks for reviewing it! >>>>>> Coleen >>>>>>> Best regards, >>>>>>> Tobias >>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >> > From paul.sandoz at oracle.com Wed Mar 23 10:55:41 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 Mar 2016 11:55:41 +0100 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F1ADEC.2050508@oracle.com> References: <56F1ADEC.2050508@oracle.com> Message-ID: Hi Dan, Well done on finding the root cause and fix for this ?bug from hell?! Do you have any wisdom to share on the techniques and approach taken to debug and find the cause? these kinds of bugs are not easy so it?s often useful to share such advice. Amy and I spent a bit of time just getting a test case that could reproduce in a ?reasonable? period of time with enough confidence it was something in HotSpot (bisecting builds), and then we threw it over the fence to you :-) Paul. > On 22 Mar 2016, at 21:41, Daniel D. Daugherty wrote: > > Greetings, > > I have fixes for the following two bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > Both fixes are very, very small and will be bundled together in the > same changeset for obvious reasons. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ > > While the fix for JDK-8077392 is a simple 1-liner, the explanation of > the race is much, much longer. I've attached the detailed evaluation > to this RFR; it is a copy of the same note that I added to > https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached > copy has all the indentation white space intact. I don't know why > JBS likes to reformat the notes, but it does... :-( > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan > From david.holmes at oracle.com Wed Mar 23 11:40:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Mar 2016 21:40:55 +1000 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56F1381D.7040009@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> <56F0A8CF.4090502@oracle.com> <56F1381D.7040009@oracle.com> Message-ID: <56F280C7.9030804@oracle.com> Hi Coleen, Thank goodness for inflight wi-fi, I nearly missed this when my battery died at the airport :) Thumbs up! More inline ... On 22/03/2016 10:18 PM, Coleen Phillimore wrote: > > Hi David, > Thank you for reviewing. > > On 3/21/16 10:07 PM, David Holmes wrote: >> On 22/03/2016 12:05 AM, Coleen Phillimore wrote: >>> On 3/21/16 1:12 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>>>> Summary: Deferred code review cleanups >>>>> >>>>> This was a review comment I had when the StackWalk API was integrated. >>>>> There were too many of this same code pattern in the middle of >>>>> universe_post_init. The only real change here is that if the method >>>>> isn't found and doesn't have the right linkage because of a >>>>> mismatch in >>>>> JDK version, we can vm_exit_during_initialization() rather than try to >>>>> return JNI_ERR. This avoids ugly code to check >>>>> initialize_known_method's boolean result for each call. We can't >>>>> throw >>>>> an exception here. Because of the EXCEPTION_MARK in >>>>> universe_post_init, >>>>> any exception gets turned into vm_exit_during_initialization >>>>> anyway. But >>>>> this wouldn't be a user error, so vm_exit_during_initialization seemed >>>>> like the cleanest choice. >>>> >>>> Our initialization code is truly awful. Until the VM is initialized >>>> any/all exceptions have to convert back to a different form of error >>>> because there will be no thread (or JVM for that matter) on which the >>>> user code could ask if an exception occurred. It then comes down to >>>> whether an error should be reported to the caller of JNI_CreateJavaVM >>>> so the host program doesn't get terminated, or we abort everything >>>> with vm_exit_during_initialization. And we're sliding further and >>>> further into always doing the latter. >>>> >>>> So in an absolute sense the new code is incompatible with the old >>>> because it will terminate host applications that wouldn't previously >>>> have been terminated - but in a practical sense this is unlikely to >>>> make any real difference to anything. >>>> >>>> That said something about all this is really bugging me. If we can do: >>>> >>>> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >>>> >>>> which purports to allow an exception to have been posted then how is >>>> it the immediately following code: >>>> >>>> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >>>> ! vmSymbols::register_method_name(), >>>> ! vmSymbols::register_method_signature()); >>>> ! if (m == NULL || !m->is_static()) { >>>> ! tty->print_cr("Unable to link/verify Finalizer.register method"); >>>> ! return false; // initialization failed (cannot throw exception >>>> yet) >>>> ! } >>>> >>>> can not throw an exception yet? Either both can throw or neither can >>>> throw AFAICS. So maybe the refactored link() call should not be using >>>> CHECK_ but also exit immediately? >>> >>> I don't think we should refactor InstanceKlass::link_class() for this. >> >> I wasn't suggesting that. As I said either both bits of code can throw >> exceptions or neither can, and I would have to assume it is the >> latter. link_class can be replaced by link_class_or_fail ie this: >> >> ik->link_class(CHECK); >> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >> Method* m = ik->find_method(name, signature); >> if (m == NULL || is_static != m->is_static()) { >> ResourceMark rm(THREAD); >> vm_exit_during_initialization(err_msg("Unable to link/verify >> %s.%s method", >> ik->name()->as_C_string(), method)); >> } >> >> becomes (hope I get this right): >> >> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >> Method* m = NULL; >> if (!ik->link_class_or_fail(THREAD) || >> ((m = ik->find_method(name, signature)) == NULL) || >> is_static != m->is_static()) { >> ResourceMark rm(THREAD); >> vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s >> method", >> ik->name()->as_C_string(), method)); >> } >> >> The CHECK on new_symbol is still a pretense but ... >> > > Yes, the CHECK in link_class is also a pretense. I added some dummy > code to throw a VerifyError and it got the assertion: > > # assert(resolved_method->method_holder()->is_linked()) failed: must be > linked > > From trying to call the Throwable.. I thought we had fixed the > jvm to handle this better. I think we moved the failure point but ultimately there has to be some point before which you can't throw an exception as it depends on initialization of classes that have failed for some reason. But as I said it would be interesting to see the actual order of linking for this particular chunk of code. > I think the code I had is easier to read, but in appreciation for your > code reviews, I've changed it to your if statement and retested. > > http://cr.openjdk.java.net/~coleenp/8143269.02/webrev Much appreciated. It really makes little sense to me to pretend to throw on one line and then vm-exit because we know we can't throw. > >>> I can rewrite so that every initialize_known_method call does: >>> >>> bool ok; >>> ok = initialize_known_method(, CHECK); >>> if (!ok) return ok; >>> >>> ok = initialize_known_method(, CHECK); >>> if (!ok) return ok; >>> >>> ... >>> >>> return true; >>> >>> Which I thought was really ugly and meaningless, since as I said, this >>> case is really an assert that the library doesn't match. >> >> I'm not sure why you are suggesting that. It would only make sense if >> if there were no vm_exit_during_initialization. ?? > > Right, which I thought was the objection. I was commenting on the potential change of behaviour but as I noted it is not a practical matter and as you said these failures really indicate a basic error in terms of the jdk+hotspot combination. So all good there. (I should make my commentary and my "review" more separate.) Thanks, David ----- >> >> It would be interesting to see exactly when java_lang_Class is linked >> in relation to this code executing, so we could see when it would be >> possible to just throw the exceptions in all cases. Pity there seems >> to be no logging for class linking. >> >>> I could change it to an assert. >>> >>> Which is your preference? This is not my preference. >> >> I'm not sure what you would assert and where ?? >> > > I meant a fatal() call instead of vm_exit_during_initialization() since > the case that I'm calling it is an error in the JVM, not really from a > users perspective. > > And YES, initialization is a messy business. Kim filed this bug a while > ago for one aspect of initialization. Throwing exceptions and/or > returning JNI_ERR is another aspect that makes it messy. Returning > JNI_ERR to some process embedding the JVM means that we've cleaned up > memory that we've allocated, of course, we haven't done that. I think > we have other bugs like that too. > > https://bugs.openjdk.java.net/browse/JDK-8068392 > > Thanks, > Coleen > >> Thanks, >> David >> >>> Thanks, >>> Coleen >>>> >>>>> Also, I want to get the code to not have to include method names (and >>>>> field names) in vmSymbols.cpp. >>>>> >>>>> I verified that this code won't merge conflict with jigsaw. There are >>>>> many additional cleanups that can be done here. universe_post_init >>>>> should really be a method belonging to Universe since it sets many >>>>> static fields in Universe, but to avoid merge conflicts, I didn't do >>>>> that. >>>> >>>> If you do that cleanup some time there are some very inaccurate >>>> comments in relation to the initialization code in init.cpp that could >>>> do with correcting. And I also spotted two paths to >>>> Interpreter::initialize. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Tested with JPRT and colocated tests. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From david.holmes at oracle.com Wed Mar 23 11:43:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Mar 2016 21:43:45 +1000 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56F17860.3020604@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> <56ECBB5B.9070008@oracle.com> <56F17860.3020604@oracle.com> Message-ID: <56F28171.6040606@oracle.com> Looks fine. Thanks, David On 23/03/2016 2:52 AM, Max Ockner wrote: > Thanks David. > > I have another webrev which moved the delcaration of "replacement" > inside of the #ifndef PRODUCT. > http://cr.openjdk.java.net/~mockner/8146632.03/ > > Max > > On 3/18/2016 10:37 PM, David Holmes wrote: >> Objections withdrawn. Code Reviewed. >> >> Thanks, >> David >> >> On 19/03/2016 7:49 AM, David Holmes wrote: >>> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/18/16 8:45 AM, David Holmes wrote: >>>>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>>>> version in >>>>>>>> the table might be helpful for documentation purposes so we know in >>>>>>>> the >>>>>>>> future when to remove the line from the table. I agree with your >>>>>>>> implementation choice to have an additional table rather than >>>>>>>> twisting >>>>>>>> the other table to cover this use case. >>>>>>> >>>>>>> I don't I'm afraid - it is yet another special case and no automatic >>>>>>> dropping of the message when we switch to JDK 10. Can't it be folded >>>>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>>>> conversion of the non-product flags to UL has to be handled >>>>>>> differently to the product ones ?? >>>>>> >>>>>> The deprecation of non-product flags has always been different than >>>>>> product flags. The AliasedLogging flags alias the old option with >>>>>> the >>>>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>>>> removed. Non-product flags can be removed without deprecation. This >>>>>> new >>>>>> table is just to improve the error message temporarily for >>>>>> non-product >>>>>> flags. >>>>>> >>>>>> It can't be handled with the aliased logging flag table because they >>>>>> convert the option. It is the intent to remove these options. >>>>>>> >>>>>>> Aren't these just deprecated flags? We internally convert them to >>>>>>> their replacement form and issue a warning that they are going away? >>>>>> >>>>>> The intent was to make a nice error message for the non-product >>>>>> flags we >>>>>> removed to help internal users. i thought you agreed to this in >>>>>> concept. >>>>> >>>>> Concept yes but I'm frustrated by the mechanism - we have too many >>>>> special cases with all this option processing, and too many tables. >>>>> >>>>> As you said above non-product flags can be removed without >>>>> deprecation, but all deprecation does is produce a nice error message >>>>> when you use the flag, and you want to add a nice error message for >>>>> this case so you have in fact turned it back into a deprecation! >>>> >>>> Deprecation is ignore and run the JVM. This is going to exit the JVM >>>> with unrecognized option with a nicer message. >>> >>> So it is a special case of "expired" which means it isn't really expired >>> because the VM still has to know about it. Hence >>> yet-another-kind-of-flag. >>> >>> Seems to me this would all be a lot simpler if we treated the >>> non-product flags the same as product and just aliased and deprecated >>> them in 9, then expire in 10. There seems to be no benefit in what we >>> are doing only added complexity. >>> >>> David >>> >>>> Coleen >>>>> >>>>> David >>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think Harold's refactoring makes sense and I think the #endif // >>>>>>>> PRODUCT >>>>>>>> >>>>>>>> } >>>>>>>> *+ #ifndef PRODUCT* >>>>>>>> *+ else if ((replacement = >>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>> stripped_argname, >>>>>>>> replacement);* >>>>>>>> *+ return false;* >>>>>>>> *+ #endif* >>>>>>>> *+ }* >>>>>>>> >>>>>>>> >>>>>>>> I think this should be like this so the {} match inside of #ifndef >>>>>>>> PRODUCT: >>>>>>>> >>>>>>>> *+ #ifndef PRODUCT* >>>>>>>> *+ } else if ((replacement = >>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>> stripped_argname, >>>>>>>> replacement);* >>>>>>>> *+ return false;* >>>>>>>> *+ #endif* >>>>>>>> *+ }* >>>>>>>> >>>>>>>> >>>>>>>> Or refactor as Harold suggested. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>>>> I did, but it blended in with the rest of the text >>>>>>>>> >>>>>>>>> My response: "Seems appropriate to report a specific error message >>>>>>>>> for >>>>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>>>> Version >>>>>>>>> in the table to keep track of when each entry needs to be deleted, >>>>>>>>> like what is done in the table of obsolete flags. " >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> You should also answer David's concern. >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>>>> >>>>>>>>>>> Comments below. >>>>>>>>>>> >>>>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>>>> Hello again everyone! >>>>>>>>>>>>> >>>>>>>>>>>>> Please review this change which adds better error messages for >>>>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>>>> >>>>>>>>>>>>> Since these options have been removed, we want still want the >>>>>>>>>>>>> vm to >>>>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>>>> command >>>>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>>>> >>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>> instead." >>>>>>>>>>>>> >>>>>>>>>>>>> The entire output looks like this: >>>>>>>>>>>>> >>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>> instead. >>>>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>>>> >>>>>>>>>>>> I'm concerned that this has introduced another variant of "flag >>>>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>>>> should >>>>>>>>>>>> be removed. Maybe we need to add "replaced" as another type of >>>>>>>>>>>> flag >>>>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>>>> then in >>>>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>>>> then >>>>>>>>>>> remove it for 10. If it would help, we can store a Version in >>>>>>>>>>> the >>>>>>>>>>> table to keep track of when each entry needs to be deleted, like >>>>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>>>> appropriate >>>>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>>>> converted to >>>>>>>>>>>>> logging. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> > From coleen.phillimore at oracle.com Wed Mar 23 11:49:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Mar 2016 07:49:05 -0400 Subject: RFR (s) 8143269: Refactor code in universe_post_init that sets up methods to upcall In-Reply-To: <56F280C7.9030804@oracle.com> References: <56ED4CAE.7010009@oracle.com> <56EF82D6.7020605@oracle.com> <56EFFFA8.30600@oracle.com> <56F0A8CF.4090502@oracle.com> <56F1381D.7040009@oracle.com> <56F280C7.9030804@oracle.com> Message-ID: <56F282B1.9020200@oracle.com> On 3/23/16 7:40 AM, David Holmes wrote: > Hi Coleen, > > Thank goodness for inflight wi-fi, I nearly missed this when my > battery died at the airport :) Have a good vacation! I was going to list you as a reviewer if you didn't answer anyway. I think the vm initialization cleanup work is something that will be around when you get back ;) Thanks for closing the loop on this. Coleen > > Thumbs up! More inline ... > > On 22/03/2016 10:18 PM, Coleen Phillimore wrote: >> >> Hi David, >> Thank you for reviewing. >> >> On 3/21/16 10:07 PM, David Holmes wrote: >>> On 22/03/2016 12:05 AM, Coleen Phillimore wrote: >>>> On 3/21/16 1:12 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 19/03/2016 10:57 PM, Coleen Phillimore wrote: >>>>>> Summary: Deferred code review cleanups >>>>>> >>>>>> This was a review comment I had when the StackWalk API was >>>>>> integrated. >>>>>> There were too many of this same code pattern in the middle of >>>>>> universe_post_init. The only real change here is that if the method >>>>>> isn't found and doesn't have the right linkage because of a >>>>>> mismatch in >>>>>> JDK version, we can vm_exit_during_initialization() rather than >>>>>> try to >>>>>> return JNI_ERR. This avoids ugly code to check >>>>>> initialize_known_method's boolean result for each call. We can't >>>>>> throw >>>>>> an exception here. Because of the EXCEPTION_MARK in >>>>>> universe_post_init, >>>>>> any exception gets turned into vm_exit_during_initialization >>>>>> anyway. But >>>>>> this wouldn't be a user error, so vm_exit_during_initialization >>>>>> seemed >>>>>> like the cleanest choice. >>>>> >>>>> Our initialization code is truly awful. Until the VM is initialized >>>>> any/all exceptions have to convert back to a different form of error >>>>> because there will be no thread (or JVM for that matter) on which the >>>>> user code could ask if an exception occurred. It then comes down to >>>>> whether an error should be reported to the caller of JNI_CreateJavaVM >>>>> so the host program doesn't get terminated, or we abort everything >>>>> with vm_exit_during_initialization. And we're sliding further and >>>>> further into always doing the latter. >>>>> >>>>> So in an absolute sense the new code is incompatible with the old >>>>> because it will terminate host applications that wouldn't previously >>>>> have been terminated - but in a practical sense this is unlikely to >>>>> make any real difference to anything. >>>>> >>>>> That said something about all this is really bugging me. If we can >>>>> do: >>>>> >>>>> ! SystemDictionary::Finalizer_klass()->link_class(CHECK_false); >>>>> >>>>> which purports to allow an exception to have been posted then how is >>>>> it the immediately following code: >>>>> >>>>> ! Method* m = SystemDictionary::Finalizer_klass()->find_method( >>>>> ! vmSymbols::register_method_name(), >>>>> ! vmSymbols::register_method_signature()); >>>>> ! if (m == NULL || !m->is_static()) { >>>>> ! tty->print_cr("Unable to link/verify Finalizer.register >>>>> method"); >>>>> ! return false; // initialization failed (cannot throw exception >>>>> yet) >>>>> ! } >>>>> >>>>> can not throw an exception yet? Either both can throw or neither can >>>>> throw AFAICS. So maybe the refactored link() call should not be using >>>>> CHECK_ but also exit immediately? >>>> >>>> I don't think we should refactor InstanceKlass::link_class() for this. >>> >>> I wasn't suggesting that. As I said either both bits of code can throw >>> exceptions or neither can, and I would have to assume it is the >>> latter. link_class can be replaced by link_class_or_fail ie this: >>> >>> ik->link_class(CHECK); >>> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >>> Method* m = ik->find_method(name, signature); >>> if (m == NULL || is_static != m->is_static()) { >>> ResourceMark rm(THREAD); >>> vm_exit_during_initialization(err_msg("Unable to link/verify >>> %s.%s method", >>> ik->name()->as_C_string(), method)); >>> } >>> >>> becomes (hope I get this right): >>> >>> TempNewSymbol name = SymbolTable::new_symbol(method, CHECK); >>> Method* m = NULL; >>> if (!ik->link_class_or_fail(THREAD) || >>> ((m = ik->find_method(name, signature)) == NULL) || >>> is_static != m->is_static()) { >>> ResourceMark rm(THREAD); >>> vm_exit_during_initialization(err_msg("Unable to link/verify %s.%s >>> method", >>> ik->name()->as_C_string(), method)); >>> } >>> >>> The CHECK on new_symbol is still a pretense but ... >>> >> >> Yes, the CHECK in link_class is also a pretense. I added some dummy >> code to throw a VerifyError and it got the assertion: >> >> # assert(resolved_method->method_holder()->is_linked()) failed: must be >> linked >> >> From trying to call the Throwable.. I thought we had fixed the >> jvm to handle this better. > > I think we moved the failure point but ultimately there has to be some > point before which you can't throw an exception as it depends on > initialization of classes that have failed for some reason. But as I > said it would be interesting to see the actual order of linking for > this particular chunk of code. > >> I think the code I had is easier to read, but in appreciation for your >> code reviews, I've changed it to your if statement and retested. >> >> http://cr.openjdk.java.net/~coleenp/8143269.02/webrev > > Much appreciated. It really makes little sense to me to pretend to > throw on one line and then vm-exit because we know we can't throw. > >> >>>> I can rewrite so that every initialize_known_method call does: >>>> >>>> bool ok; >>>> ok = initialize_known_method(, CHECK); >>>> if (!ok) return ok; >>>> >>>> ok = initialize_known_method(, CHECK); >>>> if (!ok) return ok; >>>> >>>> ... >>>> >>>> return true; >>>> >>>> Which I thought was really ugly and meaningless, since as I said, this >>>> case is really an assert that the library doesn't match. >>> >>> I'm not sure why you are suggesting that. It would only make sense if >>> if there were no vm_exit_during_initialization. ?? >> >> Right, which I thought was the objection. > > I was commenting on the potential change of behaviour but as I noted > it is not a practical matter and as you said these failures really > indicate a basic error in terms of the jdk+hotspot combination. So all > good there. (I should make my commentary and my "review" more separate.) > > Thanks, > David > ----- > >>> >>> It would be interesting to see exactly when java_lang_Class is linked >>> in relation to this code executing, so we could see when it would be >>> possible to just throw the exceptions in all cases. Pity there seems >>> to be no logging for class linking. >>> >>>> I could change it to an assert. >>>> >>>> Which is your preference? This is not my preference. >>> >>> I'm not sure what you would assert and where ?? >>> >> >> I meant a fatal() call instead of vm_exit_during_initialization() since >> the case that I'm calling it is an error in the JVM, not really from a >> users perspective. >> >> And YES, initialization is a messy business. Kim filed this bug a while >> ago for one aspect of initialization. Throwing exceptions and/or >> returning JNI_ERR is another aspect that makes it messy. Returning >> JNI_ERR to some process embedding the JVM means that we've cleaned up >> memory that we've allocated, of course, we haven't done that. I think >> we have other bugs like that too. >> >> https://bugs.openjdk.java.net/browse/JDK-8068392 >> >> Thanks, >> Coleen >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>>> >>>>>> Also, I want to get the code to not have to include method names >>>>>> (and >>>>>> field names) in vmSymbols.cpp. >>>>>> >>>>>> I verified that this code won't merge conflict with jigsaw. There >>>>>> are >>>>>> many additional cleanups that can be done here. universe_post_init >>>>>> should really be a method belonging to Universe since it sets many >>>>>> static fields in Universe, but to avoid merge conflicts, I didn't do >>>>>> that. >>>>> >>>>> If you do that cleanup some time there are some very inaccurate >>>>> comments in relation to the initialization code in init.cpp that >>>>> could >>>>> do with correcting. And I also spotted two paths to >>>>> Interpreter::initialize. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Tested with JPRT and colocated tests. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8143269.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8143269 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From robbin.ehn at oracle.com Wed Mar 23 13:50:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 23 Mar 2016 14:50:17 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4) In-Reply-To: <56F02283.10908@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> Message-ID: <56F29F19.9030409@oracle.com> Hi all, After more input, this is the current version. Please have a look. Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/ Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/ Thanks! /Robbin On 03/21/2016 05:34 PM, Robbin Ehn wrote: > Hi all, please review this a somewhat bigger change-set. > > Updated with the feedback. > > New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ > > Tested with jprt hotspot and I added 2 internal vm tests. > > (also 2 bugs fixed, missing va_end and a potential race when calling > prefix function twice (very unlikely)) > > Thanks! > > /Robbin > > On 03/16/2016 01:33 PM, Robbin Ehn wrote: >> Hi, please review this small change. >> >> This also change allocation methods. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >> >> Thanks! >> >> /Robbin From max.ockner at oracle.com Wed Mar 23 14:18:09 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 23 Mar 2016 10:18:09 -0400 Subject: RFR: 8146632: Add descriptive error messages for removed non-product logging flags. In-Reply-To: <56F28171.6040606@oracle.com> References: <56E84A2D.30304@oracle.com> <56E8F39B.3000402@oracle.com> <56E9A087.8010101@oracle.com> <56E9A4EB.20402@oracle.com> <56E9AE56.7050500@oracle.com> <56E9B1F8.3040800@oracle.com> <56EB8040.5090509@oracle.com> <56EBED6B.3000009@oracle.com> <56EBF855.6060008@oracle.com> <56EC0AA5.6000108@oracle.com> <56EC77D5.4080603@oracle.com> <56ECBB5B.9070008@oracle.com> <56F17860.3020604@oracle.com> <56F28171.6040606@oracle.com> Message-ID: <56F2A5A1.7020306@oracle.com> Thanks everyone! On 3/23/2016 7:43 AM, David Holmes wrote: > Looks fine. > > Thanks, > David > > On 23/03/2016 2:52 AM, Max Ockner wrote: >> Thanks David. >> >> I have another webrev which moved the delcaration of "replacement" >> inside of the #ifndef PRODUCT. >> http://cr.openjdk.java.net/~mockner/8146632.03/ >> >> Max >> >> On 3/18/2016 10:37 PM, David Holmes wrote: >>> Objections withdrawn. Code Reviewed. >>> >>> Thanks, >>> David >>> >>> On 19/03/2016 7:49 AM, David Holmes wrote: >>>> On 19/03/2016 12:03 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/18/16 8:45 AM, David Holmes wrote: >>>>>> On 18/03/2016 9:58 PM, Coleen Phillimore wrote: >>>>>>> On 3/18/16 12:12 AM, David Holmes wrote: >>>>>>>> On 17/03/2016 5:20 AM, Coleen Phillimore wrote: >>>>>>>>> Okay, I didn't see your reply. I also thought that storing a >>>>>>>>> version in >>>>>>>>> the table might be helpful for documentation purposes so we >>>>>>>>> know in >>>>>>>>> the >>>>>>>>> future when to remove the line from the table. I agree with your >>>>>>>>> implementation choice to have an additional table rather than >>>>>>>>> twisting >>>>>>>>> the other table to cover this use case. >>>>>>>> >>>>>>>> I don't I'm afraid - it is yet another special case and no >>>>>>>> automatic >>>>>>>> dropping of the message when we switch to JDK 10. Can't it be >>>>>>>> folded >>>>>>>> into the AliasedLoggingFlag support? I'm really not seeing why the >>>>>>>> conversion of the non-product flags to UL has to be handled >>>>>>>> differently to the product ones ?? >>>>>>> >>>>>>> The deprecation of non-product flags has always been different than >>>>>>> product flags. The AliasedLogging flags alias the old option with >>>>>>> the >>>>>>> new flag because they are "deprecated", ie. warned (tbd) but not >>>>>>> removed. Non-product flags can be removed without deprecation. >>>>>>> This >>>>>>> new >>>>>>> table is just to improve the error message temporarily for >>>>>>> non-product >>>>>>> flags. >>>>>>> >>>>>>> It can't be handled with the aliased logging flag table because >>>>>>> they >>>>>>> convert the option. It is the intent to remove these options. >>>>>>>> >>>>>>>> Aren't these just deprecated flags? We internally convert them to >>>>>>>> their replacement form and issue a warning that they are going >>>>>>>> away? >>>>>>> >>>>>>> The intent was to make a nice error message for the non-product >>>>>>> flags we >>>>>>> removed to help internal users. i thought you agreed to this in >>>>>>> concept. >>>>>> >>>>>> Concept yes but I'm frustrated by the mechanism - we have too many >>>>>> special cases with all this option processing, and too many tables. >>>>>> >>>>>> As you said above non-product flags can be removed without >>>>>> deprecation, but all deprecation does is produce a nice error >>>>>> message >>>>>> when you use the flag, and you want to add a nice error message for >>>>>> this case so you have in fact turned it back into a deprecation! >>>>> >>>>> Deprecation is ignore and run the JVM. This is going to exit the >>>>> JVM >>>>> with unrecognized option with a nicer message. >>>> >>>> So it is a special case of "expired" which means it isn't really >>>> expired >>>> because the VM still has to know about it. Hence >>>> yet-another-kind-of-flag. >>>> >>>> Seems to me this would all be a lot simpler if we treated the >>>> non-product flags the same as product and just aliased and deprecated >>>> them in 9, then expire in 10. There seems to be no benefit in what we >>>> are doing only added complexity. >>>> >>>> David >>>> >>>>> Coleen >>>>>> >>>>>> David >>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mockner/8146632.02/src/share/vm/runtime/arguments.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I think Harold's refactoring makes sense and I think the >>>>>>>>> #endif // >>>>>>>>> PRODUCT >>>>>>>>> >>>>>>>>> } >>>>>>>>> *+ #ifndef PRODUCT* >>>>>>>>> *+ else if ((replacement = >>>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL){* >>>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>>> stripped_argname, >>>>>>>>> replacement);* >>>>>>>>> *+ return false;* >>>>>>>>> *+ #endif* >>>>>>>>> *+ }* >>>>>>>>> >>>>>>>>> >>>>>>>>> I think this should be like this so the {} match inside of >>>>>>>>> #ifndef >>>>>>>>> PRODUCT: >>>>>>>>> >>>>>>>>> *+ #ifndef PRODUCT* >>>>>>>>> *+ } else if ((replacement = >>>>>>>>> removed_develop_logging_flag_name(stripped_argname)) != NULL) {* >>>>>>>>> *+ jio_fprintf(defaultStream::error_stream(),* >>>>>>>>> *+ "%s has been removed. Please use %s instead.\n", >>>>>>>>> stripped_argname, >>>>>>>>> replacement);* >>>>>>>>> *+ return false;* >>>>>>>>> *+ #endif* >>>>>>>>> *+ }* >>>>>>>>> >>>>>>>>> >>>>>>>>> Or refactor as Harold suggested. >>>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 3/16/16 3:04 PM, Max Ockner wrote: >>>>>>>>>> I did, but it blended in with the rest of the text >>>>>>>>>> >>>>>>>>>> My response: "Seems appropriate to report a specific error >>>>>>>>>> message >>>>>>>>>> for >>>>>>>>>> 9 and then remove it for 10. If it would help, we can store a >>>>>>>>>> Version >>>>>>>>>> in the table to keep track of when each entry needs to be >>>>>>>>>> deleted, >>>>>>>>>> like what is done in the table of obsolete flags. " >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/16/2016 2:24 PM, Coleen Phillimore wrote: >>>>>>>>>>> >>>>>>>>>>> You should also answer David's concern. >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> On 3/16/16 2:05 PM, Max Ockner wrote: >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632.02/ >>>>>>>>>>>> - Labeled #endif with // PRODUCT >>>>>>>>>>>> - refactored table lookup code to only do lookup once. >>>>>>>>>>>> - Added VerboseVerification to the table. >>>>>>>>>>>> >>>>>>>>>>>> Comments below. >>>>>>>>>>>> >>>>>>>>>>>> On 3/16/2016 1:48 AM, David Holmes wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> On 16/03/2016 3:45 AM, Max Ockner wrote: >>>>>>>>>>>>>> Hello again everyone! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review this change which adds better error >>>>>>>>>>>>>> messages for >>>>>>>>>>>>>> non-product flags that are now converted to Unified Logging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146632 >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8146632/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since these options have been removed, we want still want >>>>>>>>>>>>>> the >>>>>>>>>>>>>> vm to >>>>>>>>>>>>>> crash here, but now with an error message giving the correct >>>>>>>>>>>>>> command >>>>>>>>>>>>>> line option. The new message looks like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>>> instead." >>>>>>>>>>>>>> >>>>>>>>>>>>>> The entire output looks like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > TraceClassInitialization has been removed. Please use >>>>>>>>>>>>>> -Xlog:classinit >>>>>>>>>>>>>> instead. >>>>>>>>>>>>>> > Error: Could not create the Java Virtual Machine. >>>>>>>>>>>>>> > Error: A fatal exception has occurred. Program will exit. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm concerned that this has introduced another variant of >>>>>>>>>>>>> "flag >>>>>>>>>>>>> deprecation". It begs the question as to when this new code >>>>>>>>>>>>> should >>>>>>>>>>>>> be removed. Maybe we need to add "replaced" as another >>>>>>>>>>>>> type of >>>>>>>>>>>>> flag >>>>>>>>>>>>> change so we can report in 9 the flag has been replaced and >>>>>>>>>>>>> then in >>>>>>>>>>>>> 10 just report an "unknown option" error ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>> Seems appropriate to report a specific error message for 9 and >>>>>>>>>>>> then >>>>>>>>>>>> remove it for 10. If it would help, we can store a Version in >>>>>>>>>>>> the >>>>>>>>>>>> table to keep track of when each entry needs to be deleted, >>>>>>>>>>>> like >>>>>>>>>>>> what is done in the table of obsolete flags. >>>>>>>>>>>>>> Tested with jtreg runtime tests. A new test checks for an >>>>>>>>>>>>>> appropriate >>>>>>>>>>>>>> error message for every develop flag that has so far been >>>>>>>>>>>>>> converted to >>>>>>>>>>>>>> logging. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >> From stefan.karlsson at oracle.com Wed Mar 23 14:27:32 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 23 Mar 2016 15:27:32 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4) In-Reply-To: <56F29F19.9030409@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> <56F29F19.9030409@oracle.com> Message-ID: <56F2A7D4.8030400@oracle.com> Hi Robbin, On 2016-03-23 14:50, Robbin Ehn wrote: > Hi all, > > After more input, this is the current version. > Please have a look. > > Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/ > Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/ Looks good to me. It's non-obvious why you change the "stderr" config below, so that might warrant a comment: LogConfiguration::disable_logging(); assert(Test_logconfiguration_subscribe_triggered == 3, "subscription not triggered (3)"); - // Restore saved configuration - LogConfiguration::parse_log_arguments("stdout", saved_config, NULL, NULL, log.error_stream()); - os::free(saved_config); + LogConfiguration::parse_log_arguments("stderr", "all=warning", NULL, NULL, log.error_stream()); + assert(Test_logconfiguration_subscribe_triggered == 4, "subscription not triggered (3)"); } Thanks, StefanK > > Thanks! > > /Robbin > > On 03/21/2016 05:34 PM, Robbin Ehn wrote: >> Hi all, please review this a somewhat bigger change-set. >> >> Updated with the feedback. >> >> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ >> >> Tested with jprt hotspot and I added 2 internal vm tests. >> >> (also 2 bugs fixed, missing va_end and a potential race when calling >> prefix function twice (very unlikely)) >> >> Thanks! >> >> /Robbin >> >> On 03/16/2016 01:33 PM, Robbin Ehn wrote: >>> Hi, please review this small change. >>> >>> This also change allocation methods. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >>> >>> Thanks! >>> >>> /Robbin From robbin.ehn at oracle.com Wed Mar 23 14:35:59 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 23 Mar 2016 15:35:59 +0100 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4) In-Reply-To: <56F2A7D4.8030400@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> <56F29F19.9030409@oracle.com> <56F2A7D4.8030400@oracle.com> Message-ID: <56F2A9CF.8010908@oracle.com> Hi Stefan On 03/23/2016 03:27 PM, Stefan Karlsson wrote: > Hi Robbin, > > On 2016-03-23 14:50, Robbin Ehn wrote: >> Hi all, >> >> After more input, this is the current version. >> Please have a look. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/ >> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/ > > Looks good to me. > > It's non-obvious why you change the "stderr" config below, so that might > warrant a comment: > > LogConfiguration::disable_logging(); > assert(Test_logconfiguration_subscribe_triggered == 3, "subscription > not triggered (3)"); > > - // Restore saved configuration > - LogConfiguration::parse_log_arguments("stdout", saved_config, NULL, > NULL, log.error_stream()); > - os::free(saved_config); I'll add comment! (The reason is that LogConfiguration::disable_logging will disable both stdout and stderr, the TestLogSavedConfig will restore stdout for us but not stderr.) Thanks Stefan! /Robbin > + LogConfiguration::parse_log_arguments("stderr", "all=warning", NULL, > NULL, log.error_stream()); > + assert(Test_logconfiguration_subscribe_triggered == 4, "subscription > not triggered (3)"); > } > > Thanks, > StefanK > > > >> >> Thanks! >> >> /Robbin >> >> On 03/21/2016 05:34 PM, Robbin Ehn wrote: >>> Hi all, please review this a somewhat bigger change-set. >>> >>> Updated with the feedback. >>> >>> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/ >>> >>> Tested with jprt hotspot and I added 2 internal vm tests. >>> >>> (also 2 bugs fixed, missing va_end and a potential race when calling >>> prefix function twice (very unlikely)) >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 03/16/2016 01:33 PM, Robbin Ehn wrote: >>>> Hi, please review this small change. >>>> >>>> This also change allocation methods. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/ >>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/ >>>> >>>> Thanks! >>>> >>>> /Robbin > From daniel.daugherty at oracle.com Wed Mar 23 16:14:09 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Mar 2016 10:14:09 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: References: <56F1ADEC.2050508@oracle.com> Message-ID: <56F2C0D1.8030607@oracle.com> On 3/23/16 4:55 AM, Paul Sandoz wrote: > Hi Dan, > > Well done on finding the root cause and fix for this ?bug from hell?! Thanks! It has been an "interesting" bug hunt! > Do you have any wisdom to share on the techniques and approach taken to debug and find the cause? these kinds of bugs are not easy so it?s often useful to share such advice. In addition to the fix itself, this bug hunt has also resulted in creation of a wiki called "An Introduction to Java Monitors". The sections are not yet complete, but so far I've written (and internally presented): Section 1 - Stack Locks Section 2 - Inflated Locks Section 3 - Slow Java Monitor Enter There will likely be two more sections, but I haven't written those yet. Once we've reviewed and modified the content internally, we'll have to see how to get this kind of info out into OpenJDK. Another result of this bug hunt will be some debug/trace kits. I created separate debug/tracing for the different parts of Java Monitors (enter, wait, notify, exit) and I should be able to extract this stuff into "kit" form for other folks to use. No one else should have to figure out how to add tracing to the MacroAssembler code! > Amy and I spent a bit of time just getting a test case that could reproduce in a ?reasonable? period of time with enough confidence it was something in HotSpot (bisecting builds), and then we threw it over the fence to you :-) You guys gave me a reproducible test case and for that I'm very grateful! So many of the weird bugs that I hunt don't have an initial reproducible test case so I have often spent a lot of time just trying to reproduce the rare, strange, and unusual... Dan > > Paul. > >> On 22 Mar 2016, at 21:41, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I have fixes for the following two bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> Both fixes are very, very small and will be bundled together in the >> same changeset for obvious reasons. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >> >> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >> the race is much, much longer. I've attached the detailed evaluation >> to this RFR; it is a copy of the same note that I added to >> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >> copy has all the indentation white space intact. I don't know why >> JBS likes to reformat the notes, but it does... :-( >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan >> From coleen.phillimore at oracle.com Wed Mar 23 16:38:06 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Mar 2016 12:38:06 -0400 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F1F9E0.3070307@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> <56F18336.4070603@oracle.com> <56F1F9E0.3070307@oracle.com> Message-ID: <56F2C66E.8030004@oracle.com> Hi, I realized that I didn't describe this well in either the bug or the RFR, so I put a description of what the problem is and why this fixes it in the bug. On 3/22/16 10:05 PM, Ioi Lam wrote: > I've done a little investigation on Latin1 encoding of > java.lang.String and how that relates to this bug. Here's what I found: > > * Latin1 is is a 8-bit encoding of characters. > * The first 256 Unicode characters are exactly the same as the Latin1 > encoding. > * So if all the jchars in a java.lang.String are <= 0xff, it can be > stored in (logically) an unsigned byte array with the upper 16 bits > truncated. > o I am not sure if it's REQUIRED for such strings to be stored in > a byte array. It might be possible to create an equivalent > String with jchar[] storage. You can certainly do that with > Unsafe + reflection. > > This function, which you removed, should return the exact same > hashcode regardless whether the String was stored as a byte[] or jchar[] > > unsigned int java_lang_String::hash_string(oop java_string) { > int length = java_lang_String::length(java_string); > // Zero length string doesn't necessarily hash to zero. > if (length == 0) { > return StringTable::hash_string((jchar*) NULL, 0); > } > > typeArrayOop value = java_lang_String::value(java_string); > bool is_latin1 = java_lang_String::is_latin1(java_string); > if (is_latin1) { > return StringTable::hash_string(value->byte_at_addr(0), length); > } else { > return StringTable::hash_string(value->char_at_addr(0), length); > } > } > > That's because these two functions should produce the exact same > result (if all the unsigned arithmetics are correct ...) > > static unsigned int hash_code(const jchar* s, int len) { > unsigned int h = 0; > while (len-- > 0) { > h = 31*h + (unsigned int) *s; > s++; > } > return h; > } > > static unsigned int hash_code(const jbyte* s, int len) { > unsigned int h = 0; > while (len-- > 0) { > h = 31*h + (((unsigned int) *s) & 0xFF); > s++; > } > return h; > } > > For shared interned strings, we actually use the version > during dump time (writing into shared strings table), and the > version at run time (look up from shared string table). I wrote a test > and validated that the the two hashcodes are identical. For the alternate hashcode, the two hashcodes were different, which caused this bug. I don't think you should rely on the jbyte and jchar versions returning the same thing. I think you should always use the jchar version of the hash code for shared intern strings. > > So, I believe your fix for 8144940 works not because you force the > body to be converted to jchar. Rather, it's because > java_lang_String::hash_string does not consider > StringTable::use_alternate_hashcode(). > > Also, I am glad that you removed the version of this template: > > template > unsigned int StringTable::hash_string(const T* s, int len) { > return use_alternate_hashcode() ? AltHashing::murmur3_32(seed(), > s, len) : > java_lang_String::hash_code(s, > len); > } > > // Explicit instantiation for all supported types. > template unsigned int StringTable::hash_string(const jchar* > s, int len); > template unsigned int StringTable::hash_string(const jbyte* > s, int len); > > Otherwise, someone is likely to call it with a UTF8 string and get > unexpected results. I am not even sure if it would give identical > results as the version if the input was encoded in Latin1. I think it doesn't get the same results. Hopefully, I've put enough information in the bug and yeah, removing java_lang_String::hash_string() removed some confusion on my part at least, since there's also a StringTable::hash_string, which probably should be something like hash_string_for_StringTable but not for String.hashCode(). Thanks! Coleen > > Thanks > - Ioi > > On 3/22/16 10:39 AM, Coleen Phillimore wrote: >> >> Thank you, Jiangli. >> Coleen >> >> On 3/22/16 1:35 PM, Jiangli Zhou wrote: >>> Hi Coleen, >>> >>> Looks good to me. I had same question as Tobias yesterday. Your >>> answer cleared it. >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 22, 2016, at 10:07 AM, Coleen Phillimore >>>> wrote: >>>> >>>> >>>> Here's another webrev with the changes pointed out by Tobias and >>>> verified with -XX:+VerifyStringTableAtExit. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev >>>> >>>> Thanks! >>>> Coleen >>>> >>>> On 3/22/16 12:21 PM, Tobias Hartmann wrote: >>>>> Hi Coleen, >>>>> >>>>> On 22.03.2016 13:40, Coleen Phillimore wrote: >>>>>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>>>>> Summary: Fix code broken with compact Strings. >>>>>>>> >>>>>>>> One of the failure modes of an intermittent bug (but this >>>>>>>> failure is not intermittent). >>>>>>>> >>>>>>>> Tested with the failing test cases that exercise this code. >>>>>>>> Also, testing in order to find linked bugs. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>>>>> I wonder why the result is different if you first convert the >>>>>>> latin1 String to Unicode and then use the jchar hash_string() >>>>>>> version compared to just using the jbyte hash_string() version? >>>>>>> Is it because the jbyte version of AltHashing::murmur3_32() is >>>>>>> used? >>>>>> Yes, I believe it is. >>>>> Okay, thanks for checking. >>>>> >>>>>>> Now we don't need the StringTable::hash_string version >>>>>>> anymore, right? >>>>>> This one is used by Symbol* which are jbyte. >>>>> I only see jchar uses of StringTable::hash_string() (after your >>>>> fix). Are you confusing it with java_lang_String::hash_code() >>>>> which also has a jbyte and jchar version? This one is indeed used >>>>> by the SymbolTable. >>>>> >>>>>>> Just noticed that there is an unused "latin1_hash_code" in >>>>>>> javaClasses.hpp which can be removed as well. >>>>>> Thank you, I'll remove it. >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>>>> Thanks for fixing this! >>>>>> Thanks for reviewing it! >>>>>> Coleen >>>>>>> Best regards, >>>>>>> Tobias >>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >> > From ioi.lam at oracle.com Wed Mar 23 17:32:59 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Mar 2016 10:32:59 -0700 Subject: RFR (S) 8144940: Broken hash in string table entry in closed/runtime/7158800/BadUtf8.java In-Reply-To: <56F2C66E.8030004@oracle.com> References: <56F06384.4060508@oracle.com> <56F0FC7A.1000708@oracle.com> <56F13D34.9020202@oracle.com> <56F170FF.5040101@oracle.com> <56F17BE8.1010407@oracle.com> <56F18336.4070603@oracle.com> <56F1F9E0.3070307@oracle.com> <56F2C66E.8030004@oracle.com> Message-ID: <56F2D34B.4030007@oracle.com> On 3/23/16 9:38 AM, Coleen Phillimore wrote: > > Hi, I realized that I didn't describe this well in either the bug or > the RFR, so I put a description of what the problem is and why this > fixes it in the bug. > > On 3/22/16 10:05 PM, Ioi Lam wrote: >> I've done a little investigation on Latin1 encoding of >> java.lang.String and how that relates to this bug. Here's what I found: >> >> * Latin1 is is a 8-bit encoding of characters. >> * The first 256 Unicode characters are exactly the same as the Latin1 >> encoding. >> * So if all the jchars in a java.lang.String are <= 0xff, it can be >> stored in (logically) an unsigned byte array with the upper 16 bits >> truncated. >> o I am not sure if it's REQUIRED for such strings to be stored in >> a byte array. It might be possible to create an equivalent >> String with jchar[] storage. You can certainly do that with >> Unsafe + reflection. >> >> This function, which you removed, should return the exact same >> hashcode regardless whether the String was stored as a byte[] or jchar[] >> >> unsigned int java_lang_String::hash_string(oop java_string) { >> int length = java_lang_String::length(java_string); >> // Zero length string doesn't necessarily hash to zero. >> if (length == 0) { >> return StringTable::hash_string((jchar*) NULL, 0); >> } >> >> typeArrayOop value = java_lang_String::value(java_string); >> bool is_latin1 = java_lang_String::is_latin1(java_string); >> if (is_latin1) { >> return StringTable::hash_string(value->byte_at_addr(0), length); >> } else { >> return StringTable::hash_string(value->char_at_addr(0), length); >> } >> } >> >> That's because these two functions should produce the exact same >> result (if all the unsigned arithmetics are correct ...) >> >> static unsigned int hash_code(const jchar* s, int len) { >> unsigned int h = 0; >> while (len-- > 0) { >> h = 31*h + (unsigned int) *s; >> s++; >> } >> return h; >> } >> >> static unsigned int hash_code(const jbyte* s, int len) { >> unsigned int h = 0; >> while (len-- > 0) { >> h = 31*h + (((unsigned int) *s) & 0xFF); >> s++; >> } >> return h; >> } >> >> For shared interned strings, we actually use the version >> during dump time (writing into shared strings table), and the >> version at run time (look up from shared string table). I wrote a >> test and validated that the the two hashcodes are identical. > > For the alternate hashcode, the two hashcodes were different, which > caused this bug. I don't think you should rely on the jbyte and jchar > versions returning the same thing. I think you should always use the > jchar version of the hash code for shared intern strings. Sorry, what I said above was wrong. I was confused by all the different hashing functions that had similar names (hash_code vs hash_string) but do different things. [1] java_lang_String::hash_code(const jchar* s, int len) vs java_lang_String::hash_code(const jbyte* s, int len) They generate the same hash code, when you give an equivalent input in UTF16 to the first function in Latin1 to the second function [2] StringTable::hash_string(const jchar* s, int len) vs StringTable::hash_string(const jbyte* s, int len) These two function generate different hash codes (when StringTable::use_alternate_hashcode() == true) In summary, JDK-8144940 was caused by [2], and is unrelated to [1]. Thanks - Ioi >> >> So, I believe your fix for 8144940 works not because you force the >> body to be converted to jchar. Rather, it's because >> java_lang_String::hash_string does not consider >> StringTable::use_alternate_hashcode(). >> >> Also, I am glad that you removed the version of this template: >> >> template >> unsigned int StringTable::hash_string(const T* s, int len) { >> return use_alternate_hashcode() ? AltHashing::murmur3_32(seed(), >> s, len) : >> java_lang_String::hash_code(s, >> len); >> } >> >> // Explicit instantiation for all supported types. >> template unsigned int StringTable::hash_string(const jchar* >> s, int len); >> template unsigned int StringTable::hash_string(const jbyte* >> s, int len); >> >> Otherwise, someone is likely to call it with a UTF8 string and get >> unexpected results. I am not even sure if it would give identical >> results as the version if the input was encoded in Latin1. > > I think it doesn't get the same results. > > Hopefully, I've put enough information in the bug and yeah, removing > java_lang_String::hash_string() removed some confusion on my part at > least, since there's also a StringTable::hash_string, which probably > should be something like hash_string_for_StringTable but not for > String.hashCode(). > > Thanks! > Coleen > >> >> Thanks >> - Ioi >> >> On 3/22/16 10:39 AM, Coleen Phillimore wrote: >>> >>> Thank you, Jiangli. >>> Coleen >>> >>> On 3/22/16 1:35 PM, Jiangli Zhou wrote: >>>> Hi Coleen, >>>> >>>> Looks good to me. I had same question as Tobias yesterday. Your >>>> answer cleared it. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 22, 2016, at 10:07 AM, Coleen Phillimore >>>>> wrote: >>>>> >>>>> >>>>> Here's another webrev with the changes pointed out by Tobias and >>>>> verified with -XX:+VerifyStringTableAtExit. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144940.02/webrev >>>>> >>>>> Thanks! >>>>> Coleen >>>>> >>>>> On 3/22/16 12:21 PM, Tobias Hartmann wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 22.03.2016 13:40, Coleen Phillimore wrote: >>>>>>> On 3/22/16 4:04 AM, Tobias Hartmann wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> On 21.03.2016 22:11, Coleen Phillimore wrote: >>>>>>>>> Summary: Fix code broken with compact Strings. >>>>>>>>> >>>>>>>>> One of the failure modes of an intermittent bug (but this >>>>>>>>> failure is not intermittent). >>>>>>>>> >>>>>>>>> Tested with the failing test cases that exercise this code. >>>>>>>>> Also, testing in order to find linked bugs. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8144940.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144940 >>>>>>>> I wonder why the result is different if you first convert the >>>>>>>> latin1 String to Unicode and then use the jchar hash_string() >>>>>>>> version compared to just using the jbyte hash_string() version? >>>>>>>> Is it because the jbyte version of AltHashing::murmur3_32() is >>>>>>>> used? >>>>>>> Yes, I believe it is. >>>>>> Okay, thanks for checking. >>>>>> >>>>>>>> Now we don't need the StringTable::hash_string version >>>>>>>> anymore, right? >>>>>>> This one is used by Symbol* which are jbyte. >>>>>> I only see jchar uses of StringTable::hash_string() (after your >>>>>> fix). Are you confusing it with java_lang_String::hash_code() >>>>>> which also has a jbyte and jchar version? This one is indeed used >>>>>> by the SymbolTable. >>>>>> >>>>>>>> Just noticed that there is an unused "latin1_hash_code" in >>>>>>>> javaClasses.hpp which can be removed as well. >>>>>>> Thank you, I'll remove it. >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Tobias >>>>>> >>>>>>>> Thanks for fixing this! >>>>>>> Thanks for reviewing it! >>>>>>> Coleen >>>>>>>> Best regards, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>> >> > From stefan.karlsson at oracle.com Wed Mar 23 20:31:15 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 23 Mar 2016 21:31:15 +0100 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F1C43B.9020001@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> Message-ID: <56F2FD13.70801@oracle.com> Hi, On 22/03/16 23:16, Coleen Phillimore wrote: > > > On 3/22/16 4:06 PM, Rachel Protacio wrote: >> Hi, >> >> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>> >>> Hi Rachel, >>> >>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>> >>> >>> I think the line >>> >>> *-if (PrintOopAddress)print_address_on(st);* >>> >>> >>> should be removed. For the case of a String that is in output for >>> logging, it doesn't seem like it adds anything and then you wouldn't >>> have to change the tests. >>> >> The part printing from the exceptions logging isn't from oop.cpp, but >> klass.cpp#Klass::print_on(). Should I delete it from there instead? > > Ah, thank you for correcting my mistake. I think the address > shouldn't be printed in the logging statement because these are used > by people for debugging Java code, and not jvm code. So, yes, I think > it should be deleted there also. I don't think printing these > addresses are useful for debugging anymore, since we removed PermGen. Is there a reason you want to remove this except for not having to change the tests? Getting object addresses printed is an important debugging tool for us in the GC team. Thanks, StefanK > > Thanks, > Coleen > >> >> Rachel >> >>> Thanks, >>> Coleen >>> >>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this fix removing PrintOopAddress as a command line >>>> flag. The printing functionality has been made default, except for >>>> one block which has been removed (see bug description for >>>> justification). A compatibility request has been accepted with >>>> respect to this change. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>> >>>> Passes JPRT and RBT hotspot and non-colo testing. >>>> >>>> Thank you, >>>> Rachel >>> >> > From coleen.phillimore at oracle.com Wed Mar 23 20:54:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Mar 2016 16:54:45 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F2FD13.70801@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> Message-ID: <56F30295.3070600@oracle.com> I thought it was ugly. busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx [0.577s][info][exceptions] Exception (0x0000000101c4f120) thrown in interpreter method <{method} {0x00007f670f6b0d70} 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> at bci 44 for thread 0x00007f694c017000 vs. busaa027% java -Xlog:exceptions xxx [0.591s][info][exceptions] Exception (0x0000000101c4f120) thrown in interpreter method <{method} {0x00007f540b0b9d70} 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> And redundant! At least here. Coleen On 3/23/16 4:31 PM, Stefan Karlsson wrote: > Hi, > > On 22/03/16 23:16, Coleen Phillimore wrote: >> >> >> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>> Hi, >>> >>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>> >>>> Hi Rachel, >>>> >>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>> >>>> >>>> I think the line >>>> >>>> *-if (PrintOopAddress)print_address_on(st);* >>>> >>>> >>>> should be removed. For the case of a String that is in output for >>>> logging, it doesn't seem like it adds anything and then you >>>> wouldn't have to change the tests. >>>> >>> The part printing from the exceptions logging isn't from oop.cpp, >>> but klass.cpp#Klass::print_on(). Should I delete it from there instead? >> >> Ah, thank you for correcting my mistake. I think the address >> shouldn't be printed in the logging statement because these are used >> by people for debugging Java code, and not jvm code. So, yes, I >> think it should be deleted there also. I don't think printing these >> addresses are useful for debugging anymore, since we removed PermGen. > > Is there a reason you want to remove this except for not having to > change the tests? Getting object addresses printed is an important > debugging tool for us in the GC team. > > Thanks, > StefanK > >> >> Thanks, >> Coleen >> >>> >>> Rachel >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>> Hello, >>>>> >>>>> Please review this fix removing PrintOopAddress as a command line >>>>> flag. The printing functionality has been made default, except for >>>>> one block which has been removed (see bug description for >>>>> justification). A compatibility request has been accepted with >>>>> respect to this change. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>> >>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>> >>>>> Thank you, >>>>> Rachel >>>> >>> >> > From stefan.karlsson at oracle.com Wed Mar 23 21:07:56 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 23 Mar 2016 22:07:56 +0100 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F30295.3070600@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> <56F30295.3070600@oracle.com> Message-ID: <56F305AC.3090903@oracle.com> On 23/03/16 21:54, Coleen Phillimore wrote: > > I thought it was ugly. > > busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx > [0.577s][info][exceptions] Exception 'java/lang/ClassNotFoundException'{0x0000000101c4f120}: xxx> > (0x0000000101c4f120) > thrown in interpreter method <{method} {0x00007f670f6b0d70} > 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > at bci 44 for thread 0x00007f694c017000 > > > vs. > > busaa027% java -Xlog:exceptions xxx > [0.591s][info][exceptions] Exception 'java/lang/ClassNotFoundException': xxx> (0x0000000101c4f120) > thrown in interpreter method <{method} {0x00007f540b0b9d70} > 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > > > And redundant! At least here. Yes, that looks ugly. I think we could change the code to allow the call sites to turn off address printing where it doesn't make sense. StefanK > > Coleen > > On 3/23/16 4:31 PM, Stefan Karlsson wrote: >> Hi, >> >> On 22/03/16 23:16, Coleen Phillimore wrote: >>> >>> >>> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Rachel, >>>>> >>>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>>> >>>>> >>>>> I think the line >>>>> >>>>> *-if (PrintOopAddress)print_address_on(st);* >>>>> >>>>> >>>>> should be removed. For the case of a String that is in output >>>>> for logging, it doesn't seem like it adds anything and then you >>>>> wouldn't have to change the tests. >>>>> >>>> The part printing from the exceptions logging isn't from oop.cpp, >>>> but klass.cpp#Klass::print_on(). Should I delete it from there >>>> instead? >>> >>> Ah, thank you for correcting my mistake. I think the address >>> shouldn't be printed in the logging statement because these are used >>> by people for debugging Java code, and not jvm code. So, yes, I >>> think it should be deleted there also. I don't think printing these >>> addresses are useful for debugging anymore, since we removed PermGen. >> >> Is there a reason you want to remove this except for not having to >> change the tests? Getting object addresses printed is an important >> debugging tool for us in the GC team. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Rachel >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this fix removing PrintOopAddress as a command line >>>>>> flag. The printing functionality has been made default, except >>>>>> for one block which has been removed (see bug description for >>>>>> justification). A compatibility request has been accepted with >>>>>> respect to this change. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>>> >>>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>>> >>>>>> Thank you, >>>>>> Rachel >>>>> >>>> >>> >> > From rachel.protacio at oracle.com Wed Mar 23 21:20:47 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 23 Mar 2016 17:20:47 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F30295.3070600@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> <56F30295.3070600@oracle.com> Message-ID: <56F308AF.6050706@oracle.com> Ok, how about I just delete the repeat address in the exceptions logging, i.e. the part in the parentheses? Here's a webrev with that: http://cr.openjdk.java.net/~rprotacio/8146947.01/ Rachel On 3/23/2016 4:54 PM, Coleen Phillimore wrote: > > I thought it was ugly. > > busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx > [0.577s][info][exceptions] Exception 'java/lang/ClassNotFoundException'{0x0000000101c4f120}: xxx> > (0x0000000101c4f120) > thrown in interpreter method <{method} {0x00007f670f6b0d70} > 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > at bci 44 for thread 0x00007f694c017000 > > > vs. > > busaa027% java -Xlog:exceptions xxx > [0.591s][info][exceptions] Exception 'java/lang/ClassNotFoundException': xxx> (0x0000000101c4f120) > thrown in interpreter method <{method} {0x00007f540b0b9d70} > 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > > > And redundant! At least here. > > Coleen > > On 3/23/16 4:31 PM, Stefan Karlsson wrote: >> Hi, >> >> On 22/03/16 23:16, Coleen Phillimore wrote: >>> >>> >>> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Rachel, >>>>> >>>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>>> >>>>> >>>>> I think the line >>>>> >>>>> *-if (PrintOopAddress)print_address_on(st);* >>>>> >>>>> >>>>> should be removed. For the case of a String that is in output >>>>> for logging, it doesn't seem like it adds anything and then you >>>>> wouldn't have to change the tests. >>>>> >>>> The part printing from the exceptions logging isn't from oop.cpp, >>>> but klass.cpp#Klass::print_on(). Should I delete it from there >>>> instead? >>> >>> Ah, thank you for correcting my mistake. I think the address >>> shouldn't be printed in the logging statement because these are used >>> by people for debugging Java code, and not jvm code. So, yes, I >>> think it should be deleted there also. I don't think printing these >>> addresses are useful for debugging anymore, since we removed PermGen. >> >> Is there a reason you want to remove this except for not having to >> change the tests? Getting object addresses printed is an important >> debugging tool for us in the GC team. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Rachel >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this fix removing PrintOopAddress as a command line >>>>>> flag. The printing functionality has been made default, except >>>>>> for one block which has been removed (see bug description for >>>>>> justification). A compatibility request has been accepted with >>>>>> respect to this change. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>>> >>>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>>> >>>>>> Thank you, >>>>>> Rachel >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Mar 23 21:33:55 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Mar 2016 17:33:55 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F308AF.6050706@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> <56F30295.3070600@oracle.com> <56F308AF.6050706@oracle.com> Message-ID: <56F30BC3.4070401@oracle.com> Yeah, I like that. Stefan? Coleen On 3/23/16 5:20 PM, Rachel Protacio wrote: > Ok, how about I just delete the repeat address in the exceptions > logging, i.e. the part in the parentheses? Here's a webrev with that: > http://cr.openjdk.java.net/~rprotacio/8146947.01/ > > Rachel > > On 3/23/2016 4:54 PM, Coleen Phillimore wrote: >> >> I thought it was ugly. >> >> busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx >> [0.577s][info][exceptions] Exception > 'java/lang/ClassNotFoundException'{0x0000000101c4f120}: xxx> >> (0x0000000101c4f120) >> thrown in interpreter method <{method} {0x00007f670f6b0d70} >> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >> at bci 44 for thread 0x00007f694c017000 >> >> >> vs. >> >> busaa027% java -Xlog:exceptions xxx >> [0.591s][info][exceptions] Exception > 'java/lang/ClassNotFoundException': xxx> (0x0000000101c4f120) >> thrown in interpreter method <{method} {0x00007f540b0b9d70} >> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >> >> >> And redundant! At least here. >> >> Coleen >> >> On 3/23/16 4:31 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> On 22/03/16 23:16, Coleen Phillimore wrote: >>>> >>>> >>>> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>>>> Hi, >>>>> >>>>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Rachel, >>>>>> >>>>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>>>> >>>>>> >>>>>> I think the line >>>>>> >>>>>> *-if (PrintOopAddress)print_address_on(st);* >>>>>> >>>>>> >>>>>> should be removed. For the case of a String that is in output >>>>>> for logging, it doesn't seem like it adds anything and then you >>>>>> wouldn't have to change the tests. >>>>>> >>>>> The part printing from the exceptions logging isn't from oop.cpp, >>>>> but klass.cpp#Klass::print_on(). Should I delete it from there >>>>> instead? >>>> >>>> Ah, thank you for correcting my mistake. I think the address >>>> shouldn't be printed in the logging statement because these are >>>> used by people for debugging Java code, and not jvm code. So, yes, >>>> I think it should be deleted there also. I don't think printing >>>> these addresses are useful for debugging anymore, since we removed >>>> PermGen. >>> >>> Is there a reason you want to remove this except for not having to >>> change the tests? Getting object addresses printed is an important >>> debugging tool for us in the GC team. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Rachel >>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this fix removing PrintOopAddress as a command >>>>>>> line flag. The printing functionality has been made default, >>>>>>> except for one block which has been removed (see bug description >>>>>>> for justification). A compatibility request has been accepted >>>>>>> with respect to this change. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>>>> >>>>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>>>> >>>>>>> Thank you, >>>>>>> Rachel >>>>>> >>>>> >>>> >>> >> > From stefan.karlsson at oracle.com Wed Mar 23 22:30:34 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 23 Mar 2016 23:30:34 +0100 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F30BC3.4070401@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> <56F30295.3070600@oracle.com> <56F308AF.6050706@oracle.com> <56F30BC3.4070401@oracle.com> Message-ID: <56F3190A.60204@oracle.com> On 23/03/16 22:33, Coleen Phillimore wrote: > > Yeah, I like that. Stefan? I'm fine with that. Reviewed. I do appreciate that we want to make the exception log lines look pretty, and maybe we could change the code to print something like: [0.591s][info][exceptions] Exception java/lang/ClassNotFoundException thrown in java/net/URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class on the info level, and print the rest at the debug or trace level. But, if we do want that, we should probably handle that as a separate RFE. Thanks, StefanK > Coleen > > > On 3/23/16 5:20 PM, Rachel Protacio wrote: >> Ok, how about I just delete the repeat address in the exceptions >> logging, i.e. the part in the parentheses? Here's a webrev with that: >> http://cr.openjdk.java.net/~rprotacio/8146947.01/ >> >> Rachel >> >> On 3/23/2016 4:54 PM, Coleen Phillimore wrote: >>> >>> I thought it was ugly. >>> >>> busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx >>> [0.577s][info][exceptions] Exception >> 'java/lang/ClassNotFoundException'{0x0000000101c4f120}: xxx> >>> (0x0000000101c4f120) >>> thrown in interpreter method <{method} {0x00007f670f6b0d70} >>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>> at bci 44 for thread 0x00007f694c017000 >>> >>> >>> vs. >>> >>> busaa027% java -Xlog:exceptions xxx >>> [0.591s][info][exceptions] Exception >> 'java/lang/ClassNotFoundException': xxx> (0x0000000101c4f120) >>> thrown in interpreter method <{method} {0x00007f540b0b9d70} >>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>> >>> >>> And redundant! At least here. >>> >>> Coleen >>> >>> On 3/23/16 4:31 PM, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> On 22/03/16 23:16, Coleen Phillimore wrote: >>>>> >>>>> >>>>> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>>>>> Hi, >>>>>> >>>>>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Rachel, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> I think the line >>>>>>> >>>>>>> *-if (PrintOopAddress)print_address_on(st);* >>>>>>> >>>>>>> >>>>>>> should be removed. For the case of a String that is in output >>>>>>> for logging, it doesn't seem like it adds anything and then you >>>>>>> wouldn't have to change the tests. >>>>>>> >>>>>> The part printing from the exceptions logging isn't from oop.cpp, >>>>>> but klass.cpp#Klass::print_on(). Should I delete it from there >>>>>> instead? >>>>> >>>>> Ah, thank you for correcting my mistake. I think the address >>>>> shouldn't be printed in the logging statement because these are >>>>> used by people for debugging Java code, and not jvm code. So, yes, >>>>> I think it should be deleted there also. I don't think printing >>>>> these addresses are useful for debugging anymore, since we removed >>>>> PermGen. >>>> >>>> Is there a reason you want to remove this except for not having to >>>> change the tests? Getting object addresses printed is an important >>>> debugging tool for us in the GC team. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Rachel >>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this fix removing PrintOopAddress as a command >>>>>>>> line flag. The printing functionality has been made default, >>>>>>>> except for one block which has been removed (see bug >>>>>>>> description for justification). A compatibility request has >>>>>>>> been accepted with respect to this change. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>>>>> >>>>>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Rachel >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jiangli.zhou at Oracle.COM Wed Mar 23 23:24:41 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Wed, 23 Mar 2016 16:24:41 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56EC6A3F.7070500@oracle.com> References: <56EC6A3F.7070500@oracle.com> Message-ID: Hi Calvin, I have two comments below. - I?d suggest putting the new block of code (added in open_stream()) in a separate function. The new function should be defined for CDS_ONLY. - In the bug report, it is suggested that the search for versioned class stops at 8. The changes in the webrev search all versions down to 6. Could you please verify what the spec says. The VM behavior should be the same a the JDK library code. Thanks, Jiangli > On Mar 18, 2016, at 1:51 PM, Calvin Cheung wrote: > > > This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. > > JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 > (unfortunately the bug was marked as "confidential") > > webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ > > Some adjustments need to be made due to: > - attribute name in the jar manifest has been changed to "Multi-release"; > - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". > > The diff between this patch and the reviewed patch is as follows: > > 11c11 > < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); > --- > > + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); > 14c14 > < + strcmp(multi_ver, "true") == 0 || > --- > > + strcmp(multi_ver, "enable") == 0 || > 64c64 > < @@ -296,6 +345,17 @@ > --- > > @@ -272,6 +321,17 @@ > 72c72 > < + if (strstr(buffer, "Multi-Release: true") != NULL) { > --- > > + if (strstr(buffer, "Multiversion: true") != NULL) { > > thanks, > Calvin > > [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From rachel.protacio at oracle.com Thu Mar 24 13:34:19 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 24 Mar 2016 09:34:19 -0400 Subject: RFR: 8146947: Remove PrintOopAddress rather than converting to UL In-Reply-To: <56F3190A.60204@oracle.com> References: <56F151F6.70804@oracle.com> <56F16E57.2060507@oracle.com> <56F1A5DD.3040506@oracle.com> <56F1C43B.9020001@oracle.com> <56F2FD13.70801@oracle.com> <56F30295.3070600@oracle.com> <56F308AF.6050706@oracle.com> <56F30BC3.4070401@oracle.com> <56F3190A.60204@oracle.com> Message-ID: <56F3ECDB.7060305@oracle.com> Thanks for the reviews, Coleen and Stefan! Rachel On 3/23/2016 6:30 PM, Stefan Karlsson wrote: > On 23/03/16 22:33, Coleen Phillimore wrote: >> >> Yeah, I like that. Stefan? > > I'm fine with that. Reviewed. > > I do appreciate that we want to make the exception log lines look > pretty, and maybe we could change the code to print something like: > [0.591s][info][exceptions] Exception java/lang/ClassNotFoundException > thrown in > java/net/URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class > > on the info level, and print the rest at the debug or trace level. > But, if we do want that, we should probably handle that as a separate > RFE. > > Thanks, > StefanK > >> Coleen >> >> >> On 3/23/16 5:20 PM, Rachel Protacio wrote: >>> Ok, how about I just delete the repeat address in the exceptions >>> logging, i.e. the part in the parentheses? Here's a webrev with >>> that: http://cr.openjdk.java.net/~rprotacio/8146947.01/ >>> >>> Rachel >>> >>> On 3/23/2016 4:54 PM, Coleen Phillimore wrote: >>>> >>>> I thought it was ugly. >>>> >>>> busaa027% java -Xlog:exceptions -XX:+PrintOopAddress xxx >>>> [0.577s][info][exceptions] Exception >>> 'java/lang/ClassNotFoundException'{0x0000000101c4f120}: xxx> >>>> (0x0000000101c4f120) >>>> thrown in interpreter method <{method} {0x00007f670f6b0d70} >>>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>>> at bci 44 for thread 0x00007f694c017000 >>>> >>>> >>>> vs. >>>> >>>> busaa027% java -Xlog:exceptions xxx >>>> [0.591s][info][exceptions] Exception >>> 'java/lang/ClassNotFoundException': xxx> (0x0000000101c4f120) >>>> thrown in interpreter method <{method} {0x00007f540b0b9d70} >>>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>>> >>>> >>>> And redundant! At least here. >>>> >>>> Coleen >>>> >>>> On 3/23/16 4:31 PM, Stefan Karlsson wrote: >>>>> Hi, >>>>> >>>>> On 22/03/16 23:16, Coleen Phillimore wrote: >>>>>> >>>>>> >>>>>> On 3/22/16 4:06 PM, Rachel Protacio wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 3/22/2016 12:09 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi Rachel, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~rprotacio/8146947/src/share/vm/oops/oop.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> I think the line >>>>>>>> >>>>>>>> *-if (PrintOopAddress)print_address_on(st);* >>>>>>>> >>>>>>>> >>>>>>>> should be removed. For the case of a String that is in output >>>>>>>> for logging, it doesn't seem like it adds anything and then you >>>>>>>> wouldn't have to change the tests. >>>>>>>> >>>>>>> The part printing from the exceptions logging isn't from >>>>>>> oop.cpp, but klass.cpp#Klass::print_on(). Should I delete it >>>>>>> from there instead? >>>>>> >>>>>> Ah, thank you for correcting my mistake. I think the address >>>>>> shouldn't be printed in the logging statement because these are >>>>>> used by people for debugging Java code, and not jvm code. So, >>>>>> yes, I think it should be deleted there also. I don't think >>>>>> printing these addresses are useful for debugging anymore, since >>>>>> we removed PermGen. >>>>> >>>>> Is there a reason you want to remove this except for not having to >>>>> change the tests? Getting object addresses printed is an important >>>>> debugging tool for us in the GC team. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Rachel >>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/22/16 10:08 AM, Rachel Protacio wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review this fix removing PrintOopAddress as a command >>>>>>>>> line flag. The printing functionality has been made default, >>>>>>>>> except for one block which has been removed (see bug >>>>>>>>> description for justification). A compatibility request has >>>>>>>>> been accepted with respect to this change. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146947 >>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8146947/ >>>>>>>>> >>>>>>>>> Passes JPRT and RBT hotspot and non-colo testing. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Rachel >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From yasuenag at gmail.com Thu Mar 24 14:26:21 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 24 Mar 2016 23:26:21 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name Message-ID: <56F3F90D.9010408@gmail.com> Hi all, HotSpot for Linux will set thread name via pthread_setname_np(). However, main thread does not have it. All JavaThread have native name, and main thread is JavaThread. For consistency, main thread should have native thread name. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From robbin.ehn at oracle.com Thu Mar 24 16:51:11 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 24 Mar 2016 17:51:11 +0100 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56F3F90D.9010408@gmail.com> References: <56F3F90D.9010408@gmail.com> Message-ID: <56F41AFF.4090002@oracle.com> Hi Yasumasa, I'm not sure why you don't set it: diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 +0000 +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 +0100 @@ -3584,6 +3584,7 @@ JavaThread* main_thread = new JavaThread(); main_thread->set_thread_state(_thread_in_vm); main_thread->initialize_thread_current(); + main_thread->set_native_thread_name("main"); // must do this before set_active_handles main_thread->record_stack_base_and_size(); main_thread->set_active_handles(JNIHandleBlock::allocate_block()); here instead? Am I missing something? The launcher seem to name itself 'java' and naming this thread just 'main' is confusing to me. E.g. so main thread of the process (and thus the process) is 'java' but first JavaThread is 'main'. Thanks! /Robbin On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > Hi all, > > HotSpot for Linux will set thread name via pthread_setname_np(). > However, main thread does not have it. > > All JavaThread have native name, and main thread is JavaThread. > For consistency, main thread should have native thread name. > > I uploaded a webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > From david.holmes at oracle.com Thu Mar 24 19:23:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Mar 2016 05:23:17 +1000 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F1ADEC.2050508@oracle.com> References: <56F1ADEC.2050508@oracle.com> Message-ID: <56F43EA5.7040101@oracle.com> Hi Dan, Couldn't pass up the chance to review this - truly great debugging here! The changes of course look good. I was surprised to notice that before this fix the Lock argument (which should be lower-case lock if you don't mind adjusting that) was actually unused in quick_enter! So one has to wonder why it was passed in. Cheers, David On 23/03/2016 6:41 AM, Daniel D. Daugherty wrote: > Greetings, > > I have fixes for the following two bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > Both fixes are very, very small and will be bundled together in the > same changeset for obvious reasons. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ > > While the fix for JDK-8077392 is a simple 1-liner, the explanation of > the race is much, much longer. I've attached the detailed evaluation > to this RFR; it is a copy of the same note that I added to > https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached > copy has all the indentation white space intact. I don't know why > JBS likes to reformat the notes, but it does... :-( > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan From kevin.walls at oracle.com Thu Mar 24 20:05:49 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 24 Mar 2016 20:05:49 +0000 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56F06670.5030802@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> Message-ID: <56F4489D.10107@oracle.com> 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(const >>>>>>>> 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 kim.barrett at oracle.com Thu Mar 24 20:14:11 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Mar 2016 16:14:11 -0400 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4) In-Reply-To: <56F29F19.9030409@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> <56F29F19.9030409@oracle.com> Message-ID: <67967227-F576-42EB-B122-9EB76A61A512@oracle.com> > On Mar 23, 2016, at 9:50 AM, Robbin Ehn wrote: > > Hi all, > > After more input, this is the current version. > Please have a look. > > Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/ > Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/ This looks good. From daniel.daugherty at oracle.com Thu Mar 24 20:50:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Mar 2016 14:50:59 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F43EA5.7040101@oracle.com> References: <56F1ADEC.2050508@oracle.com> <56F43EA5.7040101@oracle.com> Message-ID: <56F45333.6030909@oracle.com> Thanks for the review! On 3/24/16 1:23 PM, David Holmes wrote: > Hi Dan, > > Couldn't pass up the chance to review this - truly great debugging here! Thanks! > The changes of course look good. Thanks! > I was surprised to notice that before this fix the Lock argument > (which should be lower-case lock if you don't mind adjusting that) was > actually unused in quick_enter! So one has to wonder why it was passed > in. I will rename from 'Lock' -> 'lock'. And it must have been passed as a parameter in anticipation of this very fix! :-) Dan > > Cheers, > David > > > > On 23/03/2016 6:41 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have fixes for the following two bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is >> fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> Both fixes are very, very small and will be bundled together in the >> same changeset for obvious reasons. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >> >> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >> the race is much, much longer. I've attached the detailed evaluation >> to this RFR; it is a copy of the same note that I added to >> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >> copy has all the indentation white space intact. I don't know why >> JBS likes to reformat the notes, but it does... :-( >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan From vladimir.kozlov at oracle.com Thu Mar 24 21:12:42 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Mar 2016 14:12:42 -0700 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F43EA5.7040101@oracle.com> References: <56F1ADEC.2050508@oracle.com> <56F43EA5.7040101@oracle.com> Message-ID: <56F4584A.2020805@oracle.com> On 3/24/16 12:23 PM, David Holmes wrote: > Hi Dan, > > Couldn't pass up the chance to review this - truly great debugging here! +1 Changes are good. Thanks, Vladimir > > The changes of course look good. > > I was surprised to notice that before this fix the Lock argument (which should be lower-case lock if you don't mind > adjusting that) was actually unused in quick_enter! So one has to wonder why it was passed in. > > Cheers, > David > > > > On 23/03/2016 6:41 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have fixes for the following two bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> Both fixes are very, very small and will be bundled together in the >> same changeset for obvious reasons. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >> >> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >> the race is much, much longer. I've attached the detailed evaluation >> to this RFR; it is a copy of the same note that I added to >> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >> copy has all the indentation white space intact. I don't know why >> JBS likes to reformat the notes, but it does... :-( >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan From daniel.daugherty at oracle.com Thu Mar 24 21:15:55 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Mar 2016 15:15:55 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F4584A.2020805@oracle.com> References: <56F1ADEC.2050508@oracle.com> <56F43EA5.7040101@oracle.com> <56F4584A.2020805@oracle.com> Message-ID: <56F4590B.8030709@oracle.com> On 3/24/16 3:12 PM, Vladimir Kozlov wrote: > On 3/24/16 12:23 PM, David Holmes wrote: >> Hi Dan, >> >> Couldn't pass up the chance to review this - truly great debugging here! > > +1 > > Changes are good. Thanks! Dan > > Thanks, > Vladimir > >> >> The changes of course look good. >> >> I was surprised to notice that before this fix the Lock argument >> (which should be lower-case lock if you don't mind >> adjusting that) was actually unused in quick_enter! So one has to >> wonder why it was passed in. >> >> Cheers, >> David >> >> >> >> On 23/03/2016 6:41 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have fixes for the following two bugs: >>> >>> JDK-8077392 Stream fork/join tasks occasionally fail to complete >>> https://bugs.openjdk.java.net/browse/JDK-8077392 >>> >>> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is >>> fixed >>> https://bugs.openjdk.java.net/browse/JDK-8131715 >>> >>> Both fixes are very, very small and will be bundled together in the >>> same changeset for obvious reasons. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >>> >>> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >>> the race is much, much longer. I've attached the detailed evaluation >>> to this RFR; it is a copy of the same note that I added to >>> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >>> copy has all the indentation white space intact. I don't know why >>> JBS likes to reformat the notes, but it does... :-( >>> >>> Testing: >>> >>> - the original failing test is running in a parallel stress config >>> on my Solaris X64 server; just under 23 hours and just under >>> 3000 iterations without a failure in either instance; I'm planning >>> to let the stress run go for at least 72 hours. >>> - RT/SVC nightly equivalent (in progress) >>> >>> As always, comments, suggestions and/or questions are welcome. >>> >>> Dan From vladimir.kozlov at oracle.com Thu Mar 24 21:27:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Mar 2016 14:27:15 -0700 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F1BAB0.2000001@oracle.com> References: <56F1BAB0.2000001@oracle.com> Message-ID: <56F45BB3.8000006@oracle.com> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did in c1_LIRAssembler_x86.cpp Do runtime group have plan to remove EmitSync?: experimental(intx, EmitSync, 0, \ "(Unsafe, Unstable) " \ "Control emission of inline sync fast-path code") \ I (and many other I am sure) dont' have any clue what values could be used. There is a lot of code for different values in MacroAssembler::fast_unlock() and most of them are not tested. When I worked on RTM I only guessed what should be done. I am not surprise that you found problem in it: orptr instead of xorptr. Thanks, Vladimir On 3/22/16 2:35 PM, Daniel D. Daugherty wrote: > Greetings, > > As a follow on to my fix for the following bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > I have a fix for the following bug: > > JDK-8152358 code and comment cleanups found during the hunt for 8077392 > https://bugs.openjdk.java.net/browse/JDK-8152358 > > These cleanups are pretty straight forward so I'm not going to > include the usual long, detailed analysis... :-) > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ > > This webrev is a superset of the webrev for the JDK-8077392 and > JDK-8131715 fixes and is the code that I'm currently testing... > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan From daniel.daugherty at oracle.com Thu Mar 24 21:59:13 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Mar 2016 15:59:13 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F45BB3.8000006@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> Message-ID: <56F46331.6050006@oracle.com> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: > In sharedRuntime.cpp you could use BasicObjectLock::size() as you did > in c1_LIRAssembler_x86.cpp I'll take a look. I may leave that cleanup to another pass, if you would be OK with it... I'm nearing the end of my 72 hour stress test cycle and don't want to repeat it... :-) > Do runtime group have plan to remove EmitSync?: > > experimental(intx, EmitSync, > 0, \ > "(Unsafe, Unstable) > " \ > "Control emission of inline sync fast-path > code") \ No immediate plans to do more flag removal in JDK9. Just "downgraded" a number of the flags to "experimental" in JDK9 so that we have an easier time with cleaning them up in JDK10... > I (and many other I am sure) dont' have any clue what values could be > used. I only know when I've read the code recently... I'm sure that only Dave Dice and Doug Lea know all the special knob values by heart... > There is a lot of code for different values in > MacroAssembler::fast_unlock() and most of them are not tested. Yes, we're investigating mechanisms for migrating the experimental code outside of the VM into a loadable module so that Dice and Lea can do their experiments and the rest of the world can have a simpler out-of-box code reading and maintaining experience... :-) > When I worked on RTM I only guessed what should be done. I remember that from when I reviewed the RTM stuff... > I am not surprise that you found problem in it: orptr instead of xorptr. Yup. I have notes to myself that we could sometimes end up with a non-NULL register at a later jump target because the xorptr wasn't on the common parent code path, but I have to go back and verify that note... Thanks for the review. Dan > > Thanks, > Vladimir > > On 3/22/16 2:35 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> As a follow on to my fix for the following bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is >> fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> I have a fix for the following bug: >> >> JDK-8152358 code and comment cleanups found during the hunt for >> 8077392 >> https://bugs.openjdk.java.net/browse/JDK-8152358 >> >> These cleanups are pretty straight forward so I'm not going to >> include the usual long, detailed analysis... :-) >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ >> >> This webrev is a superset of the webrev for the JDK-8077392 and >> JDK-8131715 fixes and is the code that I'm currently testing... >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan From yasuenag at gmail.com Thu Mar 24 23:48:01 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 25 Mar 2016 08:48:01 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56F41AFF.4090002@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> Message-ID: Hi Robbin, 2016/03/25 1:51 "Robbin Ehn" : > > Hi Yasumasa, > > I'm not sure why you don't set it: > > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 +0000 > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 +0100 > @@ -3584,6 +3584,7 @@ > JavaThread* main_thread = new JavaThread(); > main_thread->set_thread_state(_thread_in_vm); > main_thread->initialize_thread_current(); > + main_thread->set_native_thread_name("main"); > // must do this before set_active_handles > main_thread->record_stack_base_and_size(); > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > > here instead? Am I missing something? Native thread name is the same to thread name in Thread class. It is set in c'tor in Thread or setName(). If you create new thread in Java app, native thread name will be set at startup. However, main thread is already starte in VM. Thread name for "main" is set in create_initial_thread(). I think that the place of setting thrrad name should be the same. > The launcher seem to name itself 'java' and naming this thread just > 'main' is confusing to me. > > E.g. so main thread of the process (and thus the process) is 'java' but > first JavaThread is 'main'. The native main thread in the process is not JavaThread. It is waiting for ending of Java main thread with pthread_join(). set_native_thread_name() is for JavaThread. So I think that we do not need to call it for native main thread. Thanks, Yasumasa > Thanks! > > /Robbin > > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > > Hi all, > > > > HotSpot for Linux will set thread name via pthread_setname_np(). > > However, main thread does not have it. > > > > All JavaThread have native name, and main thread is JavaThread. > > For consistency, main thread should have native thread name. > > > > I uploaded a webrev. Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > > > > I cannot access JPRT. > > So I need a sponsor. > > > > > > Thanks, > > > > Yasumasa > > From calvin.cheung at oracle.com Fri Mar 25 00:40:54 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 24 Mar 2016 17:40:54 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: References: <56EC6A3F.7070500@oracle.com> Message-ID: <56F48916.7040604@oracle.com> Hi Jiangli, I agreed with both of your comments. On 3/23/16, 4:24 PM, Jiangli Zhou wrote: > Hi Calvin, > > I have two comments below. > > - I?d suggest putting the new block of code (added in open_stream()) in a separate function. The new function should be defined for CDS_ONLY. > > - In the bug report, it is suggested that the search for versioned class stops at 8. The changes in the webrev search all versions down to 6. Could you please verify what the spec says. The VM behavior should be the same a the JDK library code. I've checked that the base version is set to 8 in java.util.jar.JarFile. Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ thanks, Calvin > > Thanks, > Jiangli > >> On Mar 18, 2016, at 1:51 PM, Calvin Cheung wrote: >> >> >> This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. >> >> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >> (unfortunately the bug was marked as "confidential") >> >> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >> >> Some adjustments need to be made due to: >> - attribute name in the jar manifest has been changed to "Multi-release"; >> - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". >> >> The diff between this patch and the reviewed patch is as follows: >> >> 11c11 >> < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); >> --- >>> + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); >> 14c14 >> < + strcmp(multi_ver, "true") == 0 || >> --- >>> + strcmp(multi_ver, "enable") == 0 || >> 64c64 >> < @@ -296,6 +345,17 @@ >> --- >>> @@ -272,6 +321,17 @@ >> 72c72 >> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >> --- >>> + if (strstr(buffer, "Multiversion: true") != NULL) { >> thanks, >> Calvin >> >> [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From ioi.lam at oracle.com Fri Mar 25 04:01:29 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 24 Mar 2016 21:01:29 -0700 Subject: RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode Message-ID: <56F4B819.90902@oracle.com> Please review a very small fix: http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ https://bugs.openjdk.java.net/browse/JDK-8152380 Summary of fix: I added a new function, SymbolTable::hash_shared_symbol(), that does not use the alternate hashing algorithm. To validate the fix, I added new test cases that force alternate hashing while CDS is enabled (thus we have a shared symbol/string tables). Unfortunately the tests are in closed repos. Testing showed that the problem existed only for the shared symbol table. The shared string table already did not use the alternate hashing algorithm. Tests: JPRT RBT with hotspot tests Thanks - Ioi From ioi.lam at oracle.com Fri Mar 25 04:05:51 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 24 Mar 2016 21:05:51 -0700 Subject: [Closed] RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode In-Reply-To: <56F4B819.90902@oracle.com> References: <56F4B819.90902@oracle.com> Message-ID: <56F4B91F.6040509@oracle.com> Here are the closed changes: http://ioilinux.us.oracle.com/webrev/jdk9/jdk9/8152380_shared_table_rehashing.v02/ New tests to force alternate hashing for strings and symbols: runtime/7158800/BadUtf8_Shared.java runtime/7158800/InternTest_Shared.java I also added a few test cases in runtime/AppCDS/sharedStrings/InternStringTest.java to check for correct hashing of different UNICODE characters. Thanks - Ioi On 3/24/16 9:01 PM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ > > https://bugs.openjdk.java.net/browse/JDK-8152380 > > Summary of fix: > > I added a new function, SymbolTable::hash_shared_symbol(), that does not > use the alternate hashing algorithm. > > To validate the fix, I added new test cases that force alternate > hashing > while CDS is enabled (thus we have a shared symbol/string tables). > Unfortunately the tests are in closed repos. > > Testing showed that the problem existed only for the shared symbol > table. > The shared string table already did not use the alternate hashing > algorithm. > > Tests: > > JPRT > RBT with hotspot tests > > Thanks > - Ioi From coleen.phillimore at oracle.com Fri Mar 25 13:42:31 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Mar 2016 09:42:31 -0400 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56F48916.7040604@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> Message-ID: <56F54047.1010306@oracle.com> Hi Calvin, I didn't really review this but could you add a // INCLUDE_CDS on the #endif in this code. http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html Thanks, Coleen On 3/24/16 8:40 PM, Calvin Cheung wrote: > Hi Jiangli, > > I agreed with both of your comments. > > On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> I have two comments below. >> >> - I?d suggest putting the new block of code (added in open_stream()) >> in a separate function. The new function should be defined for CDS_ONLY. >> >> - In the bug report, it is suggested that the search for versioned >> class stops at 8. The changes in the webrev search all versions down >> to 6. Could you please verify what the spec says. The VM behavior >> should be the same a the JDK library code. > I've checked that the base version is set to 8 in java.util.jar.JarFile. > > Here's an updated webrev: > http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ > > thanks, > Calvin > >> >> Thanks, >> Jiangli >> >>> On Mar 18, 2016, at 1:51 PM, Calvin >>> Cheung wrote: >>> >>> >>> This fix was reviewed in Aug 2015[1] though most of the review >>> comments was via internal mailing list. Recently, the JEP 238 >>> (Multiple-Release jar files) has been checked into jdk9. So it is >>> time to make the corresponding changes in hotspot. >>> >>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>> (unfortunately the bug was marked as "confidential") >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>> >>> Some adjustments need to be made due to: >>> - attribute name in the jar manifest has been changed to >>> "Multi-release"; >>> - system property has been changed to >>> jdk.util.jar.enableMultiRelease and it has value of "true", "force" >>> or "false". >>> >>> The diff between this patch and the reviewed patch is as follows: >>> >>> 11c11 >>> < + const char* multi_ver = >>> Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>> --- >>>> + const char* multi_ver = >>>> Arguments::get_property("jdk.util.jar.multiversion"); >>> 14c14 >>> < + strcmp(multi_ver, "true") == 0 || >>> --- >>>> + strcmp(multi_ver, "enable") == 0 || >>> 64c64 >>> < @@ -296,6 +345,17 @@ >>> --- >>>> @@ -272,6 +321,17 @@ >>> 72c72 >>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>> --- >>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>> thanks, >>> Calvin >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From coleen.phillimore at oracle.com Fri Mar 25 13:47:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Mar 2016 09:47:19 -0400 Subject: RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode In-Reply-To: <56F4B819.90902@oracle.com> References: <56F4B819.90902@oracle.com> Message-ID: <56F54167.4050501@oracle.com> Ioi, This looks good. Thank you for fixing this. http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/src/share/vm/classfile/symbolTable.cpp.udiff.html Can you add a 1 line comment at line 209, something like // hash_code parameter may use alternate hashing algorithm but the shared table always uses the same original hash code (ie. why you have this if statement). thanks, Coleen On 3/25/16 12:01 AM, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ > > https://bugs.openjdk.java.net/browse/JDK-8152380 > > Summary of fix: > > I added a new function, SymbolTable::hash_shared_symbol(), that does not > use the alternate hashing algorithm. > > To validate the fix, I added new test cases that force alternate > hashing > while CDS is enabled (thus we have a shared symbol/string tables). > Unfortunately the tests are in closed repos. > > Testing showed that the problem existed only for the shared symbol > table. > The shared string table already did not use the alternate hashing > algorithm. > > Tests: > > JPRT > RBT with hotspot tests > > Thanks > - Ioi From gerard.ziemski at oracle.com Fri Mar 25 16:26:35 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 25 Mar 2016 11:26:35 -0500 Subject: RFR (S): 8136766: Enable ThreadStackSize range test Message-ID: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> hi all, Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on Windows) and adds constraint for ThreadStackSize, which allows us to include it in test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. https://bugs.openjdk.java.net/browse/JDK-8136766 http://cr.openjdk.java.net/~gziemski/8136766_rev1 Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From gerard.ziemski at oracle.com Fri Mar 25 16:26:39 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 25 Mar 2016 11:26:39 -0500 Subject: RFR (S): 8143958: CDS Shared flags need constraint function Message-ID: hi all, Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. https://bugs.openjdk.java.net/browse/JDK-8143958 http://cr.openjdk.java.net/~gziemski/8143958_rev1 Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From max.ockner at oracle.com Fri Mar 25 17:28:12 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 25 Mar 2016 13:28:12 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging Message-ID: <56F5752C.9090201@oracle.com> Hello, Please review another Unified Logging conversion. Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ TraceMonitorMismatch has been converted to unified logging with monitormismatch tag and info level. There is very little output. To trigger the output, I ran a program which does a monitorenter without a monitorexit. 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' Tested with jtreg runtime tests and added MonitorMismatchTest.java to test for the output. The test body doesn't run on embedded since it uses TieredCompilation. If you search for TraceMonitorMismatch in the new source, you will find a bunch of instances in jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. This file is a java implementation of GenerateOopMap.cpp and the two files aren't tied together in any way. This java level TraceMonitorMismatch flag is set to true in the code and doesn't get its value from the jvm level TraceMonitorMismatch flag. I have left these alone as another unfortunate naming coincidence. Thanks, Max From jiangli.zhou at oracle.com Fri Mar 25 17:54:54 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 25 Mar 2016 10:54:54 -0700 Subject: RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode In-Reply-To: <56F54167.4050501@oracle.com> References: <56F4B819.90902@oracle.com> <56F54167.4050501@oracle.com> Message-ID: +1 Thanks, Jiangli > On Mar 25, 2016, at 6:47 AM, Coleen Phillimore wrote: > > > Ioi, > This looks good. Thank you for fixing this. > > http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/src/share/vm/classfile/symbolTable.cpp.udiff.html > > Can you add a 1 line comment at line 209, something like > // hash_code parameter may use alternate hashing algorithm but the shared table always uses the same original hash code > (ie. why you have this if statement). > > thanks, > Coleen > > On 3/25/16 12:01 AM, Ioi Lam wrote: >> Please review a very small fix: >> >> http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ >> https://bugs.openjdk.java.net/browse/JDK-8152380 >> >> Summary of fix: >> >> I added a new function, SymbolTable::hash_shared_symbol(), that does not >> use the alternate hashing algorithm. >> >> To validate the fix, I added new test cases that force alternate hashing >> while CDS is enabled (thus we have a shared symbol/string tables). >> Unfortunately the tests are in closed repos. >> >> Testing showed that the problem existed only for the shared symbol table. >> The shared string table already did not use the alternate hashing algorithm. >> >> Tests: >> >> JPRT >> RBT with hotspot tests >> >> Thanks >> - Ioi > From rachel.protacio at oracle.com Fri Mar 25 18:18:10 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 25 Mar 2016 14:18:10 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56F5752C.9090201@oracle.com> References: <56F5752C.9090201@oracle.com> Message-ID: <56F580E2.8040206@oracle.com> Hey, Max, The code looks fine as-is, but perhaps could be optimized? Since all the uses of monitormismatch call report_monitor_mismatch(), which has its code in non-product only, you could remove the conditionals around it and have the function declared with "PRODUCT_RETURN." Then, inside the function you could put the "if log_is_enabled". So there will be less compiled code in product mode. (This might also mean you could make the monitormismatch tag "DEBUG_ONLY", but I'm not 100% sure about how that works.) Rachel On 3/25/2016 1:28 PM, Max Ockner wrote: > Hello, > Please review another Unified Logging conversion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 > Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ > > TraceMonitorMismatch has been converted to unified logging with > monitormismatch tag and info level. There is very little output. To > trigger the output, I ran a program which does a monitorenter without > a monitorexit. > > 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' > > Tested with jtreg runtime tests and added MonitorMismatchTest.java to > test for the output. The test body doesn't run on embedded since it > uses TieredCompilation. > > If you search for TraceMonitorMismatch in the new source, you will > find a bunch of instances in > jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. > This file is a java implementation of GenerateOopMap.cpp and the two > files aren't tied together in any way. This java level > TraceMonitorMismatch flag is set to true in the code and doesn't get > its value from the jvm level TraceMonitorMismatch flag. I have left > these alone as another unfortunate naming coincidence. > > Thanks, > Max From ioi.lam at oracle.com Fri Mar 25 20:33:46 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 25 Mar 2016 13:33:46 -0700 Subject: RFR (XS) 8152380 - Shared symbol/string tables should never use alternate hashcode In-Reply-To: References: <56F4B819.90902@oracle.com> <56F54167.4050501@oracle.com> Message-ID: <56F5A0AA.5070706@oracle.com> Thanks Coleen & Jiangli for the review. I will add the comment when I do the push. - Ioi On 3/25/16 10:54 AM, Jiangli Zhou wrote: > +1 > > Thanks, > Jiangli > >> On Mar 25, 2016, at 6:47 AM, Coleen Phillimore wrote: >> >> >> Ioi, >> This looks good. Thank you for fixing this. >> >> http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/src/share/vm/classfile/symbolTable.cpp.udiff.html >> >> Can you add a 1 line comment at line 209, something like >> // hash_code parameter may use alternate hashing algorithm but the shared table always uses the same original hash code >> (ie. why you have this if statement). >> >> thanks, >> Coleen >> >> On 3/25/16 12:01 AM, Ioi Lam wrote: >>> Please review a very small fix: >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8152380_shared_table_rehashing.v02/ >>> https://bugs.openjdk.java.net/browse/JDK-8152380 >>> >>> Summary of fix: >>> >>> I added a new function, SymbolTable::hash_shared_symbol(), that does not >>> use the alternate hashing algorithm. >>> >>> To validate the fix, I added new test cases that force alternate hashing >>> while CDS is enabled (thus we have a shared symbol/string tables). >>> Unfortunately the tests are in closed repos. >>> >>> Testing showed that the problem existed only for the shared symbol table. >>> The shared string table already did not use the alternate hashing algorithm. >>> >>> Tests: >>> >>> JPRT >>> RBT with hotspot tests >>> >>> Thanks >>> - Ioi From ioi.lam at oracle.com Fri Mar 25 20:47:32 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 25 Mar 2016 13:47:32 -0700 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: References: Message-ID: <56F5A3E4.4090607@oracle.com> Hi Gerard, This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: 136 if (value > max) { 137 CommandLineError::print(verbose, 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " 139 "smaller than (" SIZE_FORMAT ")\n", 140 value, max); 141 return Flag::VIOLATES_CONSTRAINT; 142 } else { 143 return Flag::SUCCESS; 144 } Should that be wrapped in a helper function like this? return CommandLineError::check_max(value, max, "SharedReadWriteSize"); Thanks - Ioi On 3/25/16 9:26 AM, Gerard Ziemski wrote: > hi all, > > Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. > > https://bugs.openjdk.java.net/browse/JDK-8143958 > http://cr.openjdk.java.net/~gziemski/8143958_rev1 > > Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. > From kubota.yuji at gmail.com Mon Mar 28 10:22:29 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 28 Mar 2016 19:22:29 +0900 Subject: jdk9 (fastdebug) build failed with gcc version 4.4.7-16 Message-ID: Hi everyone, I just cloned jdk9/dev and built fastdebug, then failed as similar as JDK-8047382 [1]. /mockbuild/jdk9/dev/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function 'static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)': /mockbuild/jdk9/dev/hotspot/src/share/vm/services/classLoadingService.cpp:147: error: cannot reload integer constant operand in 'asm' /mockbuild/jdk9/dev/hotspot/src/share/vm/services/classLoadingService.cpp:147: error: cannot reload integer constant operand in 'asm' gmake[8]: *** [classLoadingService.o] Error 1 As Lois said at JDK-8047382 [1], the HS_DTRACE_PROBE# macros has been removed in JDK9. However, similar macros has came back by JDK-7098194 [2], then failed when we used specified gcc version. So I create a patch to fix it. Should I create a new issue at JBS, or wait to remove the macros again? [1]: https://bugs.openjdk.java.net/browse/JDK-8047382 [2]: https://bugs.openjdk.java.net/browse/JDK-7098194 The gcc version of my build machine is: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) My proposal patch is: diff --git a/src/share/vm/oops/instanceKlass.cpp b/src/share/vm/oops/instanceKlass.cpp --- a/src/share/vm/oops/instanceKlass.cpp +++ b/src/share/vm/oops/instanceKlass.cpp @@ -92,7 +92,7 @@ len = name->utf8_length(); \ } \ HOTSPOT_CLASS_INITIALIZATION_##type( \ - data, len, (clss)->class_loader(), thread_type); \ + data, len, (void *)(clss)->class_loader(), thread_type); \ } #define DTRACE_CLASSINIT_PROBE_WAIT(type, clss, thread_type, wait) \ @@ -105,7 +105,7 @@ len = name->utf8_length(); \ } \ HOTSPOT_CLASS_INITIALIZATION_##type( \ - data, len, (clss)->class_loader(), thread_type, wait); \ + data, len, (void *)(clss)->class_loader(), thread_type, wait); \ } #else // ndef DTRACE_ENABLED diff --git a/src/share/vm/services/classLoadingService.cpp b/src/share/vm/services/classLoadingService.cpp --- a/src/share/vm/services/classLoadingService.cpp +++ b/src/share/vm/services/classLoadingService.cpp @@ -52,7 +52,7 @@ len = name->utf8_length(); \ } \ HOTSPOT_CLASS_##type( /* type = unloaded, loaded */ \ - data, len, (clss)->class_loader(), (shared)); \ + data, len, (void *)(clss)->class_loader(), (shared)); \ } #else // ndef DTRACE_ENABLED Thanks, Yuji From max.ockner at oracle.com Mon Mar 28 17:11:52 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 28 Mar 2016 13:11:52 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56E9CB8E.6000109@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> <56E97513.40902@oracle.com> <56E9CB8E.6000109@oracle.com> Message-ID: <56F965D8.2090600@oracle.com> Hey everyone. Patching this into a jake repo was difficult as there were other dependencies that had not yet been pulled into jake. As a result, I tabled this until jigsaw integration. New webrev: http://cr.openjdk.java.net/~mockner/8149996.06/ - Updated the test to check for new paths. Tested with jtreg runtime. Thanks, Max On 3/16/2016 5:09 PM, David Holmes wrote: > Follow ups below ... > > On 17/03/2016 1:00 AM, Max Ockner wrote: >> Comments below. >> >> On 3/16/2016 2:11 AM, David Holmes wrote: >>> Hi Max, >>> >>> tl;dr: you can push this as-is (modulo fixing copyright years) but I >>> have some further queries/discussion points below. :) >>> >>> Meta question: should we consider using "classload, constraints" >>> instead of "loaderconstraints" ? >>> >> I think this would be appropriate. > > Ok. > >>> On 16/03/2016 1:00 AM, Max Ockner wrote: >>>> Hello again, >>>> >>>> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >>>> - added resource marks back in >>>> - reverted to using outputStreams instead of log_info macro >>>> >>>> I ran into an issue with the outputStream eating its output when I >>>> removed " ]\n" from the end of some of the messages, solved by >>>> changing >>>> "out->print" to "out->print_cr". >>> >>> Aside: it is actually more efficient to have the \n in the string than >>> to use the print_cr form. :) >>> >> Thanks for pointing this out. I can change it. > > It was just an observation - we don't pay this much attention elsewhere. > >>> Nit: is there a reason to remove the initial capitals from the log >>> messages? I find the capitals are a visual aid when trying to find the >>> end of the decorators. >>> >>> Aside 2: I notice we have now removed the only example of a product_rw >>> flag. I wonder if we should rip out product_rw support? (Separate RFE >>> of course). I'm also wondering if our logging flags are >>> visible/modifiable via the management tools like manageable/product_rw >>> flags are? >>> >> From an email discussion with Marcus: >> "There is a DCMD to reconfigure logging during runtime. It's all baked >> into a single command called VM.log and it works similar to the -Xlog >> command, but all of the parameters are named, so -Xlog:gc:gclog.txt >> would be VM.log output=gclog.txt what=gc." > > Thanks. > >>> With regard to the test I'm not sure those "loaders" are going to >>> continue to be valid once Jake has integrated. So you might want to >>> try this on a Jake build before finalising it. >>> >> >> Do you think this is important to test before submitting? > > It might stop working next week so yes I think it worth checking this > now. > > Thanks, > David > >>> Thanks, >>> David >>> >>>> I thought about writing a log_info_rm which evaluates to a code block >>>> instead of a function, but I think one of the benefits of the current >>>> macros is that they allow two variable argument lists in the same >>>> expression. Returning a write function is important for handling the >>>> format string and its variable length argument list of format >>>> %substitutions. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>> On 3/9/2016 11:29 PM, David Holmes wrote: >>>>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Why did you take out the ResourceMarks at line 130, 160, 231 and >>>>>> 244, >>>>>> 297, 308 and 357? >>>>> >>>>> Yes these should all be of the form: >>>>> >>>>> if (log_is_enabled(...)) { >>>>> ResourceMark rm; >>>>> // log stuff >>>>> } >>>>> >>>>>> Unfortunately, we really need log_info_rm(tag)("String") call >>>>>> because >>>>>> all those places need a ResourceMark. >>>>>> >>>>>> Anytime we call name()->as_C_string() there needs to be a >>>>>> ResourceMark >>>>>> in the scope of the call. >>>>> >>>>> Which means that a log_info_rm() call wouldn't help because we'd >>>>> still >>>>> be calling as_C_string in the caller. :( >>>>> >>>>> David >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>>>> Hello again, >>>>>>> >>>>>>> Please review this change. TraceLoaderConstraints has been >>>>>>> converted >>>>>>> to Unified Logging and can be accessed using >>>>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been >>>>>>> added >>>>>>> to the logging alias table. >>>>>>> >>>>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>>>> LoaderConstraintsTest.java >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>>>> >>>>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>>>> loaderconstraints by forcing class unloading. No other >>>>>>> references to >>>>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>>>>> noncolo tests. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>> >>>> >> From rachel.protacio at oracle.com Mon Mar 28 17:17:34 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 28 Mar 2016 13:17:34 -0400 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F1BAB0.2000001@oracle.com> References: <56F1BAB0.2000001@oracle.com> Message-ID: <56F9672E.8040301@oracle.com> Just to weigh in on the logging - the biasedLocking.cpp changes look good to me! Thanks for fixing those spacing issues. Rachel On 3/22/2016 5:35 PM, Daniel D. Daugherty wrote: > Greetings, > > As a follow on to my fix for the following bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > I have a fix for the following bug: > > JDK-8152358 code and comment cleanups found during the hunt for > 8077392 > https://bugs.openjdk.java.net/browse/JDK-8152358 > > These cleanups are pretty straight forward so I'm not going to > include the usual long, detailed analysis... :-) > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ > > This webrev is a superset of the webrev for the JDK-8077392 and > JDK-8131715 fixes and is the code that I'm currently testing... > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan From rachel.protacio at oracle.com Mon Mar 28 18:50:07 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 28 Mar 2016 14:50:07 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56F965D8.2090600@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> <56E97513.40902@oracle.com> <56E9CB8E.6000109@oracle.com> <56F965D8.2090600@oracle.com> Message-ID: <56F97CDF.1080306@oracle.com> Looks good to me! Rachel On 3/28/2016 1:11 PM, Max Ockner wrote: > Hey everyone. Patching this into a jake repo was difficult as there > were other dependencies that had not yet been pulled into jake. As a > result, I tabled this until jigsaw integration. > > New webrev: http://cr.openjdk.java.net/~mockner/8149996.06/ > - Updated the test to check for new paths. > > Tested with jtreg runtime. > > Thanks, > Max > > On 3/16/2016 5:09 PM, David Holmes wrote: >> Follow ups below ... >> >> On 17/03/2016 1:00 AM, Max Ockner wrote: >>> Comments below. >>> >>> On 3/16/2016 2:11 AM, David Holmes wrote: >>>> Hi Max, >>>> >>>> tl;dr: you can push this as-is (modulo fixing copyright years) but I >>>> have some further queries/discussion points below. :) >>>> >>>> Meta question: should we consider using "classload, constraints" >>>> instead of "loaderconstraints" ? >>>> >>> I think this would be appropriate. >> >> Ok. >> >>>> On 16/03/2016 1:00 AM, Max Ockner wrote: >>>>> Hello again, >>>>> >>>>> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >>>>> - added resource marks back in >>>>> - reverted to using outputStreams instead of log_info macro >>>>> >>>>> I ran into an issue with the outputStream eating its output when I >>>>> removed " ]\n" from the end of some of the messages, solved by >>>>> changing >>>>> "out->print" to "out->print_cr". >>>> >>>> Aside: it is actually more efficient to have the \n in the string than >>>> to use the print_cr form. :) >>>> >>> Thanks for pointing this out. I can change it. >> >> It was just an observation - we don't pay this much attention elsewhere. >> >>>> Nit: is there a reason to remove the initial capitals from the log >>>> messages? I find the capitals are a visual aid when trying to find the >>>> end of the decorators. >>>> >>>> Aside 2: I notice we have now removed the only example of a product_rw >>>> flag. I wonder if we should rip out product_rw support? (Separate RFE >>>> of course). I'm also wondering if our logging flags are >>>> visible/modifiable via the management tools like manageable/product_rw >>>> flags are? >>>> >>> From an email discussion with Marcus: >>> "There is a DCMD to reconfigure logging during runtime. It's all baked >>> into a single command called VM.log and it works similar to the -Xlog >>> command, but all of the parameters are named, so -Xlog:gc:gclog.txt >>> would be VM.log output=gclog.txt what=gc." >> >> Thanks. >> >>>> With regard to the test I'm not sure those "loaders" are going to >>>> continue to be valid once Jake has integrated. So you might want to >>>> try this on a Jake build before finalising it. >>>> >>> >>> Do you think this is important to test before submitting? >> >> It might stop working next week so yes I think it worth checking this >> now. >> >> Thanks, >> David >> >>>> Thanks, >>>> David >>>> >>>>> I thought about writing a log_info_rm which evaluates to a code block >>>>> instead of a function, but I think one of the benefits of the current >>>>> macros is that they allow two variable argument lists in the same >>>>> expression. Returning a write function is important for handling the >>>>> format string and its variable length argument list of format >>>>> %substitutions. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>> On 3/9/2016 11:29 PM, David Holmes wrote: >>>>>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Why did you take out the ResourceMarks at line 130, 160, 231 and >>>>>>> 244, >>>>>>> 297, 308 and 357? >>>>>> >>>>>> Yes these should all be of the form: >>>>>> >>>>>> if (log_is_enabled(...)) { >>>>>> ResourceMark rm; >>>>>> // log stuff >>>>>> } >>>>>> >>>>>>> Unfortunately, we really need log_info_rm(tag)("String") call >>>>>>> because >>>>>>> all those places need a ResourceMark. >>>>>>> >>>>>>> Anytime we call name()->as_C_string() there needs to be a >>>>>>> ResourceMark >>>>>>> in the scope of the call. >>>>>> >>>>>> Which means that a log_info_rm() call wouldn't help because we'd >>>>>> still >>>>>> be calling as_C_string in the caller. :( >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> Please review this change. TraceLoaderConstraints has been >>>>>>>> converted >>>>>>>> to Unified Logging and can be accessed using >>>>>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been >>>>>>>> added >>>>>>>> to the logging alias table. >>>>>>>> >>>>>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>>>>> LoaderConstraintsTest.java >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>>>>> >>>>>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>>>>> loaderconstraints by forcing class unloading. No other >>>>>>>> references to >>>>>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>>>>>> noncolo tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Mon Mar 28 19:01:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Mar 2016 15:01:45 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56F965D8.2090600@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> <56E97513.40902@oracle.com> <56E9CB8E.6000109@oracle.com> <56F965D8.2090600@oracle.com> Message-ID: <56F97F99.70805@oracle.com> Max, This looks good! Thanks, Coleen On 3/28/16 1:11 PM, Max Ockner wrote: > Hey everyone. Patching this into a jake repo was difficult as there > were other dependencies that had not yet been pulled into jake. As a > result, I tabled this until jigsaw integration. > > New webrev: http://cr.openjdk.java.net/~mockner/8149996.06/ > - Updated the test to check for new paths. > > Tested with jtreg runtime. > > Thanks, > Max > > On 3/16/2016 5:09 PM, David Holmes wrote: >> Follow ups below ... >> >> On 17/03/2016 1:00 AM, Max Ockner wrote: >>> Comments below. >>> >>> On 3/16/2016 2:11 AM, David Holmes wrote: >>>> Hi Max, >>>> >>>> tl;dr: you can push this as-is (modulo fixing copyright years) but I >>>> have some further queries/discussion points below. :) >>>> >>>> Meta question: should we consider using "classload, constraints" >>>> instead of "loaderconstraints" ? >>>> >>> I think this would be appropriate. >> >> Ok. >> >>>> On 16/03/2016 1:00 AM, Max Ockner wrote: >>>>> Hello again, >>>>> >>>>> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >>>>> - added resource marks back in >>>>> - reverted to using outputStreams instead of log_info macro >>>>> >>>>> I ran into an issue with the outputStream eating its output when I >>>>> removed " ]\n" from the end of some of the messages, solved by >>>>> changing >>>>> "out->print" to "out->print_cr". >>>> >>>> Aside: it is actually more efficient to have the \n in the string than >>>> to use the print_cr form. :) >>>> >>> Thanks for pointing this out. I can change it. >> >> It was just an observation - we don't pay this much attention elsewhere. >> >>>> Nit: is there a reason to remove the initial capitals from the log >>>> messages? I find the capitals are a visual aid when trying to find the >>>> end of the decorators. >>>> >>>> Aside 2: I notice we have now removed the only example of a product_rw >>>> flag. I wonder if we should rip out product_rw support? (Separate RFE >>>> of course). I'm also wondering if our logging flags are >>>> visible/modifiable via the management tools like manageable/product_rw >>>> flags are? >>>> >>> From an email discussion with Marcus: >>> "There is a DCMD to reconfigure logging during runtime. It's all baked >>> into a single command called VM.log and it works similar to the -Xlog >>> command, but all of the parameters are named, so -Xlog:gc:gclog.txt >>> would be VM.log output=gclog.txt what=gc." >> >> Thanks. >> >>>> With regard to the test I'm not sure those "loaders" are going to >>>> continue to be valid once Jake has integrated. So you might want to >>>> try this on a Jake build before finalising it. >>>> >>> >>> Do you think this is important to test before submitting? >> >> It might stop working next week so yes I think it worth checking this >> now. >> >> Thanks, >> David >> >>>> Thanks, >>>> David >>>> >>>>> I thought about writing a log_info_rm which evaluates to a code block >>>>> instead of a function, but I think one of the benefits of the current >>>>> macros is that they allow two variable argument lists in the same >>>>> expression. Returning a write function is important for handling the >>>>> format string and its variable length argument list of format >>>>> %substitutions. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>> On 3/9/2016 11:29 PM, David Holmes wrote: >>>>>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Why did you take out the ResourceMarks at line 130, 160, 231 and >>>>>>> 244, >>>>>>> 297, 308 and 357? >>>>>> >>>>>> Yes these should all be of the form: >>>>>> >>>>>> if (log_is_enabled(...)) { >>>>>> ResourceMark rm; >>>>>> // log stuff >>>>>> } >>>>>> >>>>>>> Unfortunately, we really need log_info_rm(tag)("String") call >>>>>>> because >>>>>>> all those places need a ResourceMark. >>>>>>> >>>>>>> Anytime we call name()->as_C_string() there needs to be a >>>>>>> ResourceMark >>>>>>> in the scope of the call. >>>>>> >>>>>> Which means that a log_info_rm() call wouldn't help because we'd >>>>>> still >>>>>> be calling as_C_string in the caller. :( >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> Please review this change. TraceLoaderConstraints has been >>>>>>>> converted >>>>>>>> to Unified Logging and can be accessed using >>>>>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has been >>>>>>>> added >>>>>>>> to the logging alias table. >>>>>>>> >>>>>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>>>>> LoaderConstraintsTest.java >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>>>>> >>>>>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>>>>> loaderconstraints by forcing class unloading. No other >>>>>>>> references to >>>>>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in the >>>>>>>> noncolo tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>> >>>>> >>> > From max.ockner at oracle.com Mon Mar 28 19:10:03 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 28 Mar 2016 15:10:03 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56F580E2.8040206@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> Message-ID: <56F9818B.8070105@oracle.com> Good catch. We don't intend for this to be DEBUG_ONLY. The "#ifndef PRODUCT" has been removed. Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ If we put the log_is_enabled conditional inside the function then we will always branch to the function. The conversion of TraceClassResolution required a similar decision, and we chose to leave the log_is_enabled condition outside of the trace_class_resolution() function. Thanks, Max On 3/25/2016 2:18 PM, Rachel Protacio wrote: > Hey, Max, > > The code looks fine as-is, but perhaps could be optimized? Since all > the uses of monitormismatch call report_monitor_mismatch(), which has > its code in non-product only, you could remove the conditionals around > it and have the function declared with "PRODUCT_RETURN." Then, inside > the function you could put the "if log_is_enabled". So there will be > less compiled code in product mode. (This might also mean you could > make the monitormismatch tag "DEBUG_ONLY", but I'm not 100% sure about > how that works.) > > Rachel > > On 3/25/2016 1:28 PM, Max Ockner wrote: >> Hello, >> Please review another Unified Logging conversion. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >> >> TraceMonitorMismatch has been converted to unified logging with >> monitormismatch tag and info level. There is very little output. To >> trigger the output, I ran a program which does a monitorenter without >> a monitorexit. >> >> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' >> >> Tested with jtreg runtime tests and added MonitorMismatchTest.java to >> test for the output. The test body doesn't run on embedded since it >> uses TieredCompilation. >> >> If you search for TraceMonitorMismatch in the new source, you will >> find a bunch of instances in >> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >> This file is a java implementation of GenerateOopMap.cpp and the two >> files aren't tied together in any way. This java level >> TraceMonitorMismatch flag is set to true in the code and doesn't get >> its value from the jvm level TraceMonitorMismatch flag. I have left >> these alone as another unfortunate naming coincidence. >> >> Thanks, >> Max > From gerard.ziemski at oracle.com Mon Mar 28 19:13:57 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 28 Mar 2016 14:13:57 -0500 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: <56F5A3E4.4090607@oracle.com> References: <56F5A3E4.4090607@oracle.com> Message-ID: hi Ioi, Thank you for there review. I have factored out the common code as you suggested and I like it now much better. Updated webrev at http://cr.openjdk.java.net/~gziemski/8143958_rev2 cheers >> > On Mar 25, 2016, at 3:47 PM, Ioi Lam wrote: > > Hi Gerard, > > This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: > > 136 if (value > max) { > 137 CommandLineError::print(verbose, > 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " > 139 "smaller than (" SIZE_FORMAT ")\n", > 140 value, max); > 141 return Flag::VIOLATES_CONSTRAINT; > 142 } else { > 143 return Flag::SUCCESS; > 144 } > > > Should that be wrapped in a helper function like this? > > return CommandLineError::check_max(value, max, "SharedReadWriteSize"); > > Thanks > - Ioi > > On 3/25/16 9:26 AM, Gerard Ziemski wrote: >> hi all, >> >> Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. >> >> https://bugs.openjdk.java.net/browse/JDK-8143958 >> http://cr.openjdk.java.net/~gziemski/8143958_rev1 >> >> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. >> > From daniel.daugherty at oracle.com Mon Mar 28 19:16:24 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Mar 2016 13:16:24 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F9672E.8040301@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F9672E.8040301@oracle.com> Message-ID: <56F98308.1040400@oracle.com> Rachel, Thanks for taking a look at the logging changes. Dan On 3/28/16 11:17 AM, Rachel Protacio wrote: > Just to weigh in on the logging - the biasedLocking.cpp changes look > good to me! Thanks for fixing those spacing issues. > > Rachel > > On 3/22/2016 5:35 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> As a follow on to my fix for the following bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is >> fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> I have a fix for the following bug: >> >> JDK-8152358 code and comment cleanups found during the hunt for >> 8077392 >> https://bugs.openjdk.java.net/browse/JDK-8152358 >> >> These cleanups are pretty straight forward so I'm not going to >> include the usual long, detailed analysis... :-) >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ >> >> This webrev is a superset of the webrev for the JDK-8077392 and >> JDK-8131715 fixes and is the code that I'm currently testing... >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan > From coleen.phillimore at oracle.com Mon Mar 28 19:52:07 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Mar 2016 15:52:07 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56F9818B.8070105@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> Message-ID: <56F98B67.2090309@oracle.com> It looks like A.jasm is missing from your webrev and can you name it something more useful like MonitorMismatchHelper.java ? Otherwise, code looks good. thanks, Coleen On 3/28/16 3:10 PM, Max Ockner wrote: > Good catch. We don't intend for this to be DEBUG_ONLY. The "#ifndef > PRODUCT" has been removed. > Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ > > If we put the log_is_enabled conditional inside the function then we > will always branch to the function. The conversion of > TraceClassResolution required a similar decision, and we chose to > leave the log_is_enabled condition outside of the > trace_class_resolution() function. > > Thanks, > Max > > On 3/25/2016 2:18 PM, Rachel Protacio wrote: >> Hey, Max, >> >> The code looks fine as-is, but perhaps could be optimized? Since all >> the uses of monitormismatch call report_monitor_mismatch(), which has >> its code in non-product only, you could remove the conditionals >> around it and have the function declared with "PRODUCT_RETURN." Then, >> inside the function you could put the "if log_is_enabled". So there >> will be less compiled code in product mode. (This might also mean you >> could make the monitormismatch tag "DEBUG_ONLY", but I'm not 100% >> sure about how that works.) >> >> Rachel >> >> On 3/25/2016 1:28 PM, Max Ockner wrote: >>> Hello, >>> Please review another Unified Logging conversion. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>> >>> TraceMonitorMismatch has been converted to unified logging with >>> monitormismatch tag and info level. There is very little output. To >>> trigger the output, I ran a program which does a monitorenter >>> without a monitorexit. >>> >>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' >>> >>> Tested with jtreg runtime tests and added MonitorMismatchTest.java >>> to test for the output. The test body doesn't run on embedded since >>> it uses TieredCompilation. >>> >>> If you search for TraceMonitorMismatch in the new source, you will >>> find a bunch of instances in >>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>> This file is a java implementation of GenerateOopMap.cpp and the two >>> files aren't tied together in any way. This java level >>> TraceMonitorMismatch flag is set to true in the code and doesn't get >>> its value from the jvm level TraceMonitorMismatch flag. I have left >>> these alone as another unfortunate naming coincidence. >>> >>> Thanks, >>> Max >> > From max.ockner at oracle.com Mon Mar 28 20:15:30 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 28 Mar 2016 16:15:30 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56F98B67.2090309@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> Message-ID: <56F990E2.7080204@oracle.com> Thanks for round 1 of reviews. webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in webrev. - Fixed improper spacing in test. Thanks, Max On 3/28/2016 3:52 PM, Coleen Phillimore wrote: > > It looks like A.jasm is missing from your webrev and can you name it > something more useful like MonitorMismatchHelper.java ? > Otherwise, code looks good. > thanks, > Coleen > > On 3/28/16 3:10 PM, Max Ockner wrote: >> Good catch. We don't intend for this to be DEBUG_ONLY. The "#ifndef >> PRODUCT" has been removed. >> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >> >> If we put the log_is_enabled conditional inside the function then we >> will always branch to the function. The conversion of >> TraceClassResolution required a similar decision, and we chose to >> leave the log_is_enabled condition outside of the >> trace_class_resolution() function. >> >> Thanks, >> Max >> >> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>> Hey, Max, >>> >>> The code looks fine as-is, but perhaps could be optimized? Since all >>> the uses of monitormismatch call report_monitor_mismatch(), which >>> has its code in non-product only, you could remove the conditionals >>> around it and have the function declared with "PRODUCT_RETURN." >>> Then, inside the function you could put the "if log_is_enabled". So >>> there will be less compiled code in product mode. (This might also >>> mean you could make the monitormismatch tag "DEBUG_ONLY", but I'm >>> not 100% sure about how that works.) >>> >>> Rachel >>> >>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>> Hello, >>>> Please review another Unified Logging conversion. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>> >>>> TraceMonitorMismatch has been converted to unified logging with >>>> monitormismatch tag and info level. There is very little output. To >>>> trigger the output, I ran a program which does a monitorenter >>>> without a monitorexit. >>>> >>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' >>>> >>>> Tested with jtreg runtime tests and added MonitorMismatchTest.java >>>> to test for the output. The test body doesn't run on embedded since >>>> it uses TieredCompilation. >>>> >>>> If you search for TraceMonitorMismatch in the new source, you will >>>> find a bunch of instances in >>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>> This file is a java implementation of GenerateOopMap.cpp and the >>>> two files aren't tied together in any way. This java level >>>> TraceMonitorMismatch flag is set to true in the code and doesn't >>>> get its value from the jvm level TraceMonitorMismatch flag. I have >>>> left these alone as another unfortunate naming coincidence. >>>> >>>> Thanks, >>>> Max >>> >> > From daniel.daugherty at oracle.com Mon Mar 28 23:19:02 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Mar 2016 17:19:02 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F46331.6050006@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> Message-ID: <56F9BBE6.10207@oracle.com> On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: > On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did >> in c1_LIRAssembler_x86.cpp > > I'll take a look. I may leave that cleanup to another pass, if > you would be OK with it... I'm nearing the end of my 72 hour > stress test cycle and don't want to repeat it... :-) Here's the C1 change: $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 2016 -0800 +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 2016 -0700 @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { Register OSR_buf = osrBufferPointer()->as_pointer_register(); { assert(frame::interpreter_frame_monitor_size() == BasicObjectLock::size(), "adjust code below"); int monitor_offset = BytesPerWord * method()->max_locals() + - (2 * BytesPerWord) * (number_of_locks - 1); + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - 1); // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in // the OSR buffer using 2 word entries: first the lock and then // the oop. Here's the existing code in SharedRuntime::OSR_migration_begin(): // Allocate temp buffer, 1 word per local & 2 per active monitor int buf_size_words = max_locals + active_monitor_count * (sizeof(BasicObjectLock) / wordSize); intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); so is your suggestion to change: sizeof(BasicObjectLock) / wordSize to: BasicObjectLock::size() or am I misunderstanding what you mean? Dan From ioi.lam at oracle.com Mon Mar 28 23:43:45 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 28 Mar 2016 16:43:45 -0700 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: References: <56F5A3E4.4090607@oracle.com> Message-ID: <56F9C1B1.2080201@oracle.com> Looks good. Thanks! - Ioi On 3/28/16 12:13 PM, Gerard Ziemski wrote: > hi Ioi, > > Thank you for there review. > > I have factored out the common code as you suggested and I like it now much better. > > Updated webrev at http://cr.openjdk.java.net/~gziemski/8143958_rev2 > > > cheers > >> On Mar 25, 2016, at 3:47 PM, Ioi Lam wrote: >> >> Hi Gerard, >> >> This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: >> >> 136 if (value > max) { >> 137 CommandLineError::print(verbose, >> 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " >> 139 "smaller than (" SIZE_FORMAT ")\n", >> 140 value, max); >> 141 return Flag::VIOLATES_CONSTRAINT; >> 142 } else { >> 143 return Flag::SUCCESS; >> 144 } >> >> >> Should that be wrapped in a helper function like this? >> >> return CommandLineError::check_max(value, max, "SharedReadWriteSize"); >> >> Thanks >> - Ioi >> >> On 3/25/16 9:26 AM, Gerard Ziemski wrote: >>> hi all, >>> >>> Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143958 >>> http://cr.openjdk.java.net/~gziemski/8143958_rev1 >>> >>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. >>> From robbin.ehn at oracle.com Tue Mar 29 07:22:37 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 29 Mar 2016 09:22:37 +0200 Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4) In-Reply-To: <67967227-F576-42EB-B122-9EB76A61A512@oracle.com> References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com> <56F29F19.9030409@oracle.com> <67967227-F576-42EB-B122-9EB76A61A512@oracle.com> Message-ID: <56FA2D3D.4050505@oracle.com> Thanks Kim! /Robbin On 03/24/2016 09:14 PM, Kim Barrett wrote: >> On Mar 23, 2016, at 9:50 AM, Robbin Ehn wrote: >> >> Hi all, >> >> After more input, this is the current version. >> Please have a look. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/ >> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/ > > This looks good. > From yasuenag at gmail.com Tue Mar 29 14:43:29 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 29 Mar 2016 23:43:29 +0900 Subject: UL: Two enhancement proposal for UL Message-ID: <56FA9491.60103@gmail.com> Hi all, I want to propose two enhancement for UL. 1. Set filesize option with k/m/g I want to set filesize option with k/m/g: -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m Implementation sample: http://cr.openjdk.java.net/~ysuenaga/ul/set-filesize-option/ 2. Show output option in VM.log jcmd 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, Implementation sample: http://cr.openjdk.java.net/~ysuenaga/ul/show-output-options/ I want to file them to JBS and to upload webrev. Are they accepted? Thanks, Yasumasa From varming at gmail.com Tue Mar 29 15:56:15 2016 From: varming at gmail.com (Carsten Varming) Date: Tue, 29 Mar 2016 11:56:15 -0400 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F9BBE6.10207@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> Message-ID: Dear Dan, Generally a very nice clean-up, but I have a few questions. Quick question: Is it time to remove all those unused perf variables: _sync_EmptyNotifications, _sync_Notifications, _sync_SlowEnter, _sync_SlowExit, _sync_SlowNotify, _sync_SlowNotifyAll, _sync_FailedSpins, _sync_SuccessfulSpins, _sync_PrivateA, _sync_PrivateB, _sync_MonInCirculation, and _sync_MonScavenged. synchronizer.cpp:290 you mention that the monitor is either being inflated or has already been inflated, but mark->has_monitor() returns false if the monitor is being inflated, and this fact is important for the assert in line 292 as it would otherwise dereference a NULL pointer. BTW., should the if-clause, down to above the return, for the recursive case in fast_exit be removed in the product build? It looks like a few dead loads of volatile values to me. There is a comment in synchronizer.cpp:1419 that mentions that it is safe to read the displaced mark word of a lock as the thread exiting the lock will wait for the object mark word to be different from INFLATING. I don't see fast_exit waiting for the mark word to be different from INFLATING in the recursive case, so could the mark->displaced_mark_helper() in line 1423 be reading an arbitrary value on the stack of the thread holding the lock? Is this a bug? I don't understand the comment "Is recursive stack-lock" in synchronizer.cpp:303. The recursive case was handled above and ended with a return. This should be the non-recursive case. I also don't understand how it can be safe to install the old displaced mark word read at the top of the method as a different thread could have installed a hashCode into the displaced mark word between the read and the CAS into the object mark word. Could this gap drop the hashCode, i.e., the value of the java method void Object.hashCode() could change for the object? Carsten On Mon, Mar 28, 2016 at 7:19 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: > >> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >> >>> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did in >>> c1_LIRAssembler_x86.cpp >>> >> >> I'll take a look. I may leave that cleanup to another pass, if >> you would be OK with it... I'm nearing the end of my 72 hour >> stress test cycle and don't want to repeat it... :-) >> > > Here's the C1 change: > > $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 2016 > -0800 > +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 2016 > -0700 > @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { > Register OSR_buf = osrBufferPointer()->as_pointer_register(); > { assert(frame::interpreter_frame_monitor_size() == > BasicObjectLock::size(), "adjust code below"); > int monitor_offset = BytesPerWord * method()->max_locals() + > - (2 * BytesPerWord) * (number_of_locks - 1); > + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - 1); > // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in > // the OSR buffer using 2 word entries: first the lock and then > // the oop. > > > Here's the existing code in SharedRuntime::OSR_migration_begin(): > > // Allocate temp buffer, 1 word per local & 2 per active monitor > int buf_size_words = max_locals + active_monitor_count * > (sizeof(BasicObjectLock) / wordSize); > intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); > > > so is your suggestion to change: > > sizeof(BasicObjectLock) / wordSize > > to: > > BasicObjectLock::size() > > or am I misunderstanding what you mean? > > Dan > > From gerard.ziemski at oracle.com Tue Mar 29 15:56:48 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 29 Mar 2016 10:56:48 -0500 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: <56F9C1B1.2080201@oracle.com> References: <56F5A3E4.4090607@oracle.com> <56F9C1B1.2080201@oracle.com> Message-ID: <044D2159-6464-4DB2-BF60-6838D3ADFD33@oracle.com> Thank you for the review! cheers > On Mar 28, 2016, at 6:43 PM, Ioi Lam wrote: > > Looks good. Thanks! > - Ioi > > On 3/28/16 12:13 PM, Gerard Ziemski wrote: >> hi Ioi, >> >> Thank you for there review. >> >> I have factored out the common code as you suggested and I like it now much better. >> >> Updated webrev at http://cr.openjdk.java.net/~gziemski/8143958_rev2 >> >> >> cheers >> >>> On Mar 25, 2016, at 3:47 PM, Ioi Lam wrote: >>> >>> Hi Gerard, >>> >>> This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: >>> >>> 136 if (value > max) { >>> 137 CommandLineError::print(verbose, >>> 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " >>> 139 "smaller than (" SIZE_FORMAT ")\n", >>> 140 value, max); >>> 141 return Flag::VIOLATES_CONSTRAINT; >>> 142 } else { >>> 143 return Flag::SUCCESS; >>> 144 } >>> >>> >>> Should that be wrapped in a helper function like this? >>> >>> return CommandLineError::check_max(value, max, "SharedReadWriteSize"); >>> >>> Thanks >>> - Ioi >>> >>> On 3/25/16 9:26 AM, Gerard Ziemski wrote: >>>> hi all, >>>> >>>> Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8143958 >>>> http://cr.openjdk.java.net/~gziemski/8143958_rev1 >>>> >>>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. >>>> > From varming at gmail.com Tue Mar 29 16:05:37 2016 From: varming at gmail.com (Carsten Varming) Date: Tue, 29 Mar 2016 12:05:37 -0400 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> Message-ID: Dear Dan, Re my last comment about a potential race between FastHashCode and fast_exit. Never mind, I just noticed that FastHashCode will inflate the lock to monitor before installing a hash code. Carsten On Tue, Mar 29, 2016 at 11:56 AM, Carsten Varming wrote: > Dear Dan, > > Generally a very nice clean-up, but I have a few questions. > > Quick question: Is it time to remove all those unused perf > variables: _sync_EmptyNotifications, _sync_Notifications, _sync_SlowEnter, _sync_SlowExit, _sync_SlowNotify, _sync_SlowNotifyAll, _sync_FailedSpins, _sync_SuccessfulSpins, _sync_PrivateA, _sync_PrivateB, _sync_MonInCirculation, > and _sync_MonScavenged. > > synchronizer.cpp:290 you mention that the monitor is either being inflated > or has already been inflated, but mark->has_monitor() returns false if the > monitor is being inflated, and this fact is important for the assert in > line 292 as it would otherwise dereference a NULL pointer. BTW., should the > if-clause, down to above the return, for the recursive case in fast_exit be > removed in the product build? It looks like a few dead loads of volatile > values to me. > > There is a comment in synchronizer.cpp:1419 that mentions that it is safe > to read the displaced mark word of a lock as the thread exiting the lock > will wait for the object mark word to be different from INFLATING. I don't > see fast_exit waiting for the mark word to be different from INFLATING in > the recursive case, so could the mark->displaced_mark_helper() in line 1423 > be reading an arbitrary value on the stack of the thread holding the lock? > Is this a bug? > > I don't understand the comment "Is recursive stack-lock" in > synchronizer.cpp:303. The recursive case was handled above and ended with a > return. This should be the non-recursive case. I also don't understand how > it can be safe to install the old displaced mark word read at the top of > the method as a different thread could have installed a hashCode into the > displaced mark word between the read and the CAS into the object mark word. > Could this gap drop the hashCode, i.e., the value of the java method void > Object.hashCode() could change for the object? > > Carsten > > On Mon, Mar 28, 2016 at 7:19 PM, Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: >> >>> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >>> >>>> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did >>>> in c1_LIRAssembler_x86.cpp >>>> >>> >>> I'll take a look. I may leave that cleanup to another pass, if >>> you would be OK with it... I'm nearing the end of my 72 hour >>> stress test cycle and don't want to repeat it... :-) >>> >> >> Here's the C1 change: >> >> $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 2016 >> -0800 >> +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 2016 >> -0700 >> @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { >> Register OSR_buf = osrBufferPointer()->as_pointer_register(); >> { assert(frame::interpreter_frame_monitor_size() == >> BasicObjectLock::size(), "adjust code below"); >> int monitor_offset = BytesPerWord * method()->max_locals() + >> - (2 * BytesPerWord) * (number_of_locks - 1); >> + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - 1); >> // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in >> // the OSR buffer using 2 word entries: first the lock and then >> // the oop. >> >> >> Here's the existing code in SharedRuntime::OSR_migration_begin(): >> >> // Allocate temp buffer, 1 word per local & 2 per active monitor >> int buf_size_words = max_locals + active_monitor_count * >> (sizeof(BasicObjectLock) / wordSize); >> intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); >> >> >> so is your suggestion to change: >> >> sizeof(BasicObjectLock) / wordSize >> >> to: >> >> BasicObjectLock::size() >> >> or am I misunderstanding what you mean? >> >> Dan >> >> > From claes.redestad at oracle.com Tue Mar 29 16:07:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 29 Mar 2016 18:07:29 +0200 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> Message-ID: <56FAA841.8080707@oracle.com> Hi, On 2016-03-29 17:56, Carsten Varming wrote: > Quick question: Is it time to remove all those unused perf > variables: _sync_EmptyNotifications, _sync_Notifications, > _sync_SlowEnter, _sync_SlowExit, _sync_SlowNotify, > _sync_SlowNotifyAll, _sync_FailedSpins, _sync_SuccessfulSpins, > _sync_PrivateA, _sync_PrivateB, _sync_MonInCirculation, > and _sync_MonScavenged. there's already an RFE for that: https://bugs.openjdk.java.net/browse/JDK-8068593 Seems I didn't put _sync_Notifications on the list, maybe just an oversight, or it was actually used at the time. /Claes From varming at gmail.com Tue Mar 29 16:25:23 2016 From: varming at gmail.com (Carsten Varming) Date: Tue, 29 Mar 2016 12:25:23 -0400 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56FAA841.8080707@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> <56FAA841.8080707@oracle.com> Message-ID: Dear Dan, I think I figured out why what the comment " The owner can't die or unwind past the lock while our INFLATING object is in the mark" means. The displaced mark word is in the first lock on the stack of the thread owning the lock. That mean the only case to worry about the the non-recursive exit which is handled by a call to inflate as INFLATING is different from the pointer to the lock. It would be nice with a comment explaining why the recursive exit does not need to wait, i.e., the object mark word always points to the first lock on the stack of the thread currently owning the lock. Anyway, the clean-up looks good. Carsten On Tue, Mar 29, 2016 at 12:07 PM, Claes Redestad wrote: > Hi, > > On 2016-03-29 17:56, Carsten Varming wrote: > >> Quick question: Is it time to remove all those unused perf >> variables: _sync_EmptyNotifications, _sync_Notifications, >> _sync_SlowEnter, _sync_SlowExit, _sync_SlowNotify, >> _sync_SlowNotifyAll, _sync_FailedSpins, _sync_SuccessfulSpins, >> _sync_PrivateA, _sync_PrivateB, _sync_MonInCirculation, >> and _sync_MonScavenged. >> > > there's already an RFE for that: > https://bugs.openjdk.java.net/browse/JDK-8068593 > > Seems I didn't put _sync_Notifications on the list, maybe just an > oversight, or it was > actually used at the time. > > /Claes > From max.ockner at oracle.com Tue Mar 29 16:56:22 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 29 Mar 2016 12:56:22 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56F9A685.4040407@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> <56F990E2.7080204@oracle.com> <56F9A685.4040407@oracle.com> Message-ID: <56FAB3B6.6060905@oracle.com> Fixed: http://cr.openjdk.java.net/~mockner/8150084.04/ Thanks, Max On 3/28/2016 5:47 PM, Coleen Phillimore wrote: > > MonitorMismatchHelper.java needs a copyright notice. > Coleen > > On 3/28/16 4:15 PM, Max Ockner wrote: >> Thanks for round 1 of reviews. >> >> webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ >> - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in >> webrev. >> - Fixed improper spacing in test. >> >> Thanks, >> Max >> On 3/28/2016 3:52 PM, Coleen Phillimore wrote: >>> >>> It looks like A.jasm is missing from your webrev and can you name it >>> something more useful like MonitorMismatchHelper.java ? >>> Otherwise, code looks good. >>> thanks, >>> Coleen >>> >>> On 3/28/16 3:10 PM, Max Ockner wrote: >>>> Good catch. We don't intend for this to be DEBUG_ONLY. The "#ifndef >>>> PRODUCT" has been removed. >>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >>>> >>>> If we put the log_is_enabled conditional inside the function then >>>> we will always branch to the function. The conversion of >>>> TraceClassResolution required a similar decision, and we chose to >>>> leave the log_is_enabled condition outside of the >>>> trace_class_resolution() function. >>>> >>>> Thanks, >>>> Max >>>> >>>> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>>>> Hey, Max, >>>>> >>>>> The code looks fine as-is, but perhaps could be optimized? Since >>>>> all the uses of monitormismatch call report_monitor_mismatch(), >>>>> which has its code in non-product only, you could remove the >>>>> conditionals around it and have the function declared with >>>>> "PRODUCT_RETURN." Then, inside the function you could put the "if >>>>> log_is_enabled". So there will be less compiled code in product >>>>> mode. (This might also mean you could make the monitormismatch tag >>>>> "DEBUG_ONLY", but I'm not 100% sure about how that works.) >>>>> >>>>> Rachel >>>>> >>>>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>>>> Hello, >>>>>> Please review another Unified Logging conversion. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>>>> >>>>>> TraceMonitorMismatch has been converted to unified logging with >>>>>> monitormismatch tag and info level. There is very little output. >>>>>> To trigger the output, I ran a program which does a monitorenter >>>>>> without a monitorexit. >>>>>> >>>>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch ' >>>>>> >>>>>> Tested with jtreg runtime tests and added >>>>>> MonitorMismatchTest.java to test for the output. The test body >>>>>> doesn't run on embedded since it uses TieredCompilation. >>>>>> >>>>>> If you search for TraceMonitorMismatch in the new source, you >>>>>> will find a bunch of instances in >>>>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>>>> This file is a java implementation of GenerateOopMap.cpp and the >>>>>> two files aren't tied together in any way. This java level >>>>>> TraceMonitorMismatch flag is set to true in the code and doesn't >>>>>> get its value from the jvm level TraceMonitorMismatch flag. I >>>>>> have left these alone as another unfortunate naming coincidence. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Mar 29 17:01:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 29 Mar 2016 13:01:19 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56FAB3B6.6060905@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> <56F990E2.7080204@oracle.com> <56F9A685.4040407@oracle.com> <56FAB3B6.6060905@oracle.com> Message-ID: <56FAB4DF.5000709@oracle.com> This looks good - but one last question (sorry for incremental comments). http://cr.openjdk.java.net/~mockner/8150084.04/test/runtime/logging/MonitorMismatchTest.java.html Does this need any @modules things? Thanks, Coleen On 3/29/16 12:56 PM, Max Ockner wrote: > Fixed: http://cr.openjdk.java.net/~mockner/8150084.04/ > > Thanks, > Max > On 3/28/2016 5:47 PM, Coleen Phillimore wrote: >> >> MonitorMismatchHelper.java needs a copyright notice. >> Coleen >> >> On 3/28/16 4:15 PM, Max Ockner wrote: >>> Thanks for round 1 of reviews. >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ >>> - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in >>> webrev. >>> - Fixed improper spacing in test. >>> >>> Thanks, >>> Max >>> On 3/28/2016 3:52 PM, Coleen Phillimore wrote: >>>> >>>> It looks like A.jasm is missing from your webrev and can you name >>>> it something more useful like MonitorMismatchHelper.java ? >>>> Otherwise, code looks good. >>>> thanks, >>>> Coleen >>>> >>>> On 3/28/16 3:10 PM, Max Ockner wrote: >>>>> Good catch. We don't intend for this to be DEBUG_ONLY. The >>>>> "#ifndef PRODUCT" has been removed. >>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >>>>> >>>>> If we put the log_is_enabled conditional inside the function then >>>>> we will always branch to the function. The conversion of >>>>> TraceClassResolution required a similar decision, and we chose to >>>>> leave the log_is_enabled condition outside of the >>>>> trace_class_resolution() function. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>>>>> Hey, Max, >>>>>> >>>>>> The code looks fine as-is, but perhaps could be optimized? Since >>>>>> all the uses of monitormismatch call report_monitor_mismatch(), >>>>>> which has its code in non-product only, you could remove the >>>>>> conditionals around it and have the function declared with >>>>>> "PRODUCT_RETURN." Then, inside the function you could put the "if >>>>>> log_is_enabled". So there will be less compiled code in product >>>>>> mode. (This might also mean you could make the monitormismatch >>>>>> tag "DEBUG_ONLY", but I'm not 100% sure about how that works.) >>>>>> >>>>>> Rachel >>>>>> >>>>>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>>>>> Hello, >>>>>>> Please review another Unified Logging conversion. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>>>>> >>>>>>> TraceMonitorMismatch has been converted to unified logging with >>>>>>> monitormismatch tag and info level. There is very little output. >>>>>>> To trigger the output, I ran a program which does a monitorenter >>>>>>> without a monitorexit. >>>>>>> >>>>>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch >>>>>>> ' >>>>>>> >>>>>>> Tested with jtreg runtime tests and added >>>>>>> MonitorMismatchTest.java to test for the output. The test body >>>>>>> doesn't run on embedded since it uses TieredCompilation. >>>>>>> >>>>>>> If you search for TraceMonitorMismatch in the new source, you >>>>>>> will find a bunch of instances in >>>>>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>>>>> This file is a java implementation of GenerateOopMap.cpp and the >>>>>>> two files aren't tied together in any way. This java level >>>>>>> TraceMonitorMismatch flag is set to true in the code and doesn't >>>>>>> get its value from the jvm level TraceMonitorMismatch flag. I >>>>>>> have left these alone as another unfortunate naming coincidence. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>> >>>>> >>>> >>> >> > From max.ockner at oracle.com Tue Mar 29 17:04:24 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 29 Mar 2016 13:04:24 -0400 Subject: RFR: 8149996: TraceLoaderConstraints has been converted to Unified Logging. In-Reply-To: <56F97F99.70805@oracle.com> References: <56E08BE4.7000904@oracle.com> <56E09DA9.4040504@oracle.com> <56E0F836.70301@oracle.com> <56E8237D.8070908@oracle.com> <56E8F909.9060705@oracle.com> <56E97513.40902@oracle.com> <56E9CB8E.6000109@oracle.com> <56F965D8.2090600@oracle.com> <56F97F99.70805@oracle.com> Message-ID: <56FAB598.4010407@oracle.com> OK I will submit this now. Thanks everybody. On 3/28/2016 3:01 PM, Coleen Phillimore wrote: > Max, > This looks good! > Thanks, > Coleen > > On 3/28/16 1:11 PM, Max Ockner wrote: >> Hey everyone. Patching this into a jake repo was difficult as there >> were other dependencies that had not yet been pulled into jake. As a >> result, I tabled this until jigsaw integration. >> >> New webrev: http://cr.openjdk.java.net/~mockner/8149996.06/ >> - Updated the test to check for new paths. >> >> Tested with jtreg runtime. >> >> Thanks, >> Max >> >> On 3/16/2016 5:09 PM, David Holmes wrote: >>> Follow ups below ... >>> >>> On 17/03/2016 1:00 AM, Max Ockner wrote: >>>> Comments below. >>>> >>>> On 3/16/2016 2:11 AM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> tl;dr: you can push this as-is (modulo fixing copyright years) but I >>>>> have some further queries/discussion points below. :) >>>>> >>>>> Meta question: should we consider using "classload, constraints" >>>>> instead of "loaderconstraints" ? >>>>> >>>> I think this would be appropriate. >>> >>> Ok. >>> >>>>> On 16/03/2016 1:00 AM, Max Ockner wrote: >>>>>> Hello again, >>>>>> >>>>>> new webrev: http://cr.openjdk.java.net/~mockner/8149996.05/ >>>>>> - added resource marks back in >>>>>> - reverted to using outputStreams instead of log_info macro >>>>>> >>>>>> I ran into an issue with the outputStream eating its output when I >>>>>> removed " ]\n" from the end of some of the messages, solved by >>>>>> changing >>>>>> "out->print" to "out->print_cr". >>>>> >>>>> Aside: it is actually more efficient to have the \n in the string >>>>> than >>>>> to use the print_cr form. :) >>>>> >>>> Thanks for pointing this out. I can change it. >>> >>> It was just an observation - we don't pay this much attention >>> elsewhere. >>> >>>>> Nit: is there a reason to remove the initial capitals from the log >>>>> messages? I find the capitals are a visual aid when trying to find >>>>> the >>>>> end of the decorators. >>>>> >>>>> Aside 2: I notice we have now removed the only example of a >>>>> product_rw >>>>> flag. I wonder if we should rip out product_rw support? (Separate RFE >>>>> of course). I'm also wondering if our logging flags are >>>>> visible/modifiable via the management tools like >>>>> manageable/product_rw >>>>> flags are? >>>>> >>>> From an email discussion with Marcus: >>>> "There is a DCMD to reconfigure logging during runtime. It's all baked >>>> into a single command called VM.log and it works similar to the -Xlog >>>> command, but all of the parameters are named, so -Xlog:gc:gclog.txt >>>> would be VM.log output=gclog.txt what=gc." >>> >>> Thanks. >>> >>>>> With regard to the test I'm not sure those "loaders" are going to >>>>> continue to be valid once Jake has integrated. So you might want to >>>>> try this on a Jake build before finalising it. >>>>> >>>> >>>> Do you think this is important to test before submitting? >>> >>> It might stop working next week so yes I think it worth checking >>> this now. >>> >>> Thanks, >>> David >>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I thought about writing a log_info_rm which evaluates to a code >>>>>> block >>>>>> instead of a function, but I think one of the benefits of the >>>>>> current >>>>>> macros is that they allow two variable argument lists in the same >>>>>> expression. Returning a write function is important for handling the >>>>>> format string and its variable length argument list of format >>>>>> %substitutions. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>> On 3/9/2016 11:29 PM, David Holmes wrote: >>>>>>> On 10/03/2016 8:03 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mockner/8149996.02/src/share/vm/classfile/loaderConstraints.cpp.frames.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why did you take out the ResourceMarks at line 130, 160, 231 >>>>>>>> and 244, >>>>>>>> 297, 308 and 357? >>>>>>> >>>>>>> Yes these should all be of the form: >>>>>>> >>>>>>> if (log_is_enabled(...)) { >>>>>>> ResourceMark rm; >>>>>>> // log stuff >>>>>>> } >>>>>>> >>>>>>>> Unfortunately, we really need log_info_rm(tag)("String") call >>>>>>>> because >>>>>>>> all those places need a ResourceMark. >>>>>>>> >>>>>>>> Anytime we call name()->as_C_string() there needs to be a >>>>>>>> ResourceMark >>>>>>>> in the scope of the call. >>>>>>> >>>>>>> Which means that a log_info_rm() call wouldn't help because we'd >>>>>>> still >>>>>>> be calling as_C_string in the caller. :( >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 3/9/16 3:47 PM, Max Ockner wrote: >>>>>>>>> Hello again, >>>>>>>>> >>>>>>>>> Please review this change. TraceLoaderConstraints has been >>>>>>>>> converted >>>>>>>>> to Unified Logging and can be accessed using >>>>>>>>> '-Xlog:loaderconstraints=info'. TraceLoaderConstraints has >>>>>>>>> been added >>>>>>>>> to the logging alias table. >>>>>>>>> >>>>>>>>> There are 0 lines of output for java -version, and ~10 lines from >>>>>>>>> LoaderConstraintsTest.java >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8149996 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8149996.02/ >>>>>>>>> >>>>>>>>> Testing: jtreg runtime. Added new test which triggers logging for >>>>>>>>> loaderconstraints by forcing class unloading. No other >>>>>>>>> references to >>>>>>>>> TraceLoaderConstraints found in hotspot/test, jdk/test , or in >>>>>>>>> the >>>>>>>>> noncolo tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>> >>>>>> >>>> >> > From jiangli.zhou at oracle.com Tue Mar 29 17:07:30 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 29 Mar 2016 10:07:30 -0700 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: References: <56F5A3E4.4090607@oracle.com> Message-ID: Hi Gerard, Looks good. Thanks, Jiangli > On Mar 28, 2016, at 12:13 PM, Gerard Ziemski wrote: > > hi Ioi, > > Thank you for there review. > > I have factored out the common code as you suggested and I like it now much better. > > Updated webrev at http://cr.openjdk.java.net/~gziemski/8143958_rev2 > > > cheers > >>> >> On Mar 25, 2016, at 3:47 PM, Ioi Lam wrote: >> >> Hi Gerard, >> >> This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: >> >> 136 if (value > max) { >> 137 CommandLineError::print(verbose, >> 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " >> 139 "smaller than (" SIZE_FORMAT ")\n", >> 140 value, max); >> 141 return Flag::VIOLATES_CONSTRAINT; >> 142 } else { >> 143 return Flag::SUCCESS; >> 144 } >> >> >> Should that be wrapped in a helper function like this? >> >> return CommandLineError::check_max(value, max, "SharedReadWriteSize"); >> >> Thanks >> - Ioi >> >> On 3/25/16 9:26 AM, Gerard Ziemski wrote: >>> hi all, >>> >>> Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143958 >>> http://cr.openjdk.java.net/~gziemski/8143958_rev1 >>> >>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. >>> >> > From ron.durbin at oracle.com Tue Mar 29 17:57:57 2016 From: ron.durbin at oracle.com (Ron Durbin) Date: Tue, 29 Mar 2016 10:57:57 -0700 (PDT) Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> Message-ID: <803ade70-bdcd-4027-9622-48a7cf56d954@default> Gerard, I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. I have not seen this failure of the min test on windows. I would like to understand why this change is needed. Ron >-----Original Message----- >From: Gerard Ziemski >Sent: Friday, March 25, 2016 10:27 AM >To: hotspot-runtime-dev at openjdk.java.net >Subject: RFR (S): 8136766: Enable ThreadStackSize range test > >hi all, > >Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >Windows) and adds constraint for ThreadStackSize, which allows us to include it in >test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. > >https://bugs.openjdk.java.net/browse/JDK-8136766 >http://cr.openjdk.java.net/~gziemski/8136766_rev1 > >Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From max.ockner at oracle.com Tue Mar 29 18:13:26 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 29 Mar 2016 14:13:26 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56FAB4DF.5000709@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> <56F990E2.7080204@oracle.com> <56F9A685.4040407@oracle.com> <56FAB3B6.6060905@oracle.com> <56FAB4DF.5000709@oracle.com> Message-ID: <56FAC5C6.3050304@oracle.com> This does not need @modules. According to Harold, if the test passes without @modules, then it doesn't need @modules. Max On 3/29/2016 1:01 PM, Coleen Phillimore wrote: > > This looks good - but one last question (sorry for incremental comments). > > http://cr.openjdk.java.net/~mockner/8150084.04/test/runtime/logging/MonitorMismatchTest.java.html > > > Does this need any @modules things? > > Thanks, > Coleen > > On 3/29/16 12:56 PM, Max Ockner wrote: >> Fixed: http://cr.openjdk.java.net/~mockner/8150084.04/ >> >> Thanks, >> Max >> On 3/28/2016 5:47 PM, Coleen Phillimore wrote: >>> >>> MonitorMismatchHelper.java needs a copyright notice. >>> Coleen >>> >>> On 3/28/16 4:15 PM, Max Ockner wrote: >>>> Thanks for round 1 of reviews. >>>> >>>> webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ >>>> - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in >>>> webrev. >>>> - Fixed improper spacing in test. >>>> >>>> Thanks, >>>> Max >>>> On 3/28/2016 3:52 PM, Coleen Phillimore wrote: >>>>> >>>>> It looks like A.jasm is missing from your webrev and can you name >>>>> it something more useful like MonitorMismatchHelper.java ? >>>>> Otherwise, code looks good. >>>>> thanks, >>>>> Coleen >>>>> >>>>> On 3/28/16 3:10 PM, Max Ockner wrote: >>>>>> Good catch. We don't intend for this to be DEBUG_ONLY. The >>>>>> "#ifndef PRODUCT" has been removed. >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >>>>>> >>>>>> If we put the log_is_enabled conditional inside the function then >>>>>> we will always branch to the function. The conversion of >>>>>> TraceClassResolution required a similar decision, and we chose to >>>>>> leave the log_is_enabled condition outside of the >>>>>> trace_class_resolution() function. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>>>>>> Hey, Max, >>>>>>> >>>>>>> The code looks fine as-is, but perhaps could be optimized? Since >>>>>>> all the uses of monitormismatch call report_monitor_mismatch(), >>>>>>> which has its code in non-product only, you could remove the >>>>>>> conditionals around it and have the function declared with >>>>>>> "PRODUCT_RETURN." Then, inside the function you could put the >>>>>>> "if log_is_enabled". So there will be less compiled code in >>>>>>> product mode. (This might also mean you could make the >>>>>>> monitormismatch tag "DEBUG_ONLY", but I'm not 100% sure about >>>>>>> how that works.) >>>>>>> >>>>>>> Rachel >>>>>>> >>>>>>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> Please review another Unified Logging conversion. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>>>>>> >>>>>>>> TraceMonitorMismatch has been converted to unified logging with >>>>>>>> monitormismatch tag and info level. There is very little >>>>>>>> output. To trigger the output, I ran a program which does a >>>>>>>> monitorenter without a monitorexit. >>>>>>>> >>>>>>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch >>>>>>>> ' >>>>>>>> >>>>>>>> Tested with jtreg runtime tests and added >>>>>>>> MonitorMismatchTest.java to test for the output. The test body >>>>>>>> doesn't run on embedded since it uses TieredCompilation. >>>>>>>> >>>>>>>> If you search for TraceMonitorMismatch in the new source, you >>>>>>>> will find a bunch of instances in >>>>>>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>>>>>> This file is a java implementation of GenerateOopMap.cpp and >>>>>>>> the two files aren't tied together in any way. This java level >>>>>>>> TraceMonitorMismatch flag is set to true in the code and >>>>>>>> doesn't get its value from the jvm level TraceMonitorMismatch >>>>>>>> flag. I have left these alone as another unfortunate naming >>>>>>>> coincidence. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Mar 29 18:25:46 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 29 Mar 2016 14:25:46 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56FAC5C6.3050304@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> <56F990E2.7080204@oracle.com> <56F9A685.4040407@oracle.com> <56FAB3B6.6060905@oracle.com> <56FAB4DF.5000709@oracle.com> <56FAC5C6.3050304@oracle.com> Message-ID: <56FAC8AA.60200@oracle.com> Thumbs up! Thanks for checking Coleen On 3/29/16 2:13 PM, Max Ockner wrote: > This does not need @modules. According to Harold, if the test passes > without @modules, then it doesn't need @modules. > Max > > On 3/29/2016 1:01 PM, Coleen Phillimore wrote: >> >> This looks good - but one last question (sorry for incremental >> comments). >> >> http://cr.openjdk.java.net/~mockner/8150084.04/test/runtime/logging/MonitorMismatchTest.java.html >> >> >> Does this need any @modules things? >> >> Thanks, >> Coleen >> >> On 3/29/16 12:56 PM, Max Ockner wrote: >>> Fixed: http://cr.openjdk.java.net/~mockner/8150084.04/ >>> >>> Thanks, >>> Max >>> On 3/28/2016 5:47 PM, Coleen Phillimore wrote: >>>> >>>> MonitorMismatchHelper.java needs a copyright notice. >>>> Coleen >>>> >>>> On 3/28/16 4:15 PM, Max Ockner wrote: >>>>> Thanks for round 1 of reviews. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ >>>>> - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in >>>>> webrev. >>>>> - Fixed improper spacing in test. >>>>> >>>>> Thanks, >>>>> Max >>>>> On 3/28/2016 3:52 PM, Coleen Phillimore wrote: >>>>>> >>>>>> It looks like A.jasm is missing from your webrev and can you name >>>>>> it something more useful like MonitorMismatchHelper.java ? >>>>>> Otherwise, code looks good. >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>> On 3/28/16 3:10 PM, Max Ockner wrote: >>>>>>> Good catch. We don't intend for this to be DEBUG_ONLY. The >>>>>>> "#ifndef PRODUCT" has been removed. >>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >>>>>>> >>>>>>> If we put the log_is_enabled conditional inside the function >>>>>>> then we will always branch to the function. The conversion of >>>>>>> TraceClassResolution required a similar decision, and we chose >>>>>>> to leave the log_is_enabled condition outside of the >>>>>>> trace_class_resolution() function. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>>>>>>> Hey, Max, >>>>>>>> >>>>>>>> The code looks fine as-is, but perhaps could be optimized? >>>>>>>> Since all the uses of monitormismatch call >>>>>>>> report_monitor_mismatch(), which has its code in non-product >>>>>>>> only, you could remove the conditionals around it and have the >>>>>>>> function declared with "PRODUCT_RETURN." Then, inside the >>>>>>>> function you could put the "if log_is_enabled". So there will >>>>>>>> be less compiled code in product mode. (This might also mean >>>>>>>> you could make the monitormismatch tag "DEBUG_ONLY", but I'm >>>>>>>> not 100% sure about how that works.) >>>>>>>> >>>>>>>> Rachel >>>>>>>> >>>>>>>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>>>>>>> Hello, >>>>>>>>> Please review another Unified Logging conversion. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>>>>>>> >>>>>>>>> TraceMonitorMismatch has been converted to unified logging >>>>>>>>> with monitormismatch tag and info level. There is very little >>>>>>>>> output. To trigger the output, I ran a program which does a >>>>>>>>> monitorenter without a monitorexit. >>>>>>>>> >>>>>>>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch >>>>>>>>> ' >>>>>>>>> >>>>>>>>> Tested with jtreg runtime tests and added >>>>>>>>> MonitorMismatchTest.java to test for the output. The test body >>>>>>>>> doesn't run on embedded since it uses TieredCompilation. >>>>>>>>> >>>>>>>>> If you search for TraceMonitorMismatch in the new source, you >>>>>>>>> will find a bunch of instances in >>>>>>>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>>>>>>> This file is a java implementation of GenerateOopMap.cpp and >>>>>>>>> the two files aren't tied together in any way. This java >>>>>>>>> level TraceMonitorMismatch flag is set to true in the code and >>>>>>>>> doesn't get its value from the jvm level TraceMonitorMismatch >>>>>>>>> flag. I have left these alone as another unfortunate naming >>>>>>>>> coincidence. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From max.ockner at oracle.com Tue Mar 29 18:29:07 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 29 Mar 2016 14:29:07 -0400 Subject: RFR: 8150084: Convert TraceMonitorMismatch to Unified Logging In-Reply-To: <56FAC8AA.60200@oracle.com> References: <56F5752C.9090201@oracle.com> <56F580E2.8040206@oracle.com> <56F9818B.8070105@oracle.com> <56F98B67.2090309@oracle.com> <56F990E2.7080204@oracle.com> <56F9A685.4040407@oracle.com> <56FAB3B6.6060905@oracle.com> <56FAB4DF.5000709@oracle.com> <56FAC5C6.3050304@oracle.com> <56FAC8AA.60200@oracle.com> Message-ID: <56FAC973.7040505@oracle.com> OK I will submit this now. Thanks! On 3/29/2016 2:25 PM, Coleen Phillimore wrote: > Thumbs up! > Thanks for checking > Coleen > > On 3/29/16 2:13 PM, Max Ockner wrote: >> This does not need @modules. According to Harold, if the test passes >> without @modules, then it doesn't need @modules. >> Max >> >> On 3/29/2016 1:01 PM, Coleen Phillimore wrote: >>> >>> This looks good - but one last question (sorry for incremental >>> comments). >>> >>> http://cr.openjdk.java.net/~mockner/8150084.04/test/runtime/logging/MonitorMismatchTest.java.html >>> >>> >>> Does this need any @modules things? >>> >>> Thanks, >>> Coleen >>> >>> On 3/29/16 12:56 PM, Max Ockner wrote: >>>> Fixed: http://cr.openjdk.java.net/~mockner/8150084.04/ >>>> >>>> Thanks, >>>> Max >>>> On 3/28/2016 5:47 PM, Coleen Phillimore wrote: >>>>> >>>>> MonitorMismatchHelper.java needs a copyright notice. >>>>> Coleen >>>>> >>>>> On 3/28/16 4:15 PM, Max Ockner wrote: >>>>>> Thanks for round 1 of reviews. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8150084.03/ >>>>>> - Renamed A.jasm to MonitorMismatchHelper.jasm and included it in >>>>>> webrev. >>>>>> - Fixed improper spacing in test. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> On 3/28/2016 3:52 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> It looks like A.jasm is missing from your webrev and can you >>>>>>> name it something more useful like MonitorMismatchHelper.java ? >>>>>>> Otherwise, code looks good. >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 3/28/16 3:10 PM, Max Ockner wrote: >>>>>>>> Good catch. We don't intend for this to be DEBUG_ONLY. The >>>>>>>> "#ifndef PRODUCT" has been removed. >>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.02/ >>>>>>>> >>>>>>>> If we put the log_is_enabled conditional inside the function >>>>>>>> then we will always branch to the function. The conversion of >>>>>>>> TraceClassResolution required a similar decision, and we chose >>>>>>>> to leave the log_is_enabled condition outside of the >>>>>>>> trace_class_resolution() function. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 3/25/2016 2:18 PM, Rachel Protacio wrote: >>>>>>>>> Hey, Max, >>>>>>>>> >>>>>>>>> The code looks fine as-is, but perhaps could be optimized? >>>>>>>>> Since all the uses of monitormismatch call >>>>>>>>> report_monitor_mismatch(), which has its code in non-product >>>>>>>>> only, you could remove the conditionals around it and have the >>>>>>>>> function declared with "PRODUCT_RETURN." Then, inside the >>>>>>>>> function you could put the "if log_is_enabled". So there will >>>>>>>>> be less compiled code in product mode. (This might also mean >>>>>>>>> you could make the monitormismatch tag "DEBUG_ONLY", but I'm >>>>>>>>> not 100% sure about how that works.) >>>>>>>>> >>>>>>>>> Rachel >>>>>>>>> >>>>>>>>> On 3/25/2016 1:28 PM, Max Ockner wrote: >>>>>>>>>> Hello, >>>>>>>>>> Please review another Unified Logging conversion. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150084 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8150084.01/ >>>>>>>>>> >>>>>>>>>> TraceMonitorMismatch has been converted to unified logging >>>>>>>>>> with monitormismatch tag and info level. There is very little >>>>>>>>>> output. To trigger the output, I ran a program which does a >>>>>>>>>> monitorenter without a monitorexit. >>>>>>>>>> >>>>>>>>>> 'java -XX:+TieredCompilation -Xcomp -Xlog:monitormismatch >>>>>>>>>> ' >>>>>>>>>> >>>>>>>>>> Tested with jtreg runtime tests and added >>>>>>>>>> MonitorMismatchTest.java to test for the output. The test >>>>>>>>>> body doesn't run on embedded since it uses TieredCompilation. >>>>>>>>>> >>>>>>>>>> If you search for TraceMonitorMismatch in the new source, you >>>>>>>>>> will find a bunch of instances in >>>>>>>>>> jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java. >>>>>>>>>> This file is a java implementation of GenerateOopMap.cpp and >>>>>>>>>> the two files aren't tied together in any way. This java >>>>>>>>>> level TraceMonitorMismatch flag is set to true in the code >>>>>>>>>> and doesn't get its value from the jvm level >>>>>>>>>> TraceMonitorMismatch flag. I have left these alone as another >>>>>>>>>> unfortunate naming coincidence. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From gerard.ziemski at oracle.com Tue Mar 29 18:50:05 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 29 Mar 2016 13:50:05 -0500 Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: <803ade70-bdcd-4027-9622-48a7cf56d954@default> References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> <803ade70-bdcd-4027-9622-48a7cf56d954@default> Message-ID: hi Ron, This change is needed to enable running ThreadStackSize as part of the TestOptionsWithRanges test. ThreadStackSize needed its range implemented in platform dependent way, where on Windows 0 means ?use os defaults? - please see Dan?s comment in the issue for more background. cheers > On Mar 29, 2016, at 12:57 PM, Ron Durbin wrote: > > Gerard, > > I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. > I have not seen this failure of the min test on windows. I would like to understand why this change is > needed. > > Ron > >> -----Original Message----- >> From: Gerard Ziemski >> Sent: Friday, March 25, 2016 10:27 AM >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: RFR (S): 8136766: Enable ThreadStackSize range test >> >> hi all, >> >> Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >> Windows) and adds constraint for ThreadStackSize, which allows us to include it in >> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >> >> https://bugs.openjdk.java.net/browse/JDK-8136766 >> http://cr.openjdk.java.net/~gziemski/8136766_rev1 >> >> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From gerard.ziemski at oracle.com Tue Mar 29 18:50:20 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 29 Mar 2016 13:50:20 -0500 Subject: RFR (S): 8143958: CDS Shared flags need constraint function In-Reply-To: References: <56F5A3E4.4090607@oracle.com> Message-ID: <2F00E155-ED61-4064-933F-250869CAE13B@oracle.com> Thank you for the review! > On Mar 29, 2016, at 12:07 PM, Jiangli Zhou wrote: > > Hi Gerard, > > Looks good. > > Thanks, > Jiangli > >> On Mar 28, 2016, at 12:13 PM, Gerard Ziemski wrote: >> >> hi Ioi, >> >> Thank you for there review. >> >> I have factored out the common code as you suggested and I like it now much better. >> >> Updated webrev at http://cr.openjdk.java.net/~gziemski/8143958_rev2 >> >> >> cheers >> >>>> >>> On Mar 25, 2016, at 3:47 PM, Ioi Lam wrote: >>> >>> Hi Gerard, >>> >>> This looks OK. I have a general comment about commandLineFlagConstraintsRuntime.cpp. There's a lot of boiler-plate code like this: >>> >>> 136 if (value > max) { >>> 137 CommandLineError::print(verbose, >>> 138 "SharedReadWriteSize (" SIZE_FORMAT ") must be " >>> 139 "smaller than (" SIZE_FORMAT ")\n", >>> 140 value, max); >>> 141 return Flag::VIOLATES_CONSTRAINT; >>> 142 } else { >>> 143 return Flag::SUCCESS; >>> 144 } >>> >>> >>> Should that be wrapped in a helper function like this? >>> >>> return CommandLineError::check_max(value, max, "SharedReadWriteSize"); >>> >>> Thanks >>> - Ioi >>> >>> On 3/25/16 9:26 AM, Gerard Ziemski wrote: >>>> hi all, >>>> >>>> Please review this small fix which adds constraints to CDS flags. Please note that the max range value is based on the sum of min values of the other 3 flags, so setting one flag?s value to max while leaving the other 3 flags at their defaults will trigger constraint failure, which test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java accounts for. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8143958 >>>> http://cr.openjdk.java.net/~gziemski/8143958_rev1 >>>> >>>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. >>>> >>> >> > From max.ockner at oracle.com Tue Mar 29 19:00:51 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 29 Mar 2016 15:00:51 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file Message-ID: <56FAD0E3.5090508@oracle.com> Hello, Please review another Unified Logging change. They are almost done, and we are serious this time. bug: https://bugs.openjdk.java.net/browse/JDK-8151526 webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ The logging configuration is now printed in each hs_err file. The output is the same as you would see from -Xlog:logging=trace and it is obtained from LogConfiguration::describe(). Below is a sample of the hs_err contents. The Logging info is printed after VM Arguments and Whitebox, and before Environment Variables. VM Arguments: java_command: Kaboom java_class_path (initial): . Launcher Type: SUN_STANDARD Logging: Available log levels: off, trace, debug, info, warning, error Available log decorators: time (t), uptime (u), timemillis (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid (p), tid (ti), level (l), tags (tg) Available log tags: alloc, age, barrier, biasedlocking, bot, census, classhisto, classresolve, classinit, classload, classloaderdata, classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, liveness, logging, marking, metaspace, modules, monitorinflation, os, phases, plab, promotion, preorder, protectiondomain, ref, refine, region, remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, start, startuptime, state, stats, stringdedup, stringtable, survivor, sweep, task, thread, tlab, time, verboseverification, verify, vmoperation, vtables Log output configuration: #0: stdout all=off uptime,level,tags, #1: stderr all=warning uptime,level,tags, Environment Variables: JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin SHELL=/bin/bash OS=Linux From daniel.daugherty at oracle.com Tue Mar 29 19:10:25 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Mar 2016 13:10:25 -0600 Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> <803ade70-bdcd-4027-9622-48a7cf56d954@default> Message-ID: <56FAD321.8000706@oracle.com> The special treatment of '0' for the various thread stack size options is not limited to Windows. I believe that for all platforms, specifying a value of '0' means use the platform default. This should be true for ThreadStackSize, CompilerThreadStackSize and CompilerThreadStackSize options. Dan On 3/29/16 12:50 PM, Gerard Ziemski wrote: > hi Ron, > > This change is needed to enable running ThreadStackSize as part of the TestOptionsWithRanges test. > > ThreadStackSize needed its range implemented in platform dependent way, where on Windows 0 means ?use os defaults? - please see Dan?s comment in the issue for more background. > > > cheers > >> On Mar 29, 2016, at 12:57 PM, Ron Durbin wrote: >> >> Gerard, >> >> I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. >> I have not seen this failure of the min test on windows. I would like to understand why this change is >> needed. >> >> Ron >> >>> -----Original Message----- >>> From: Gerard Ziemski >>> Sent: Friday, March 25, 2016 10:27 AM >>> To: hotspot-runtime-dev at openjdk.java.net >>> Subject: RFR (S): 8136766: Enable ThreadStackSize range test >>> >>> hi all, >>> >>> Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >>> Windows) and adds constraint for ThreadStackSize, which allows us to include it in >>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8136766 >>> http://cr.openjdk.java.net/~gziemski/8136766_rev1 >>> >>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From gerard.ziemski at oracle.com Tue Mar 29 21:37:09 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 29 Mar 2016 16:37:09 -0500 Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: <56FAD321.8000706@oracle.com> References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> <803ade70-bdcd-4027-9622-48a7cf56d954@default> <56FAD321.8000706@oracle.com> Message-ID: Thank you Dan. You are right and I will have to re-do this. For now I am withdrawing this RFR. cheers > On Mar 29, 2016, at 2:10 PM, Daniel D. Daugherty wrote: > > The special treatment of '0' for the various thread stack size options > is not limited to Windows. I believe that for all platforms, specifying > a value of '0' means use the platform default. This should be true for > ThreadStackSize, CompilerThreadStackSize and CompilerThreadStackSize > options. > > Dan > > > On 3/29/16 12:50 PM, Gerard Ziemski wrote: >> hi Ron, >> >> This change is needed to enable running ThreadStackSize as part of the TestOptionsWithRanges test. >> >> ThreadStackSize needed its range implemented in platform dependent way, where on Windows 0 means ?use os defaults? - please see Dan?s comment in the issue for more background. >> >> >> cheers >> >>> On Mar 29, 2016, at 12:57 PM, Ron Durbin wrote: >>> >>> Gerard, >>> >>> I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. >>> I have not seen this failure of the min test on windows. I would like to understand why this change is >>> needed. >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: Gerard Ziemski >>>> Sent: Friday, March 25, 2016 10:27 AM >>>> To: hotspot-runtime-dev at openjdk.java.net >>>> Subject: RFR (S): 8136766: Enable ThreadStackSize range test >>>> >>>> hi all, >>>> >>>> Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >>>> Windows) and adds constraint for ThreadStackSize, which allows us to include it in >>>> test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8136766 >>>> http://cr.openjdk.java.net/~gziemski/8136766_rev1 >>>> >>>> Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. > From coleen.phillimore at oracle.com Tue Mar 29 22:33:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 29 Mar 2016 18:33:42 -0400 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <176E1ED0-E954-4CAC-BB6D-1E8AAA184877@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> <56EAB11D.2030001@oracle.com> <176E1ED0-E954-4CAC-BB6D-1E8AAA184877@oracle.com> Message-ID: <56FB02C6.70600@oracle.com> Hi, I think this looks good. http://cr.openjdk.java.net/~gziemski/8142510_rev2/src/share/vm/runtime/globals.cpp.udiff.html The only thing I'd change is to use mtInternal for the C_HEAP allocation rather than mtLogging. I think all of the arguments NMT tracking should be mtCommand or mtArg, rather than mtInternal but this should be consistent with that. I'll file an RFE that someone might want to pick up. thanks, Coleen On 3/17/16 9:52 AM, Gerard Ziemski wrote: > Thank you very much Dmitry! > >> On Mar 17, 2016, at 8:29 AM, Dmitry Dmitriev wrote: >> >> Hi Gerard, >> >> Looks good, except copyrights years in the following modules(forgot about that in the first round): >> commandLineFlagConstraintList.cpp >> commandLineFlagConstraintList.hpp >> commandLineFlagRangeList.hpp >> >> Not need a new webrev for that. >> >> Thanks, >> Dmitry >> >> On 16.03.2016 19:55, Gerard Ziemski wrote: >>> hi all, >>> >>> This is rev2 of the fix incorporating feedback from Dmitry: >>> >>> - re-use "CommandLineFlagConstraintList::find()" >>> >>> Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) >>> >>> With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. >>> >>> >>> bug https://bugs.openjdk.java.net/browse/JDK-8142510 >>> webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 >>> >>> tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation >>> >>> >>> cheers From daniel.daugherty at oracle.com Tue Mar 29 23:30:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Mar 2016 17:30:11 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> Message-ID: <56FB1003.8050902@oracle.com> Hi Carsten! Thanks for taking the time to jump into this review. Responses embedded below... On 3/29/16 9:56 AM, Carsten Varming wrote: > Dear Dan, > > Generally a very nice clean-up, but I have a few questions. > > Quick question: Is it time to remove all those unused perf > variables: _sync_EmptyNotifications, _sync_Notifications, _sync_SlowEnter, _sync_SlowExit, _sync_SlowNotify, _sync_SlowNotifyAll, _sync_FailedSpins, _sync_SuccessfulSpins, _sync_PrivateA, _sync_PrivateB, _sync_MonInCirculation, > and _sync_MonScavenged. Claes chimed in on the thread with a mention of: > there's already an RFE for that: https://bugs.openjdk.java.net/browse/JDK-8068593 so I think the above comment is covered. > synchronizer.cpp:290 you mention that the monitor is either being > inflated or has already been inflated, but mark->has_monitor() returns > false if the monitor is being inflated, and this fact is important for > the assert in line 292 as it would otherwise dereference a NULL pointer. You are correct. This line: L290: // Is inflating or inflated. is wrong and I need to delete the "inflating or" part, but then... > BTW., should the if-clause, down to above the return, for the > recursive case in fast_exit be removed in the product build? It looks > like a few dead loads of volatile values to me. Looking at the entire block: 281 if (dhw == NULL) { 282 // Marked as a recursive stack-lock. 283 // Diagnostics -- Could be: stack-locked, inflating, inflated. 284 mark = object->mark(); 285 assert(!mark->is_neutral(), "invariant"); 286 if (mark->has_locker() && mark != markOopDesc::INFLATING()) { 287 assert(THREAD->is_lock_owned((address)mark->locker()), "invariant"); 288 } 289 if (mark->has_monitor()) { 290 // Is inflating or inflated. 291 ObjectMonitor * m = mark->monitor(); 292 assert(((oop)(m->object()))->mark() == mark, "invariant"); 293 assert(m->is_entered(THREAD), "invariant"); 294 } 295 return; 296 } It is a bit of a mess in many ways... If this line: L284: mark = object->mark(); happens to return a 'mark' value of markOopDesc::INFLATING(), then 'mark' is NULL and these lines all blow up: L285: assert(!mark->is_neutral(), "invariant"); L286: if (mark->has_locker() && mark != markOopDesc::INFLATING()) { L287: assert(THREAD->is_lock_owned((address)mark->locker()), "invariant"); L289: if (mark->has_monitor()) { L291: ObjectMonitor * m = mark->monitor(); In fact, the first assert(): L277: assert(!object->mark()->has_bias_pattern(), "should not see bias pattern here"); is a problem if 'mark()' happens to return markOopDesc::INFLATING(). I'm going to have to take another look at all this sanity checking code and make it a little more sane. :-) > There is a comment in synchronizer.cpp:1419 that mentions that it is > safe to read the displaced mark word of a lock as the thread exiting > the lock will wait for the object mark word to be different from > INFLATING. I don't see fast_exit waiting for the mark word to be > different from INFLATING in the recursive case, so could the > mark->displaced_mark_helper() in line 1423 be reading an arbitrary > value on the stack of the thread holding the lock? Is this a bug? You followed up on the above comment with your own reply: > I think I figured out why what the comment " The owner can't die or > unwind past the lock while our INFLATING object is in the mark" means. > The displaced mark word is in the first lock on the stack of the > thread owning the lock. That mean the only case to worry about the the > non-recursive exit which is handled by a call to inflate as INFLATING > is different from the pointer to the lock. It would be nice with a > comment explaining why the recursive exit does not need to wait, i.e., > the object mark word always points to the first lock on the stack of > the thread currently owning the lock. With your reply above I think you've reached the conclusion that the code is working, but we need better comments. I think the whole INFLATING mechanism needs to be looked at for better comments which I wasn't trying to do with this fix. You ended that reply with: > Anyway, the clean-up looks good. but I'm thinking that you meant that for just the one comment thread in your original post and not for your entire review. > I don't understand the comment "Is recursive stack-lock" in > synchronizer.cpp:303. The recursive case was handled above and ended > with a return. This should be the non-recursive case. Agreed. I think I screwed up that comment when I did my extraction of the cleanup changes for this patch. I will delete that line. > I also don't understand how it can be safe to install the old > displaced mark word read at the top of the method as a different > thread could have installed a hashCode into the displaced mark word > between the read and the CAS into the object mark word. Could this gap > drop the hashCode, i.e., the value of the java method void > Object.hashCode() could change for the object? You followed up on the above comment with your own reply: > Re my last comment about a potential race between FastHashCode and > fast_exit. Never mind, I just noticed that FastHashCode will inflate > the lock to monitor before installing a hash code. so I think the above comment is covered. Dan > > Carsten > > On Mon, Mar 28, 2016 at 7:19 PM, Daniel D. Daugherty > > wrote: > > On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: > > On 3/24/16 3:27 PM, Vladimir Kozlov wrote: > > In sharedRuntime.cpp you could use BasicObjectLock::size() > as you did in c1_LIRAssembler_x86.cpp > > > I'll take a look. I may leave that cleanup to another pass, if > you would be OK with it... I'm nearing the end of my 72 hour > stress test cycle and don't want to repeat it... :-) > > > Here's the C1 change: > > $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 > 11:28:06 2016 -0800 > +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 > 16:12:30 2016 -0700 > @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { > Register OSR_buf = osrBufferPointer()->as_pointer_register(); > { assert(frame::interpreter_frame_monitor_size() == > BasicObjectLock::size(), "adjust code below"); > int monitor_offset = BytesPerWord * method()->max_locals() + > - (2 * BytesPerWord) * (number_of_locks - 1); > + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks > - 1); > // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in > // the OSR buffer using 2 word entries: first the lock and then > // the oop. > > > Here's the existing code in SharedRuntime::OSR_migration_begin(): > > // Allocate temp buffer, 1 word per local & 2 per active monitor > int buf_size_words = max_locals + active_monitor_count * > (sizeof(BasicObjectLock) / wordSize); > intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); > > > so is your suggestion to change: > > sizeof(BasicObjectLock) / wordSize > > to: > > BasicObjectLock::size() > > or am I misunderstanding what you mean? > > Dan > > From derek.white at oracle.com Wed Mar 30 03:32:56 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 29 Mar 2016 23:32:56 -0400 Subject: RFR: 8152905: hs_err file is missing gc threads Message-ID: <56FB48E8.5050609@oracle.com> Summary: List the GC threads in the hs_err file in the "Other Threads" section There are 4 small parts to this: 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over concurrent mark worker threads. 2) Have Thread::print_on_error() print the thread name of NamedThreads. 3) Factor out code that prints out each "Other Thread" to Threads::print_on_error(). 4) Call Threads::print_on_error() on every GC thread. BUG: 8152905: hs_err file is missing gc threads WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ TESTING: - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. - jprt Thanks, - Derek From robbin.ehn at oracle.com Wed Mar 30 09:17:33 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 30 Mar 2016 11:17:33 +0200 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> Message-ID: <56FB99AD.30207@oracle.com> Hi Yasumasa, On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: > Hi Robbin, > 2016/03/25 1:51 "Robbin Ehn" >: > > > > Hi Yasumasa, > > > > I'm not sure why you don't set it: > > > > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp > > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 +0000 > > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 +0100 > > @@ -3584,6 +3584,7 @@ > > JavaThread* main_thread = new JavaThread(); > > main_thread->set_thread_state(_thread_in_vm); > > main_thread->initialize_thread_current(); > > + main_thread->set_native_thread_name("main"); > > // must do this before set_active_handles > > main_thread->record_stack_base_and_size(); > > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > > > > here instead? Am I missing something? > > Native thread name is the same to thread name in Thread class. > It is set in c'tor in Thread or setName(). > If you create new thread in Java app, native thread name will be set at > startup. However, main thread is already starte in VM. > Thread name for "main" is set in create_initial_thread(). > I think that the place of setting thrrad name should be the same. Yes, I see your point. But then something like this is nicer, no? --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 +0200 +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 +0200 @@ -981,6 +981,7 @@ // Creates the initial Thread static oop create_initial_thread(Handle thread_group, JavaThread* thread, TRAPS) { + static const char* initial_thread_name = "main"; Klass* k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, CHECK_NULL); instanceKlassHandle klass (THREAD, k); instanceHandle thread_oop = klass->allocate_instance_handle(CHECK_NULL); @@ -988,8 +989,10 @@ java_lang_Thread::set_thread(thread_oop(), thread); java_lang_Thread::set_priority(thread_oop(), NormPriority); thread->set_threadObj(thread_oop()); - - Handle string = java_lang_String::create_from_str("main", CHECK_NULL); + + thread->set_native_thread_name(initial_thread_name); + + Handle string = java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); JavaValue result(T_VOID); JavaCalls::call_special(&result, thread_oop, > > > The launcher seem to name itself 'java' and naming this thread just > > 'main' is confusing to me. > > > > E.g. so main thread of the process (and thus the process) is 'java' but > > first JavaThread is 'main'. > > The native main thread in the process is not JavaThread. It is waiting > for ending of Java main thread with pthread_join(). > set_native_thread_name() is for JavaThread. So I think that we do not > need to call it for native main thread. Not sure if we can change it anyhow, since we want java and native name to be the same and java thread name might have some dependents. The name is visible in e.g. /proc. $ ps H -C java -o 'pid tid comm' | head -4 PID TID COMMAND 6423 6423 java 6423 6424 main 6423 6425 GC Thread#0 It would be nice with something like 'Java Main Thread'. Thanks /Robbin > > Thanks, > > Yasumasa > > > Thanks! > > > > /Robbin > > > > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > > > Hi all, > > > > > > HotSpot for Linux will set thread name via pthread_setname_np(). > > > However, main thread does not have it. > > > > > > All JavaThread have native name, and main thread is JavaThread. > > > For consistency, main thread should have native thread name. > > > > > > I uploaded a webrev. Could you review it? > > > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > > > > > > I cannot access JPRT. > > > So I need a sponsor. > > > > > > > > > Thanks, > > > > > > Yasumasa > > > > From marcus.larsson at oracle.com Wed Mar 30 09:34:51 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 30 Mar 2016 11:34:51 +0200 Subject: UL: Two enhancement proposal for UL In-Reply-To: <56FA9491.60103@gmail.com> References: <56FA9491.60103@gmail.com> Message-ID: <56FB9DBB.8050605@oracle.com> Hi Yasumasa, On 03/29/2016 04:43 PM, Yasumasa Suenaga wrote: > Hi all, > > I want to propose two enhancement for UL. > > > 1. Set filesize option with k/m/g > I want to set filesize option with k/m/g: > -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m > > Implementation sample: > http://cr.openjdk.java.net/~ysuenaga/ul/set-filesize-option/ In logFileOutput.cpp: 119 size_t value; 120 if (Arguments::atomull(value_str, &value)) { 121 if (value <= SIZE_MAX) { 122 _rotate_size = value; 123 success = true; 124 } else { 125 success = false; 126 } 127 break; 128 } else { The if-statement on line 121 is redundant and should be removed. You could also let atomull write directly to the _rotate_size field and remove the local size_t value. Other than that the patch looks good to me. > > > 2. Show output option in VM.log jcmd > 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, > > Implementation sample: > http://cr.openjdk.java.net/~ysuenaga/ul/show-output-options/ I think this is a good idea, but the implementation could be simpler. Since we don't allow reconfiguration of output options there's no need to set the option string anywhere else but in the constructor. This removes the need for a set_option_string method as long as we keep the _option_string protected so that subclasses may set it in their constructor. Also, the destructor in LogOutput is missing os::free(_output_string). > > > I want to file them to JBS and to upload webrev. > Are they accepted? I think they're fine. Thanks, Marcus > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Wed Mar 30 09:41:23 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Mar 2016 18:41:23 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56FB99AD.30207@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> Message-ID: Hi Robbin, 2016/03/30 18:22 "Robbin Ehn" : > > Hi Yasumasa, > > > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >> >> Hi Robbin, >> 2016/03/25 1:51 "Robbin Ehn" > >: >> >> > >> > Hi Yasumasa, >> > >> > I'm not sure why you don't set it: >> > >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 +0000 >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 +0100 >> > @@ -3584,6 +3584,7 @@ >> > JavaThread* main_thread = new JavaThread(); >> > main_thread->set_thread_state(_thread_in_vm); >> > main_thread->initialize_thread_current(); >> > + main_thread->set_native_thread_name("main"); >> > // must do this before set_active_handles >> > main_thread->record_stack_base_and_size(); >> > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >> > >> > here instead? Am I missing something? >> >> Native thread name is the same to thread name in Thread class. >> It is set in c'tor in Thread or setName(). >> If you create new thread in Java app, native thread name will be set at >> startup. However, main thread is already starte in VM. >> Thread name for "main" is set in create_initial_thread(). >> I think that the place of setting thrrad name should be the same. > > > Yes, I see your point. But then something like this is nicer, no? > > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 +0200 > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 +0200 > @@ -981,6 +981,7 @@ > // Creates the initial Thread > static oop create_initial_thread(Handle thread_group, JavaThread* thread, > TRAPS) { > + static const char* initial_thread_name = "main"; > Klass* k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, CHECK_NULL); > instanceKlassHandle klass (THREAD, k); > instanceHandle thread_oop = klass->allocate_instance_handle(CHECK_NULL); > @@ -988,8 +989,10 @@ > java_lang_Thread::set_thread(thread_oop(), thread); > java_lang_Thread::set_priority(thread_oop(), NormPriority); > thread->set_threadObj(thread_oop()); > - > - Handle string = java_lang_String::create_from_str("main", CHECK_NULL); > + > + thread->set_native_thread_name(initial_thread_name); > + > + Handle string = java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); > > JavaValue result(T_VOID); > JavaCalls::call_special(&result, thread_oop, Okay, I will upload new webrev later. >> > The launcher seem to name itself 'java' and naming this thread just >> > 'main' is confusing to me. >> > >> > E.g. so main thread of the process (and thus the process) is 'java' but >> > first JavaThread is 'main'. >> >> The native main thread in the process is not JavaThread. It is waiting >> for ending of Java main thread with pthread_join(). >> set_native_thread_name() is for JavaThread. So I think that we do not >> need to call it for native main thread. > > > Not sure if we can change it anyhow, since we want java and native name to be the same and java thread name might have some dependents. > > The name is visible in e.g. /proc. > > $ ps H -C java -o 'pid tid comm' | head -4 > PID TID COMMAND > 6423 6423 java > 6423 6424 main > 6423 6425 GC Thread#0 > > It would be nice with something like 'Java Main Thread'. I do not think so. Native main thread might not be a Java launcher - e.g. Apache commons-daemon, JNI application, etc. If you want to change native main thread name, I think that we have to change Java launcher code. Should I include it in new webrev? Thanks, Yasumasa > Thanks > > /Robbin > > >> >> Thanks, >> >> Yasumasa >> >> > Thanks! >> > >> > /Robbin >> > >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >> > > Hi all, >> > > >> > > HotSpot for Linux will set thread name via pthread_setname_np(). >> > > However, main thread does not have it. >> > > >> > > All JavaThread have native name, and main thread is JavaThread. >> > > For consistency, main thread should have native thread name. >> > > >> > > I uploaded a webrev. Could you review it? >> > > >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >> > > >> > > I cannot access JPRT. >> > > So I need a sponsor. >> > > >> > > >> > > Thanks, >> > > >> > > Yasumasa >> > > >> From robbin.ehn at oracle.com Wed Mar 30 10:10:32 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 30 Mar 2016 12:10:32 +0200 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> Message-ID: <56FBA618.2020809@oracle.com> Hi, On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: > Hi Robbin, > > 2016/03/30 18:22 "Robbin Ehn" >: > > > > Hi Yasumasa, > > > > > > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: > >> > >> Hi Robbin, > >> 2016/03/25 1:51 "Robbin Ehn" > >> >>: > >> > >> > > >> > Hi Yasumasa, > >> > > >> > I'm not sure why you don't set it: > >> > > >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp > >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 > +0000 > >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 > +0100 > >> > @@ -3584,6 +3584,7 @@ > >> > JavaThread* main_thread = new JavaThread(); > >> > main_thread->set_thread_state(_thread_in_vm); > >> > main_thread->initialize_thread_current(); > >> > + main_thread->set_native_thread_name("main"); > >> > // must do this before set_active_handles > >> > main_thread->record_stack_base_and_size(); > >> > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > >> > > >> > here instead? Am I missing something? > >> > >> Native thread name is the same to thread name in Thread class. > >> It is set in c'tor in Thread or setName(). > >> If you create new thread in Java app, native thread name will be set at > >> startup. However, main thread is already starte in VM. > >> Thread name for "main" is set in create_initial_thread(). > >> I think that the place of setting thrrad name should be the same. > > > > > > Yes, I see your point. But then something like this is nicer, no? > > > > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 +0200 > > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 +0200 > > @@ -981,6 +981,7 @@ > > // Creates the initial Thread > > static oop create_initial_thread(Handle thread_group, JavaThread* > thread, > > TRAPS) { > > + static const char* initial_thread_name = "main"; > > Klass* k = > SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, > CHECK_NULL); > > instanceKlassHandle klass (THREAD, k); > > instanceHandle thread_oop = > klass->allocate_instance_handle(CHECK_NULL); > > @@ -988,8 +989,10 @@ > > java_lang_Thread::set_thread(thread_oop(), thread); > > java_lang_Thread::set_priority(thread_oop(), NormPriority); > > thread->set_threadObj(thread_oop()); > > - > > - Handle string = java_lang_String::create_from_str("main", CHECK_NULL); > > + > > + thread->set_native_thread_name(initial_thread_name); > > + > > + Handle string = > java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); > > > > JavaValue result(T_VOID); > > JavaCalls::call_special(&result, thread_oop, > > Okay, I will upload new webrev later. Thanks! > > >> > The launcher seem to name itself 'java' and naming this thread just > >> > 'main' is confusing to me. > >> > > >> > E.g. so main thread of the process (and thus the process) is > 'java' but > >> > first JavaThread is 'main'. > >> > >> The native main thread in the process is not JavaThread. It is waiting > >> for ending of Java main thread with pthread_join(). > >> set_native_thread_name() is for JavaThread. So I think that we do not > >> need to call it for native main thread. > > > > > > Not sure if we can change it anyhow, since we want java and native > name to be the same and java thread name might have some dependents. > > > > The name is visible in e.g. /proc. > > > > $ ps H -C java -o 'pid tid comm' | head -4 > > PID TID COMMAND > > 6423 6423 java > > 6423 6424 main > > 6423 6425 GC Thread#0 > > > > It would be nice with something like 'Java Main Thread'. > > I do not think so. > Native main thread might not be a Java launcher - e.g. Apache > commons-daemon, JNI application, etc. > > If you want to change native main thread name, I think that we have to > change Java launcher code. > Should I include it in new webrev? No Thanks again! /Robbin > > Thanks, > > Yasumasa > > > Thanks > > > > /Robbin > > > > > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > Thanks! > >> > > >> > /Robbin > >> > > >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > >> > > Hi all, > >> > > > >> > > HotSpot for Linux will set thread name via pthread_setname_np(). > >> > > However, main thread does not have it. > >> > > > >> > > All JavaThread have native name, and main thread is JavaThread. > >> > > For consistency, main thread should have native thread name. > >> > > > >> > > I uploaded a webrev. Could you review it? > >> > > > >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > >> > > > >> > > I cannot access JPRT. > >> > > So I need a sponsor. > >> > > > >> > > > >> > > Thanks, > >> > > > >> > > Yasumasa > >> > > > >> > From andreas.eriksson at oracle.com Wed Mar 30 12:12:46 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 30 Mar 2016 14:12:46 +0200 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances Message-ID: <56FBC2BE.3060806@oracle.com> Hi, Please review this fix for 8135322: ConstantPool::release_C_heap_structures not run in some circumstances. Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 The way this occurs is: 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is created during class redefinition. 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not cleaned up by ClassLoaderDataGraph::do_unloading because the holding ClassLoaderData is already dead. 3. ClassLoaderData::~ClassLoaderData is called, which usually runs InstanceKlass::release_C_heap_structures, which in turn will call ConstantPool::release_C_heap_structures. But since there is no corresponding InstanceKlass for /merge_cp/ it will never release its C heap structures. 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For JDK 9 the Monitor has been removed, but we will miss doing a call to ConstantPool::unreference_symbols, which is probably not good either. This change adds a call to free everything in the _deallocate_list first thing in ClassLoaderData::~ClassLoaderData. Note: Running deallocate_contents() on everything in the list might be doing unnecessary work: What we really would like to do is run release_C_heap_structures() on constant pools in the list that do not have a corresponding InstanceKlass. Not sure it's worth the effort to do the filtering, since I believe the _deallocate_list is usually not that long. Note 2: After fixing in JDK 9 I'll backport this to JDK 8, where it has a more immediately visible effect. Regards, Andreas From thomas.stuefe at gmail.com Wed Mar 30 13:31:33 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 Mar 2016 15:31:33 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FAD0E3.5090508@oracle.com> References: <56FAD0E3.5090508@oracle.com> Message-ID: Hi Max, Disclaimer: not a (R)eviewer. Do we really need a list of all tags and all decorators? Also: I assume what you print is the Log state as it is at the time the hs-err file is printed. If logging was enabled/changed during lifetime of the VM, e.g. with jcmd, would it be possible to see that? At least a warning if logging was not enabled from the start on. Kind Regards, Thomas On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner wrote: > Hello, > Please review another Unified Logging change. They are almost done, and we > are serious this time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8151526 > webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ > > The logging configuration is now printed in each hs_err file. The output > is the same as you would see from -Xlog:logging=trace and it is obtained > from LogConfiguration::describe(). > > Below is a sample of the hs_err contents. The Logging info is printed > after VM Arguments and Whitebox, and before Environment Variables. > > VM Arguments: > java_command: Kaboom > java_class_path (initial): . > Launcher Type: SUN_STANDARD > > Logging: > Available log levels: off, trace, debug, info, warning, error > Available log decorators: time (t), uptime (u), timemillis (tm), > uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid > (p), tid (ti), level (l), tags (tg) > Available log tags: alloc, age, barrier, biasedlocking, bot, census, > classhisto, classresolve, classinit, classload, classloaderdata, > classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, > exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, > liveness, logging, marking, metaspace, modules, monitorinflation, os, > phases, plab, promotion, preorder, protectiondomain, ref, refine, region, > remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, start, > startuptime, state, stats, stringdedup, stringtable, survivor, sweep, task, > thread, tlab, time, verboseverification, verify, vmoperation, vtables > Log output configuration: > #0: stdout all=off uptime,level,tags, > #1: stderr all=warning uptime,level,tags, > > Environment Variables: > > JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk > > PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin > SHELL=/bin/bash > OS=Linux > > From yasuenag at gmail.com Wed Mar 30 13:47:35 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Mar 2016 22:47:35 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56FBA618.2020809@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> Message-ID: <56FBD8F7.3020909@gmail.com> Hi, I uploaded new webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ Thanks, Yasumasa On 2016/03/30 19:10, Robbin Ehn wrote: > Hi, > > On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >> Hi Robbin, >> >> 2016/03/30 18:22 "Robbin Ehn" > >: >> > >> > Hi Yasumasa, >> > >> > >> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >> >> >> >> Hi Robbin, >> >> 2016/03/25 1:51 "Robbin Ehn" > >> >> >>: >> >> >> >> > >> >> > Hi Yasumasa, >> >> > >> >> > I'm not sure why you don't set it: >> >> > >> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >> +0000 >> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >> +0100 >> >> > @@ -3584,6 +3584,7 @@ >> >> > JavaThread* main_thread = new JavaThread(); >> >> > main_thread->set_thread_state(_thread_in_vm); >> >> > main_thread->initialize_thread_current(); >> >> > + main_thread->set_native_thread_name("main"); >> >> > // must do this before set_active_handles >> >> > main_thread->record_stack_base_and_size(); >> >> > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >> >> > >> >> > here instead? Am I missing something? >> >> >> >> Native thread name is the same to thread name in Thread class. >> >> It is set in c'tor in Thread or setName(). >> >> If you create new thread in Java app, native thread name will be set at >> >> startup. However, main thread is already starte in VM. >> >> Thread name for "main" is set in create_initial_thread(). >> >> I think that the place of setting thrrad name should be the same. >> > >> > >> > Yes, I see your point. But then something like this is nicer, no? >> > >> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 +0200 >> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 +0200 >> > @@ -981,6 +981,7 @@ >> > // Creates the initial Thread >> > static oop create_initial_thread(Handle thread_group, JavaThread* >> thread, >> > TRAPS) { >> > + static const char* initial_thread_name = "main"; >> > Klass* k = >> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >> CHECK_NULL); >> > instanceKlassHandle klass (THREAD, k); >> > instanceHandle thread_oop = >> klass->allocate_instance_handle(CHECK_NULL); >> > @@ -988,8 +989,10 @@ >> > java_lang_Thread::set_thread(thread_oop(), thread); >> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >> > thread->set_threadObj(thread_oop()); >> > - >> > - Handle string = java_lang_String::create_from_str("main", CHECK_NULL); >> > + >> > + thread->set_native_thread_name(initial_thread_name); >> > + >> > + Handle string = >> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >> > >> > JavaValue result(T_VOID); >> > JavaCalls::call_special(&result, thread_oop, >> >> Okay, I will upload new webrev later. > > Thanks! > >> >> >> > The launcher seem to name itself 'java' and naming this thread just >> >> > 'main' is confusing to me. >> >> > >> >> > E.g. so main thread of the process (and thus the process) is >> 'java' but >> >> > first JavaThread is 'main'. >> >> >> >> The native main thread in the process is not JavaThread. It is waiting >> >> for ending of Java main thread with pthread_join(). >> >> set_native_thread_name() is for JavaThread. So I think that we do not >> >> need to call it for native main thread. >> > >> > >> > Not sure if we can change it anyhow, since we want java and native >> name to be the same and java thread name might have some dependents. >> > >> > The name is visible in e.g. /proc. >> > >> > $ ps H -C java -o 'pid tid comm' | head -4 >> > PID TID COMMAND >> > 6423 6423 java >> > 6423 6424 main >> > 6423 6425 GC Thread#0 >> > >> > It would be nice with something like 'Java Main Thread'. >> >> I do not think so. >> Native main thread might not be a Java launcher - e.g. Apache >> commons-daemon, JNI application, etc. >> >> If you want to change native main thread name, I think that we have to >> change Java launcher code. >> Should I include it in new webrev? > > No > > Thanks again! > > /Robbin > >> >> Thanks, >> >> Yasumasa >> >> > Thanks >> > >> > /Robbin >> > >> > >> >> >> >> Thanks, >> >> >> >> Yasumasa >> >> >> >> > Thanks! >> >> > >> >> > /Robbin >> >> > >> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >> >> > > Hi all, >> >> > > >> >> > > HotSpot for Linux will set thread name via pthread_setname_np(). >> >> > > However, main thread does not have it. >> >> > > >> >> > > All JavaThread have native name, and main thread is JavaThread. >> >> > > For consistency, main thread should have native thread name. >> >> > > >> >> > > I uploaded a webrev. Could you review it? >> >> > > >> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >> >> > > >> >> > > I cannot access JPRT. >> >> > > So I need a sponsor. >> >> > > >> >> > > >> >> > > Thanks, >> >> > > >> >> > > Yasumasa >> >> > > >> >> >> From yasuenag at gmail.com Wed Mar 30 14:09:06 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Mar 2016 23:09:06 +0900 Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g Message-ID: <56FBDE02.2030900@gmail.com> 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/ 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 Wed Mar 30 14:09:51 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Mar 2016 23:09:51 +0900 Subject: RFR: JDK-8153074: UL: Show output option in VM.log jcmd Message-ID: <56FBDE2F.60701@gmail.com> 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 yasuenag at gmail.com Wed Mar 30 14:11:30 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 30 Mar 2016 23:11:30 +0900 Subject: UL: Two enhancement proposal for UL In-Reply-To: <56FB9DBB.8050605@oracle.com> References: <56FA9491.60103@gmail.com> <56FB9DBB.8050605@oracle.com> Message-ID: <56FBDE92.4050105@gmail.com> Hi Marcus, Thank you for replying. I filed them to JBS and sent review request: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018710.html http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018711.html Thanks, Yasumasa On 2016/03/30 18:34, Marcus Larsson wrote: > Hi Yasumasa, > > On 03/29/2016 04:43 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I want to propose two enhancement for UL. >> >> >> 1. Set filesize option with k/m/g >> I want to set filesize option with k/m/g: >> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >> >> Implementation sample: >> http://cr.openjdk.java.net/~ysuenaga/ul/set-filesize-option/ > > In logFileOutput.cpp: > > 119 size_t value; > 120 if (Arguments::atomull(value_str, &value)) { > 121 if (value <= SIZE_MAX) { > 122 _rotate_size = value; > 123 success = true; > 124 } else { > 125 success = false; > 126 } > 127 break; > 128 } else { > > The if-statement on line 121 is redundant and should be removed. You > could also let atomull write directly to the _rotate_size field and > remove the local size_t value. > > Other than that the patch looks good to me. > >> >> >> 2. Show output option in VM.log jcmd >> 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, >> >> Implementation sample: >> http://cr.openjdk.java.net/~ysuenaga/ul/show-output-options/ > > I think this is a good idea, but the implementation could be simpler. > Since we don't allow reconfiguration of output options there's no need > to set the option string anywhere else but in the constructor. This > removes the need for a set_option_string method as long as we keep the > _option_string protected so that subclasses may set it in their > constructor. Also, the destructor in LogOutput is missing > os::free(_output_string). > >> >> >> I want to file them to JBS and to upload webrev. >> Are they accepted? > > I think they're fine. > > Thanks, > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> > From marcus.larsson at oracle.com Wed Mar 30 14:17:05 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 30 Mar 2016 16:17:05 +0200 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> Message-ID: <56FBDFE1.9040202@oracle.com> Hi Gerard, On 03/22/2016 07:15 PM, Gerard Ziemski wrote: > hi Marcus, > > Thank you for incorporating the feedback. > > The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line. > > May I suggest the following implementation instead: > > static size_t number_of_lines_with_substring_in_file(const char* filename, > const char* substr) { > ResourceMark rm; > size_t ret = 0; > FILE* fp = fopen(filename, "r"); > assert(fp, "error opening file %s: %s", filename, strerror(errno)); > > int buflen = 512; > char* buf = NEW_RESOURCE_ARRAY(char, buflen); > long int pos = 0; > > while (fgets(buf, buflen, fp) != NULL) { > if (buf[strlen(buf) - 1] != '\n') { > // rewind to the beginning of the line > fseek(fp, pos, SEEK_SET); > // double the buffer size and try again > buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen); > buflen *= 2; > } else { > // get current file position > pos = ftell(fp); > > if (strstr(buf, substr) != NULL) { > ret++; > } > } > } > > fclose(fp); > return ret; > } Alright, fixed. New webrev: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/ Incremental: http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/ Also fixed some failing tests caused by this patch in the previous round of changes. Thanks, Marcus > > cheers > > >> On Mar 18, 2016, at 8:04 AM, Marcus Larsson wrote: >> >> Updated patch after feedback. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ >> >> Tested with internal VM tests through RBT. >> >> Changes: >> * Rotation filecount is now limited to 1000 files. >> * Removed loop in os::compare_file_modified_times. >> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file. >> * Added test case to check that logging to a directory gives the intended error message. >> * Fixed test help method to handle arbitrary length log lines. >> >> Thanks, >> Marcus >> >> On 03/11/2016 03:21 PM, Marcus Larsson wrote: >>> Third time's the charm. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>> >>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >>> >>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >>> >>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >>> >>> Tested with included internal VM tests through RBT. >>> >>> Thanks, >>> Marcus >>> >>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>> Hi, >>>> >>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>> Hi again, >>>>> >>>>> Taking a different approach to this. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>> >>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>> >>>>> Tested with included jtreg test through JPRT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>> >>>>>> Testing: >>>>>> Included test through JPRT >>>>>> >>>>>> Thanks, >>>>>> Marcus From daniel.daugherty at oracle.com Wed Mar 30 15:44:08 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2016 09:44:08 -0600 Subject: RFR: 8152905: hs_err file is missing gc threads In-Reply-To: <56FB48E8.5050609@oracle.com> References: <56FB48E8.5050609@oracle.com> Message-ID: <56FBF448.9020608@oracle.com> On 3/29/16 9:32 PM, Derek White wrote: > Summary: List the GC threads in the hs_err file in the "Other Threads" > section > > There are 4 small parts to this: > 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over > concurrent mark worker threads. > 2) Have Thread::print_on_error() print the thread name of NamedThreads. > 3) Factor out code that prints out each "Other Thread" to > Threads::print_on_error(). > 4) Call Threads::print_on_error() on every GC thread. > > BUG: 8152905: hs_err file is missing gc threads > > WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ src/share/vm/runtime/thread.hpp No comments. src/share/vm/runtime/thread.cpp L831: else st->print("Thread"); L832: L833: if (is_Named_thread()) { L834: st->print(" \"%s\"", name()); L835: } The new is_Named_thread() check is currently made for every thread type, but only applies to the else-statement on L831. That else-statement should change into an else-block. Perhaps: else { st->print("Thread"); if (is_Named_thread()) { st->print(" \"%s\"", name()); } } L4496: if (this_thread) { Should not use an implied boolean. This should be: if (this_thread != NULL) { L4533: bool is_current = (current == thread); L4534: found_current = found_current || is_current; L4535: L4536: st->print("%s", is_current ? "=>" : " "); L4537: L4538: st->print(PTR_FORMAT, p2i(thread)); L4539: st->print(" "); L4540: thread->print_on_error(st, buf, buflen); L4541: st->cr(); I think this block can refactor into: print_on_error(thread, st, current, buf, buflen, &found_current); src/share/vm/gc/g1/g1CollectedHeap.cpp No comments. src/share/vm/gc/g1/g1ConcurrentMark.cpp No comments. src/share/vm/gc/g1/g1ConcurrentMark.hpp No comments. Dan > TESTING: > - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. > - jprt > > Thanks, > > - Derek > From gerard.ziemski at oracle.com Wed Mar 30 15:58:11 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 30 Mar 2016 10:58:11 -0500 Subject: RFR (M): 8142510: rev2: -XX:+PrintFlagsRanges should print default range value for those flags that have constraint and an implicit range. In-Reply-To: <56FB02C6.70600@oracle.com> References: <9B481037-2E51-4F42-A37C-909B0AE0D90A@me.com> <01153A49-5AFE-475F-8AC1-DA34C63C33FA@oracle.com> <1906D2D5-88AC-4B83-B44B-A91CAAFEC9D2@oracle.com> <56EAB11D.2030001@oracle.com> <176E1ED0-E954-4CAC-BB6D-1E8AAA184877@oracle.com> <56FB02C6.70600@oracle.com> Message-ID: <848A518F-0391-4D7D-AE18-175DD4EB68A0@oracle.com> Thank you Coleen for the review. > On Mar 29, 2016, at 5:33 PM, Coleen Phillimore wrote: > > > Hi, I think this looks good. > > http://cr.openjdk.java.net/~gziemski/8142510_rev2/src/share/vm/runtime/globals.cpp.udiff.html > > The only thing I'd change is to use mtInternal for the C_HEAP allocation rather than mtLogging. I think all of the arguments NMT tracking should be mtCommand or mtArg, rather than mtInternal but this should be consistent with that. I'll file an RFE that someone might want to pick up. I thought mtLogging would apply here since the code is used to log the errors, but we can follow up on this as you suggested in a separate RFE. > > thanks, > Coleen > > > On 3/17/16 9:52 AM, Gerard Ziemski wrote: >> Thank you very much Dmitry! >> >>> On Mar 17, 2016, at 8:29 AM, Dmitry Dmitriev wrote: >>> >>> Hi Gerard, >>> >>> Looks good, except copyrights years in the following modules(forgot about that in the first round): >>> commandLineFlagConstraintList.cpp >>> commandLineFlagConstraintList.hpp >>> commandLineFlagRangeList.hpp >>> >>> Not need a new webrev for that. >>> >>> Thanks, >>> Dmitry >>> >>> On 16.03.2016 19:55, Gerard Ziemski wrote: >>>> hi all, >>>> >>>> This is rev2 of the fix incorporating feedback from Dmitry: >>>> >>>> - re-use "CommandLineFlagConstraintList::find()" >>>> >>>> Please review this enhancement to Command Line Options Validation JEP-245, which prints default ranges for those flags, that only have constraints (ie. no range, but a constraint, implies default range) >>>> >>>> With this fix we?ll be able to include more flags in test/runtime/CommandLine/OptionsValidation test. >>>> >>>> >>>> bug https://bugs.openjdk.java.net/browse/JDK-8142510 >>>> webrev http://cr.openjdk.java.net/~gziemski/8142510_rev2 >>>> >>>> tested with JPRT hotspot, RBT hotspot/test/runtime and local test/runtime/CommandLine/OptionsValidation >>>> >>>> >>>> cheers > From gerard.ziemski at oracle.com Wed Mar 30 16:16:29 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 30 Mar 2016 11:16:29 -0500 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: <56FBDFE1.9040202@oracle.com> References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> <56FBDFE1.9040202@oracle.com> Message-ID: Look good. Thank you for you patience with my review. cheers > On Mar 30, 2016, at 9:17 AM, Marcus Larsson wrote: > > Hi Gerard, > > On 03/22/2016 07:15 PM, Gerard Ziemski wrote: >> hi Marcus, >> >> Thank you for incorporating the feedback. >> >> The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line. >> >> May I suggest the following implementation instead: >> >> static size_t number_of_lines_with_substring_in_file(const char* filename, >> const char* substr) { >> ResourceMark rm; >> size_t ret = 0; >> FILE* fp = fopen(filename, "r"); >> assert(fp, "error opening file %s: %s", filename, strerror(errno)); >> >> int buflen = 512; >> char* buf = NEW_RESOURCE_ARRAY(char, buflen); >> long int pos = 0; >> >> while (fgets(buf, buflen, fp) != NULL) { >> if (buf[strlen(buf) - 1] != '\n') { >> // rewind to the beginning of the line >> fseek(fp, pos, SEEK_SET); >> // double the buffer size and try again >> buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen); >> buflen *= 2; >> } else { >> // get current file position >> pos = ftell(fp); >> >> if (strstr(buf, substr) != NULL) { >> ret++; >> } >> } >> } >> >> fclose(fp); >> return ret; >> } > > Alright, fixed. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/ > > Also fixed some failing tests caused by this patch in the previous round of changes. > > Thanks, > Marcus > >> >> cheers >> >> >>> On Mar 18, 2016, at 8:04 AM, Marcus Larsson wrote: >>> >>> Updated patch after feedback. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ >>> >>> Tested with internal VM tests through RBT. >>> >>> Changes: >>> * Rotation filecount is now limited to 1000 files. >>> * Removed loop in os::compare_file_modified_times. >>> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file. >>> * Added test case to check that logging to a directory gives the intended error message. >>> * Fixed test help method to handle arbitrary length log lines. >>> >>> Thanks, >>> Marcus >>> >>> On 03/11/2016 03:21 PM, Marcus Larsson wrote: >>>> Third time's the charm. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>>> >>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >>>> >>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >>>> >>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >>>> >>>> Tested with included internal VM tests through RBT. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>>> Hi again, >>>>>> >>>>>> Taking a different approach to this. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>>> >>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>>> >>>>>> Tested with included jtreg test through JPRT. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>>> >>>>>>> Testing: >>>>>>> Included test through JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus From ron.durbin at oracle.com Wed Mar 30 16:27:54 2016 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 30 Mar 2016 09:27:54 -0700 (PDT) Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: <803ade70-bdcd-4027-9622-48a7cf56d954@default> References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> <803ade70-bdcd-4027-9622-48a7cf56d954@default> Message-ID: <4f582671-f7a1-49da-80c7-d7fc15f9e7ec@default> My bug is already related to yours >-----Original Message----- >From: Ron Durbin >Sent: Tuesday, March 29, 2016 11:58 AM >To: Gerard Ziemski; hotspot-runtime-dev at openjdk.java.net >Subject: RE: RFR (S): 8136766: Enable ThreadStackSize range test > >Gerard, > >I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. >I have not seen this failure of the min test on windows. I would like to understand why this change is >needed. > >Ron > >>-----Original Message----- >>From: Gerard Ziemski >>Sent: Friday, March 25, 2016 10:27 AM >>To: hotspot-runtime-dev at openjdk.java.net >>Subject: RFR (S): 8136766: Enable ThreadStackSize range test >> >>hi all, >> >>Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >>Windows) and adds constraint for ThreadStackSize, which allows us to include it in >>test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >> >>https://bugs.openjdk.java.net/browse/JDK-8136766 >>http://cr.openjdk.java.net/~gziemski/8136766_rev1 >> >>Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From mattis.castegren at oracle.com Wed Mar 30 17:12:02 2016 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Wed, 30 Mar 2016 10:12:02 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56F4489D.10107@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> Message-ID: 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(cons >>>>>>>> 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 ron.durbin at oracle.com Wed Mar 30 20:08:12 2016 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 30 Mar 2016 13:08:12 -0700 (PDT) Subject: RFR (S): 8136766: Enable ThreadStackSize range test In-Reply-To: <803ade70-bdcd-4027-9622-48a7cf56d954@default> References: <72288F10-028E-4A3A-9035-71D141B908F5@oracle.com> <803ade70-bdcd-4027-9622-48a7cf56d954@default> Message-ID: Gerard, Per our phone conversation, your solution needs refactoring. Specifically the minimum stack size mechanism you propose is not not needed as one exists in the current implementation which I am fixing. I have related your bug 8136766 to mine 8140520. Ron >-----Original Message----- >From: Ron Durbin >Sent: Tuesday, March 29, 2016 11:58 AM >To: Gerard Ziemski; hotspot-runtime-dev at openjdk.java.net >Subject: RE: RFR (S): 8136766: Enable ThreadStackSize range test > >Gerard, > >I have run the Options Range Test dozens of times with only the Max test disabled for ThreadStackSize. >I have not seen this failure of the min test on windows. I would like to understand why this change is >needed. > >Ron > >>-----Original Message----- >>From: Gerard Ziemski >>Sent: Friday, March 25, 2016 10:27 AM >>To: hotspot-runtime-dev at openjdk.java.net >>Subject: RFR (S): 8136766: Enable ThreadStackSize range test >> >>hi all, >> >>Please review this small fix which fixes the range (in platform dependent way where 0 has a special meaning on >>Windows) and adds constraint for ThreadStackSize, which allows us to include it in >>test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >> >>https://bugs.openjdk.java.net/browse/JDK-8136766 >>http://cr.openjdk.java.net/~gziemski/8136766_rev1 >> >>Passes JPRT hotspot and RBT CommandLine/OptionsValidation/TestOptionsWithRanges on all platforms. From derek.white at oracle.com Wed Mar 30 20:20:17 2016 From: derek.white at oracle.com (Derek White) Date: Wed, 30 Mar 2016 16:20:17 -0400 Subject: RFR: 8152905: hs_err file is missing gc threads In-Reply-To: <56FBF448.9020608@oracle.com> References: <56FB48E8.5050609@oracle.com> <56FBF448.9020608@oracle.com> Message-ID: <56FC3501.2010502@oracle.com> Hi Dan, On 3/30/16 11:44 AM, Daniel D. Daugherty wrote: > On 3/29/16 9:32 PM, Derek White wrote: >> Summary: List the GC threads in the hs_err file in the "Other >> Threads" section >> >> There are 4 small parts to this: >> 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over >> concurrent mark worker threads. >> 2) Have Thread::print_on_error() print the thread name of NamedThreads. >> 3) Factor out code that prints out each "Other Thread" to >> Threads::print_on_error(). >> 4) Call Threads::print_on_error() on every GC thread. >> >> BUG: 8152905: hs_err file is missing gc threads >> >> WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ > > src/share/vm/runtime/thread.hpp > No comments. > > src/share/vm/runtime/thread.cpp > L831: else st->print("Thread"); > L832: > L833: if (is_Named_thread()) { > L834: st->print(" \"%s\"", name()); > L835: } > > The new is_Named_thread() check is currently made for > every thread type, but only applies to the else-statement > on L831. That else-statement should change into an > else-block. Perhaps: > > else { > st->print("Thread"); > if (is_Named_thread()) { > st->print(" \"%s\"", name()); > } > } The intention really is to print the name for every thread type. For the GC threads, they often have the same type, but different purposes reflected in the name. For example: 0x00007f77b807e800 ConcurrentGCThread "G1 Main Marker" [stack: 0x00007f779ca7d000,0x00007f779cb7e000] [id=25865] 0x00007f77b8081000 ConcurrentGCThread "G1 Marker#0" [stack: 0x00007f779c97c000,0x00007f779ca7d000] [id=25866] 0x00007f77b806a000 ConcurrentGCThread "G1 Refine#0" [stack: 0x00007f779cee5000,0x00007f779cfe6000] [id=25863] 0x00007f77b806c000 ConcurrentGCThread "G1 Young RemSet Sampling" [stack: 0x00007f779cde4000,0x00007f779cee5000] [id=25864] 0x00007f77b8296000 ConcurrentGCThread "G1 StrDedup" [stack: 0x00007f770c757000,0x00007f770c858000] [id=25871] I can add explicit braces to the if-else-tree to make it clear that this is not an oversight. On a related note, I realized after I sent this that it's not safe to call thread->name() on a JavaThread or CompilerThread in Thread::print_on_error(), because the overridden name() might allocate, but print_on_error() is also overridden, so it's safe after all. I'll add asserts in Thread::print_on_error() that it's not called on a JavaThread or CompilerThread. > > L4496: if (this_thread) { > Should not use an implied boolean. This should be: > > if (this_thread != NULL) { OK. > > L4533: bool is_current = (current == thread); > L4534: found_current = found_current || is_current; > L4535: > L4536: st->print("%s", is_current ? "=>" : " "); > L4537: > L4538: st->print(PTR_FORMAT, p2i(thread)); > L4539: st->print(" "); > L4540: thread->print_on_error(st, buf, buflen); > L4541: st->cr(); > > I think this block can refactor into: > > print_on_error(thread, st, current, buf, buflen, > &found_current); Oh, that works! > > src/share/vm/gc/g1/g1CollectedHeap.cpp > No comments. > > src/share/vm/gc/g1/g1ConcurrentMark.cpp > No comments. > > src/share/vm/gc/g1/g1ConcurrentMark.hpp > No comments. > > Dan Thanks for the review! I'll post an updated webrev once tested. - Derek > > >> TESTING: >> - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. >> - jprt >> >> Thanks, >> >> - Derek >> > From daniel.daugherty at oracle.com Wed Mar 30 20:30:01 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2016 14:30:01 -0600 Subject: RFR: 8152905: hs_err file is missing gc threads In-Reply-To: <56FC3501.2010502@oracle.com> References: <56FB48E8.5050609@oracle.com> <56FBF448.9020608@oracle.com> <56FC3501.2010502@oracle.com> Message-ID: <56FC3749.9010900@oracle.com> On 3/30/16 2:20 PM, Derek White wrote: > Hi Dan, > > On 3/30/16 11:44 AM, Daniel D. Daugherty wrote: >> On 3/29/16 9:32 PM, Derek White wrote: >>> Summary: List the GC threads in the hs_err file in the "Other >>> Threads" section >>> >>> There are 4 small parts to this: >>> 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over >>> concurrent mark worker threads. >>> 2) Have Thread::print_on_error() print the thread name of NamedThreads. >>> 3) Factor out code that prints out each "Other Thread" to >>> Threads::print_on_error(). >>> 4) Call Threads::print_on_error() on every GC thread. >>> >>> BUG: 8152905: hs_err file is missing gc threads >>> >>> WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ >> >> src/share/vm/runtime/thread.hpp >> No comments. >> >> src/share/vm/runtime/thread.cpp >> L831: else st->print("Thread"); >> L832: >> L833: if (is_Named_thread()) { >> L834: st->print(" \"%s\"", name()); >> L835: } >> >> The new is_Named_thread() check is currently made for >> every thread type, but only applies to the else-statement >> on L831. That else-statement should change into an >> else-block. Perhaps: >> >> else { >> st->print("Thread"); >> if (is_Named_thread()) { >> st->print(" \"%s\"", name()); >> } >> } > The intention really is to print the name for every thread type. For > the GC threads, they often have the same type, but different purposes > reflected in the name. For example: > 0x00007f77b807e800 ConcurrentGCThread "G1 Main Marker" [stack: > 0x00007f779ca7d000,0x00007f779cb7e000] [id=25865] > 0x00007f77b8081000 ConcurrentGCThread "G1 Marker#0" [stack: > 0x00007f779c97c000,0x00007f779ca7d000] [id=25866] > 0x00007f77b806a000 ConcurrentGCThread "G1 Refine#0" [stack: > 0x00007f779cee5000,0x00007f779cfe6000] [id=25863] > 0x00007f77b806c000 ConcurrentGCThread "G1 Young RemSet Sampling" > [stack: 0x00007f779cde4000,0x00007f779cee5000] [id=25864] > 0x00007f77b8296000 ConcurrentGCThread "G1 StrDedup" [stack: > 0x00007f770c757000,0x00007f770c858000] [id=25871] > > I can add explicit braces to the if-else-tree to make it clear that > this is not an oversight. No need for the explicit braces. I simply misunderstood what you were trying to do here. Dan > > On a related note, I realized after I sent this that it's not safe to > call thread->name() on a JavaThread or CompilerThread in > Thread::print_on_error(), because the overridden name() might > allocate, but print_on_error() is also overridden, so it's safe after > all. I'll add asserts in Thread::print_on_error() that it's not called > on a JavaThread or CompilerThread. >> >> L4496: if (this_thread) { >> Should not use an implied boolean. This should be: >> >> if (this_thread != NULL) { > OK. >> >> L4533: bool is_current = (current == thread); >> L4534: found_current = found_current || is_current; >> L4535: >> L4536: st->print("%s", is_current ? "=>" : " "); >> L4537: >> L4538: st->print(PTR_FORMAT, p2i(thread)); >> L4539: st->print(" "); >> L4540: thread->print_on_error(st, buf, buflen); >> L4541: st->cr(); >> >> I think this block can refactor into: >> >> print_on_error(thread, st, current, buf, buflen, >> &found_current); > > Oh, that works! >> >> src/share/vm/gc/g1/g1CollectedHeap.cpp >> No comments. >> >> src/share/vm/gc/g1/g1ConcurrentMark.cpp >> No comments. >> >> src/share/vm/gc/g1/g1ConcurrentMark.hpp >> No comments. >> >> Dan > > Thanks for the review! I'll post an updated webrev once tested. > > - Derek >> >> >>> TESTING: >>> - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. >>> - jprt >>> >>> Thanks, >>> >>> - Derek >>> >> > From robbin.ehn at oracle.com Wed Mar 30 20:55:39 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 30 Mar 2016 22:55:39 +0200 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56FBD8F7.3020909@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> Message-ID: <56FC3D4B.2000700@oracle.com> Thanks, looks good. /Robbin On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: > Hi, > > I uploaded new webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/03/30 19:10, Robbin Ehn wrote: >> Hi, >> >> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>> Hi Robbin, >>> >>> 2016/03/30 18:22 "Robbin Ehn" >> >: >>> > >>> > Hi Yasumasa, >>> > >>> > >>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>> >> >>> >> Hi Robbin, >>> >> 2016/03/25 1:51 "Robbin Ehn" >> >>> >> >>: >>> >> >>> >> > >>> >> > Hi Yasumasa, >>> >> > >>> >> > I'm not sure why you don't set it: >>> >> > >>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >>> +0000 >>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >>> +0100 >>> >> > @@ -3584,6 +3584,7 @@ >>> >> > JavaThread* main_thread = new JavaThread(); >>> >> > main_thread->set_thread_state(_thread_in_vm); >>> >> > main_thread->initialize_thread_current(); >>> >> > + main_thread->set_native_thread_name("main"); >>> >> > // must do this before set_active_handles >>> >> > main_thread->record_stack_base_and_size(); >>> >> > >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>> >> > >>> >> > here instead? Am I missing something? >>> >> >>> >> Native thread name is the same to thread name in Thread class. >>> >> It is set in c'tor in Thread or setName(). >>> >> If you create new thread in Java app, native thread name will be >>> set at >>> >> startup. However, main thread is already starte in VM. >>> >> Thread name for "main" is set in create_initial_thread(). >>> >> I think that the place of setting thrrad name should be the same. >>> > >>> > >>> > Yes, I see your point. But then something like this is nicer, no? >>> > >>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 >>> +0200 >>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 >>> +0200 >>> > @@ -981,6 +981,7 @@ >>> > // Creates the initial Thread >>> > static oop create_initial_thread(Handle thread_group, JavaThread* >>> thread, >>> > TRAPS) { >>> > + static const char* initial_thread_name = "main"; >>> > Klass* k = >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >>> CHECK_NULL); >>> > instanceKlassHandle klass (THREAD, k); >>> > instanceHandle thread_oop = >>> klass->allocate_instance_handle(CHECK_NULL); >>> > @@ -988,8 +989,10 @@ >>> > java_lang_Thread::set_thread(thread_oop(), thread); >>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>> > thread->set_threadObj(thread_oop()); >>> > - >>> > - Handle string = java_lang_String::create_from_str("main", >>> CHECK_NULL); >>> > + >>> > + thread->set_native_thread_name(initial_thread_name); >>> > + >>> > + Handle string = >>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>> > >>> > JavaValue result(T_VOID); >>> > JavaCalls::call_special(&result, thread_oop, >>> >>> Okay, I will upload new webrev later. >> >> Thanks! >> >>> >>> >> > The launcher seem to name itself 'java' and naming this thread >>> just >>> >> > 'main' is confusing to me. >>> >> > >>> >> > E.g. so main thread of the process (and thus the process) is >>> 'java' but >>> >> > first JavaThread is 'main'. >>> >> >>> >> The native main thread in the process is not JavaThread. It is >>> waiting >>> >> for ending of Java main thread with pthread_join(). >>> >> set_native_thread_name() is for JavaThread. So I think that we do >>> not >>> >> need to call it for native main thread. >>> > >>> > >>> > Not sure if we can change it anyhow, since we want java and native >>> name to be the same and java thread name might have some dependents. >>> > >>> > The name is visible in e.g. /proc. >>> > >>> > $ ps H -C java -o 'pid tid comm' | head -4 >>> > PID TID COMMAND >>> > 6423 6423 java >>> > 6423 6424 main >>> > 6423 6425 GC Thread#0 >>> > >>> > It would be nice with something like 'Java Main Thread'. >>> >>> I do not think so. >>> Native main thread might not be a Java launcher - e.g. Apache >>> commons-daemon, JNI application, etc. >>> >>> If you want to change native main thread name, I think that we have to >>> change Java launcher code. >>> Should I include it in new webrev? >> >> No >> >> Thanks again! >> >> /Robbin >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> > Thanks >>> > >>> > /Robbin >>> > >>> > >>> >> >>> >> Thanks, >>> >> >>> >> Yasumasa >>> >> >>> >> > Thanks! >>> >> > >>> >> > /Robbin >>> >> > >>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>> >> > > Hi all, >>> >> > > >>> >> > > HotSpot for Linux will set thread name via >>> pthread_setname_np(). >>> >> > > However, main thread does not have it. >>> >> > > >>> >> > > All JavaThread have native name, and main thread is JavaThread. >>> >> > > For consistency, main thread should have native thread name. >>> >> > > >>> >> > > I uploaded a webrev. Could you review it? >>> >> > > >>> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>> >> > > >>> >> > > I cannot access JPRT. >>> >> > > So I need a sponsor. >>> >> > > >>> >> > > >>> >> > > Thanks, >>> >> > > >>> >> > > Yasumasa >>> >> > > >>> >> >>> From robbin.ehn at oracle.com Wed Mar 30 20:58:32 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 30 Mar 2016 22:58:32 +0200 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56FC3D4B.2000700@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> Message-ID: <56FC3DF8.4080309@oracle.com> FYI: I'm not a Reviewer. /Robbin On 03/30/2016 10:55 PM, Robbin Ehn wrote: > Thanks, looks good. > > /Robbin > > On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >> Hi, >> >> I uploaded new webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/30 19:10, Robbin Ehn wrote: >>> Hi, >>> >>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>> Hi Robbin, >>>> >>>> 2016/03/30 18:22 "Robbin Ehn" >>> >: >>>> > >>>> > Hi Yasumasa, >>>> > >>>> > >>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>> >> >>>> >> Hi Robbin, >>>> >> 2016/03/25 1:51 "Robbin Ehn" >>> >>>> >> >>: >>>> >> >>>> >> > >>>> >> > Hi Yasumasa, >>>> >> > >>>> >> > I'm not sure why you don't set it: >>>> >> > >>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >>>> +0000 >>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >>>> +0100 >>>> >> > @@ -3584,6 +3584,7 @@ >>>> >> > JavaThread* main_thread = new JavaThread(); >>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>> >> > main_thread->initialize_thread_current(); >>>> >> > + main_thread->set_native_thread_name("main"); >>>> >> > // must do this before set_active_handles >>>> >> > main_thread->record_stack_base_and_size(); >>>> >> > >>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>> >> > >>>> >> > here instead? Am I missing something? >>>> >> >>>> >> Native thread name is the same to thread name in Thread class. >>>> >> It is set in c'tor in Thread or setName(). >>>> >> If you create new thread in Java app, native thread name will be >>>> set at >>>> >> startup. However, main thread is already starte in VM. >>>> >> Thread name for "main" is set in create_initial_thread(). >>>> >> I think that the place of setting thrrad name should be the same. >>>> > >>>> > >>>> > Yes, I see your point. But then something like this is nicer, no? >>>> > >>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 >>>> +0200 >>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 >>>> +0200 >>>> > @@ -981,6 +981,7 @@ >>>> > // Creates the initial Thread >>>> > static oop create_initial_thread(Handle thread_group, JavaThread* >>>> thread, >>>> > TRAPS) { >>>> > + static const char* initial_thread_name = "main"; >>>> > Klass* k = >>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >>>> CHECK_NULL); >>>> > instanceKlassHandle klass (THREAD, k); >>>> > instanceHandle thread_oop = >>>> klass->allocate_instance_handle(CHECK_NULL); >>>> > @@ -988,8 +989,10 @@ >>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>> > thread->set_threadObj(thread_oop()); >>>> > - >>>> > - Handle string = java_lang_String::create_from_str("main", >>>> CHECK_NULL); >>>> > + >>>> > + thread->set_native_thread_name(initial_thread_name); >>>> > + >>>> > + Handle string = >>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>> > >>>> > JavaValue result(T_VOID); >>>> > JavaCalls::call_special(&result, thread_oop, >>>> >>>> Okay, I will upload new webrev later. >>> >>> Thanks! >>> >>>> >>>> >> > The launcher seem to name itself 'java' and naming this thread >>>> just >>>> >> > 'main' is confusing to me. >>>> >> > >>>> >> > E.g. so main thread of the process (and thus the process) is >>>> 'java' but >>>> >> > first JavaThread is 'main'. >>>> >> >>>> >> The native main thread in the process is not JavaThread. It is >>>> waiting >>>> >> for ending of Java main thread with pthread_join(). >>>> >> set_native_thread_name() is for JavaThread. So I think that we do >>>> not >>>> >> need to call it for native main thread. >>>> > >>>> > >>>> > Not sure if we can change it anyhow, since we want java and native >>>> name to be the same and java thread name might have some dependents. >>>> > >>>> > The name is visible in e.g. /proc. >>>> > >>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>> > PID TID COMMAND >>>> > 6423 6423 java >>>> > 6423 6424 main >>>> > 6423 6425 GC Thread#0 >>>> > >>>> > It would be nice with something like 'Java Main Thread'. >>>> >>>> I do not think so. >>>> Native main thread might not be a Java launcher - e.g. Apache >>>> commons-daemon, JNI application, etc. >>>> >>>> If you want to change native main thread name, I think that we have to >>>> change Java launcher code. >>>> Should I include it in new webrev? >>> >>> No >>> >>> Thanks again! >>> >>> /Robbin >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> > Thanks >>>> > >>>> > /Robbin >>>> > >>>> > >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Yasumasa >>>> >> >>>> >> > Thanks! >>>> >> > >>>> >> > /Robbin >>>> >> > >>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>> >> > > Hi all, >>>> >> > > >>>> >> > > HotSpot for Linux will set thread name via >>>> pthread_setname_np(). >>>> >> > > However, main thread does not have it. >>>> >> > > >>>> >> > > All JavaThread have native name, and main thread is >>>> JavaThread. >>>> >> > > For consistency, main thread should have native thread name. >>>> >> > > >>>> >> > > I uploaded a webrev. Could you review it? >>>> >> > > >>>> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>> >> > > >>>> >> > > I cannot access JPRT. >>>> >> > > So I need a sponsor. >>>> >> > > >>>> >> > > >>>> >> > > Thanks, >>>> >> > > >>>> >> > > Yasumasa >>>> >> > > >>>> >> >>>> From coleen.phillimore at oracle.com Wed Mar 30 23:06:15 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Mar 2016 19:06:15 -0400 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FBC2BE.3060806@oracle.com> References: <56FBC2BE.3060806@oracle.com> Message-ID: <56FC5BE7.2080009@oracle.com> Andreas, Good find! This seems like a safe fix. It's unfortunate to have to walk the deallocate list, but I think it's short enough and less work in comparison to having to call free_C_heap_structures on all the other classes in the dead class loader data. And deallocate_contents removes the scratch_class from the CLD _klasses list so won't walk it twice. This is really good. Coleen On 3/30/16 8:12 AM, Andreas Eriksson wrote: > Hi, > > Please review this fix for 8135322: > ConstantPool::release_C_heap_structures not run in some circumstances. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 > Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 > > The way this occurs is: > > 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is > created during class redefinition. > 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not > cleaned up by ClassLoaderDataGraph::do_unloading because the holding > ClassLoaderData is already dead. > 3. ClassLoaderData::~ClassLoaderData is called, which usually runs > InstanceKlass::release_C_heap_structures, which in turn will call > ConstantPool::release_C_heap_structures. But since there is no > corresponding InstanceKlass for /merge_cp/ it will never release its > C heap structures. > 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For > JDK 9 the Monitor has been removed, but we will miss doing a call to > ConstantPool::unreference_symbols, which is probably not good either. > > > This change adds a call to free everything in the _deallocate_list > first thing in ClassLoaderData::~ClassLoaderData. > > Note: > Running deallocate_contents() on everything in the list might be doing > unnecessary work: > What we really would like to do is run release_C_heap_structures() on > constant pools in the list that do not have a corresponding > InstanceKlass. Not sure it's worth the effort to do the filtering, > since I believe the _deallocate_list is usually not that long. > > Note 2: > After fixing in JDK 9 I'll backport this to JDK 8, where it has a more > immediately visible effect. > > Regards, > Andreas > From daniel.daugherty at oracle.com Wed Mar 30 23:44:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2016 17:44:00 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56F1ADEC.2050508@oracle.com> References: <56F1ADEC.2050508@oracle.com> Message-ID: <56FC64C0.9020003@oracle.com> Greetings, I've updated the fixes for 8077392 and 8131715 based on code review comments and test results. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/1-jdk9-hs-rt/ src/share/vm/runtime/sharedRuntime.cpp Changed to disable ObjectSynchronizer::quick_enter() for ARM64 since testing has shown that ARM64 still has hangs when the quick_enter() optimization is enabled. See: JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs https://bugs.openjdk.java.net/browse/JDK-8153107 I suspect a mis-match between the quick_enter() optimization and the ARM64 MacroAssembler code... src/share/vm/runtime/synchronizer.cpp Moved the init of the BasicLock's displaced_header to be unconditional instead of only when Atomic::cmpxchg_ptr() works. See the more detailed comments. Also fixed a code review request to rename the 'Lock' param. Redoing all the same testing... As always, comments, suggestions and/or questions are welcome. Dan On 3/22/16 2:41 PM, Daniel D. Daugherty wrote: > Greetings, > > I have fixes for the following two bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > Both fixes are very, very small and will be bundled together in the > same changeset for obvious reasons. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ > > While the fix for JDK-8077392 is a simple 1-liner, the explanation of > the race is much, much longer. I've attached the detailed evaluation > to this RFR; it is a copy of the same note that I added to > https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached > copy has all the indentation white space intact. I don't know why > JBS likes to reformat the notes, but it does... :-( > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan From yasuenag at gmail.com Wed Mar 30 23:49:56 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 08:49:56 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <56FC3DF8.4080309@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> Message-ID: Thanks Robbin, I'm waiting a sponsor and more reviewer :-) Yasumasa 2016/03/31 5:58 "Robbin Ehn" : > FYI: I'm not a Reviewer. > > /Robbin > > On 03/30/2016 10:55 PM, Robbin Ehn wrote: > >> Thanks, looks good. >> >> /Robbin >> >> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >> >>> Hi, >>> >>> I uploaded new webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/30 19:10, Robbin Ehn wrote: >>> >>>> Hi, >>>> >>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>> >>>>> Hi Robbin, >>>>> >>>>> 2016/03/30 18:22 "Robbin Ehn" >>>> >: >>>>> > >>>>> > Hi Yasumasa, >>>>> > >>>>> > >>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>> >> >>>>> >> Hi Robbin, >>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>> >>>>> >> >>: >>>>> >> >>>>> >> > >>>>> >> > Hi Yasumasa, >>>>> >> > >>>>> >> > I'm not sure why you don't set it: >>>>> >> > >>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >>>>> +0000 >>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >>>>> +0100 >>>>> >> > @@ -3584,6 +3584,7 @@ >>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>> >> > main_thread->initialize_thread_current(); >>>>> >> > + main_thread->set_native_thread_name("main"); >>>>> >> > // must do this before set_active_handles >>>>> >> > main_thread->record_stack_base_and_size(); >>>>> >> > >>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>> >> > >>>>> >> > here instead? Am I missing something? >>>>> >> >>>>> >> Native thread name is the same to thread name in Thread class. >>>>> >> It is set in c'tor in Thread or setName(). >>>>> >> If you create new thread in Java app, native thread name will be >>>>> set at >>>>> >> startup. However, main thread is already starte in VM. >>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>> >> I think that the place of setting thrrad name should be the same. >>>>> > >>>>> > >>>>> > Yes, I see your point. But then something like this is nicer, no? >>>>> > >>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 >>>>> +0200 >>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 >>>>> +0200 >>>>> > @@ -981,6 +981,7 @@ >>>>> > // Creates the initial Thread >>>>> > static oop create_initial_thread(Handle thread_group, JavaThread* >>>>> thread, >>>>> > TRAPS) { >>>>> > + static const char* initial_thread_name = "main"; >>>>> > Klass* k = >>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >>>>> CHECK_NULL); >>>>> > instanceKlassHandle klass (THREAD, k); >>>>> > instanceHandle thread_oop = >>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>> > @@ -988,8 +989,10 @@ >>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>> > thread->set_threadObj(thread_oop()); >>>>> > - >>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>> CHECK_NULL); >>>>> > + >>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>> > + >>>>> > + Handle string = >>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>> > >>>>> > JavaValue result(T_VOID); >>>>> > JavaCalls::call_special(&result, thread_oop, >>>>> >>>>> Okay, I will upload new webrev later. >>>>> >>>> >>>> Thanks! >>>> >>>> >>>>> >> > The launcher seem to name itself 'java' and naming this thread >>>>> just >>>>> >> > 'main' is confusing to me. >>>>> >> > >>>>> >> > E.g. so main thread of the process (and thus the process) is >>>>> 'java' but >>>>> >> > first JavaThread is 'main'. >>>>> >> >>>>> >> The native main thread in the process is not JavaThread. It is >>>>> waiting >>>>> >> for ending of Java main thread with pthread_join(). >>>>> >> set_native_thread_name() is for JavaThread. So I think that we do >>>>> not >>>>> >> need to call it for native main thread. >>>>> > >>>>> > >>>>> > Not sure if we can change it anyhow, since we want java and native >>>>> name to be the same and java thread name might have some dependents. >>>>> > >>>>> > The name is visible in e.g. /proc. >>>>> > >>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>> > PID TID COMMAND >>>>> > 6423 6423 java >>>>> > 6423 6424 main >>>>> > 6423 6425 GC Thread#0 >>>>> > >>>>> > It would be nice with something like 'Java Main Thread'. >>>>> >>>>> I do not think so. >>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>> commons-daemon, JNI application, etc. >>>>> >>>>> If you want to change native main thread name, I think that we have to >>>>> change Java launcher code. >>>>> Should I include it in new webrev? >>>>> >>>> >>>> No >>>> >>>> Thanks again! >>>> >>>> /Robbin >>>> >>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> > Thanks >>>>> > >>>>> > /Robbin >>>>> > >>>>> > >>>>> >> >>>>> >> Thanks, >>>>> >> >>>>> >> Yasumasa >>>>> >> >>>>> >> > Thanks! >>>>> >> > >>>>> >> > /Robbin >>>>> >> > >>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>> >> > > Hi all, >>>>> >> > > >>>>> >> > > HotSpot for Linux will set thread name via >>>>> pthread_setname_np(). >>>>> >> > > However, main thread does not have it. >>>>> >> > > >>>>> >> > > All JavaThread have native name, and main thread is >>>>> JavaThread. >>>>> >> > > For consistency, main thread should have native thread name. >>>>> >> > > >>>>> >> > > I uploaded a webrev. Could you review it? >>>>> >> > > >>>>> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>> >> > > >>>>> >> > > I cannot access JPRT. >>>>> >> > > So I need a sponsor. >>>>> >> > > >>>>> >> > > >>>>> >> > > Thanks, >>>>> >> > > >>>>> >> > > Yasumasa >>>>> >> > > >>>>> >> >>>>> >>>>> From daniel.daugherty at oracle.com Thu Mar 31 00:01:16 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2016 18:01:16 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F1BAB0.2000001@oracle.com> References: <56F1BAB0.2000001@oracle.com> Message-ID: <56FC68CC.601@oracle.com> I've updated the fix for 8152358 based on code review comments and test results. Reminder that 8152358 is a superset of the fixes for 8077392 and 8131715... Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8152358-webrev/1-jdk9-hs-rt/ The files changed in this round relative to round 0: src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Copyright update. src/share/vm/runtime/sharedRuntime.cpp Changed to disable ObjectSynchronizer::quick_enter() for ARM64 since testing has shown that ARM64 still has hangs when the quick_enter() optimization is enabled. See: JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs https://bugs.openjdk.java.net/browse/JDK-8153107 I suspect a mis-match between the quick_enter() optimization and the ARM64 MacroAssembler code... src/share/vm/runtime/synchronizer.cpp Moved the init of the BasicLock's displaced_header to be unconditional instead of only when Atomic::cmpxchg_ptr() works. See the more detailed comments. Also fixed a code review request to rename the 'Lock' param. Rework ObjectSynchronizer::fast_exit() comments, assert()'s and included code due to code review comments. This includes new comments explaining the special case where the BasicLock's displaced_header is marked as a recursive enter and we have an inflated Java Monitor (ObjectMonitor). The updated assert()'s and comments also address the markOopDesc::INFLATING special case in this function. Absolutely exciting reading here! Redoing all the same testing... plus adding a fastdebug instance to the stress config... As always, comments, suggestions and/or questions are welcome. Dan On 3/22/16 3:35 PM, Daniel D. Daugherty wrote: > Greetings, > > As a follow on to my fix for the following bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > I have a fix for the following bug: > > JDK-8152358 code and comment cleanups found during the hunt for > 8077392 > https://bugs.openjdk.java.net/browse/JDK-8152358 > > These cleanups are pretty straight forward so I'm not going to > include the usual long, detailed analysis... :-) > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ > > This webrev is a superset of the webrev for the JDK-8077392 and > JDK-8131715 fixes and is the code that I'm currently testing... > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan > From calvin.cheung at oracle.com Thu Mar 31 00:07:24 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 30 Mar 2016 17:07:24 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56F54047.1010306@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> Message-ID: <56FC6A3C.8@oracle.com> Hi, I needed to update the webrev to handle the -Xbootclasspath/a. To be consistent with non-CDS case, the versioned entries in a multi-release jar will be ignored if the jar is found in the -Xbootclasspath/a. Summary of changes: - added a bool _is_boot_entry to the ClassPathZipEntry; - added a bool parameter to the functions (create_class_path_entry, create_class_path_zip_entry, etc.) which creates a ClassPathZipEntry; - open_versioned_entry and is_multiple_versioned are CDS only functions. webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ Testing: JPRT RBT tests on hotspot_runtime thanks, Calvin On 3/25/16, 6:42 AM, Coleen Phillimore wrote: > > Hi Calvin, > I didn't really review this but could you add a // INCLUDE_CDS on the > #endif in this code. > > http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html > > > Thanks, > Coleen > > On 3/24/16 8:40 PM, Calvin Cheung wrote: >> Hi Jiangli, >> >> I agreed with both of your comments. >> >> On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> I have two comments below. >>> >>> - I?d suggest putting the new block of code (added in open_stream()) >>> in a separate function. The new function should be defined for >>> CDS_ONLY. >>> >>> - In the bug report, it is suggested that the search for versioned >>> class stops at 8. The changes in the webrev search all versions down >>> to 6. Could you please verify what the spec says. The VM behavior >>> should be the same a the JDK library code. >> I've checked that the base version is set to 8 in java.util.jar.JarFile. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ >> >> thanks, >> Calvin >> >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 18, 2016, at 1:51 PM, Calvin >>>> Cheung wrote: >>>> >>>> >>>> This fix was reviewed in Aug 2015[1] though most of the review >>>> comments was via internal mailing list. Recently, the JEP 238 >>>> (Multiple-Release jar files) has been checked into jdk9. So it is >>>> time to make the corresponding changes in hotspot. >>>> >>>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>>> (unfortunately the bug was marked as "confidential") >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>>> >>>> Some adjustments need to be made due to: >>>> - attribute name in the jar manifest has been changed to >>>> "Multi-release"; >>>> - system property has been changed to >>>> jdk.util.jar.enableMultiRelease and it has value of "true", "force" >>>> or "false". >>>> >>>> The diff between this patch and the reviewed patch is as follows: >>>> >>>> 11c11 >>>> < + const char* multi_ver = >>>> Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>>> --- >>>>> + const char* multi_ver = >>>>> Arguments::get_property("jdk.util.jar.multiversion"); >>>> 14c14 >>>> < + strcmp(multi_ver, "true") == 0 || >>>> --- >>>>> + strcmp(multi_ver, "enable") == 0 || >>>> 64c64 >>>> < @@ -296,6 +345,17 @@ >>>> --- >>>>> @@ -272,6 +321,17 @@ >>>> 72c72 >>>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>>> --- >>>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>>> thanks, >>>> Calvin >>>> >>>> [1]: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html > From varming at gmail.com Thu Mar 31 00:43:18 2016 From: varming at gmail.com (Carsten Varming) Date: Wed, 30 Mar 2016 20:43:18 -0400 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56FC68CC.601@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56FC68CC.601@oracle.com> Message-ID: Dear Dan, I like the updates to synchronizer.cpp. Nice change. Carsten On Wed, Mar 30, 2016 at 8:01 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > I've updated the fix for 8152358 based on code review comments and > test results. Reminder that 8152358 is a superset of the fixes for > 8077392 and 8131715... > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/1-jdk9-hs-rt/ > > The files changed in this round relative to round 0: > > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > Copyright update. > > src/share/vm/runtime/sharedRuntime.cpp > > > Changed to disable ObjectSynchronizer::quick_enter() for ARM64 > since testing has shown that ARM64 still has hangs when the > quick_enter() optimization is enabled. See: > > JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes > hangs > https://bugs.openjdk.java.net/browse/JDK-8153107 > > I suspect a mis-match between the quick_enter() optimization > and the ARM64 MacroAssembler code... > > src/share/vm/runtime/synchronizer.cpp > > > Moved the init of the BasicLock's displaced_header to be > unconditional instead of only when Atomic::cmpxchg_ptr() > works. See the more detailed comments. > > Also fixed a code review request to rename the 'Lock' param. > > > > Rework ObjectSynchronizer::fast_exit() comments, assert()'s > and included code due to code review comments. This includes > new comments explaining the special case where the BasicLock's > displaced_header is marked as a recursive enter and we have an > inflated Java Monitor (ObjectMonitor). The updated assert()'s > and comments also address the markOopDesc::INFLATING special > case in this function. Absolutely exciting reading here! > > Redoing all the same testing... plus adding a fastdebug instance > to the stress config... > > As always, comments, suggestions and/or questions are welcome. > > Dan > > > On 3/22/16 3:35 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> As a follow on to my fix for the following bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> I have a fix for the following bug: >> >> JDK-8152358 code and comment cleanups found during the hunt for >> 8077392 >> https://bugs.openjdk.java.net/browse/JDK-8152358 >> >> These cleanups are pretty straight forward so I'm not going to >> include the usual long, detailed analysis... :-) >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ >> >> This webrev is a superset of the webrev for the JDK-8077392 and >> JDK-8131715 fixes and is the code that I'm currently testing... >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan >> >> > From jiangli.zhou at oracle.com Thu Mar 31 01:06:28 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 30 Mar 2016 18:06:28 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56FC6A3C.8@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> <56FC6A3C.8@oracle.com> Message-ID: <908F986C-5924-4BB7-A7EC-87A36C0BFA7F@oracle.com> Hi Calvin, Looks good. I have a minor comment. I would suggest to rename ?_is_boot_entry? to ?_is_boot_append? or ?_is_boot_append_entry?. Thanks, Jiangli > On Mar 30, 2016, at 5:07 PM, Calvin Cheung wrote: > > Hi, > > I needed to update the webrev to handle the -Xbootclasspath/a. > To be consistent with non-CDS case, the versioned entries in a multi-release jar will be ignored if the jar is found in the -Xbootclasspath/a. > Summary of changes: > - added a bool _is_boot_entry to the ClassPathZipEntry; > - added a bool parameter to the functions (create_class_path_entry, create_class_path_zip_entry, etc.) which creates a ClassPathZipEntry; > - open_versioned_entry and is_multiple_versioned are CDS only functions. > > webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ > > Testing: > JPRT > RBT tests on hotspot_runtime > > thanks, > Calvin > > On 3/25/16, 6:42 AM, Coleen Phillimore wrote: >> >> Hi Calvin, >> I didn't really review this but could you add a // INCLUDE_CDS on the #endif in this code. >> >> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html >> >> Thanks, >> Coleen >> >> On 3/24/16 8:40 PM, Calvin Cheung wrote: >>> Hi Jiangli, >>> >>> I agreed with both of your comments. >>> >>> On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >>>> Hi Calvin, >>>> >>>> I have two comments below. >>>> >>>> - I?d suggest putting the new block of code (added in open_stream()) in a separate function. The new function should be defined for CDS_ONLY. >>>> >>>> - In the bug report, it is suggested that the search for versioned class stops at 8. The changes in the webrev search all versions down to 6. Could you please verify what the spec says. The VM behavior should be the same a the JDK library code. >>> I've checked that the base version is set to 8 in java.util.jar.JarFile. >>> >>> Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ >>> >>> thanks, >>> Calvin >>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 18, 2016, at 1:51 PM, Calvin Cheung wrote: >>>>> >>>>> >>>>> This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. >>>>> >>>>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>>>> (unfortunately the bug was marked as "confidential") >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>>>> >>>>> Some adjustments need to be made due to: >>>>> - attribute name in the jar manifest has been changed to "Multi-release"; >>>>> - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". >>>>> >>>>> The diff between this patch and the reviewed patch is as follows: >>>>> >>>>> 11c11 >>>>> < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>>>> --- >>>>>> + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); >>>>> 14c14 >>>>> < + strcmp(multi_ver, "true") == 0 || >>>>> --- >>>>>> + strcmp(multi_ver, "enable") == 0 || >>>>> 64c64 >>>>> < @@ -296,6 +345,17 @@ >>>>> --- >>>>>> @@ -272,6 +321,17 @@ >>>>> 72c72 >>>>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>>>> --- >>>>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>>>> thanks, >>>>> Calvin >>>>> >>>>> [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html >> From yumin.qi at gmail.com Thu Mar 31 01:43:26 2016 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 31 Mar 2016 09:43:26 +0800 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56FC6A3C.8@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> <56FC6A3C.8@oracle.com> Message-ID: It looks good to me. (I still not a 'R'eviewer). Thanks Yumin On Thu, Mar 31, 2016 at 8:07 AM, Calvin Cheung wrote: > Hi, > > I needed to update the webrev to handle the -Xbootclasspath/a. > To be consistent with non-CDS case, the versioned entries in a > multi-release jar will be ignored if the jar is found in the > -Xbootclasspath/a. > Summary of changes: > - added a bool _is_boot_entry to the ClassPathZipEntry; > - added a bool parameter to the functions (create_class_path_entry, > create_class_path_zip_entry, etc.) which creates a ClassPathZipEntry; > - open_versioned_entry and is_multiple_versioned are CDS only functions. > > webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ > > Testing: > JPRT > RBT tests on hotspot_runtime > > thanks, > Calvin > > > On 3/25/16, 6:42 AM, Coleen Phillimore wrote: > >> >> Hi Calvin, >> I didn't really review this but could you add a // INCLUDE_CDS on the >> #endif in this code. >> >> >> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html >> >> Thanks, >> Coleen >> >> On 3/24/16 8:40 PM, Calvin Cheung wrote: >> >>> Hi Jiangli, >>> >>> I agreed with both of your comments. >>> >>> On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >>> >>>> Hi Calvin, >>>> >>>> I have two comments below. >>>> >>>> - I?d suggest putting the new block of code (added in open_stream()) in >>>> a separate function. The new function should be defined for CDS_ONLY. >>>> >>>> - In the bug report, it is suggested that the search for versioned >>>> class stops at 8. The changes in the webrev search all versions down to 6. >>>> Could you please verify what the spec says. The VM behavior should be the >>>> same a the JDK library code. >>>> >>> I've checked that the base version is set to 8 in java.util.jar.JarFile. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ >>> >>> thanks, >>> Calvin >>> >>> >>>> Thanks, >>>> Jiangli >>>> >>>> On Mar 18, 2016, at 1:51 PM, Calvin Cheung >>>>> wrote: >>>>> >>>>> >>>>> This fix was reviewed in Aug 2015[1] though most of the review >>>>> comments was via internal mailing list. Recently, the JEP 238 >>>>> (Multiple-Release jar files) has been checked into jdk9. So it is time to >>>>> make the corresponding changes in hotspot. >>>>> >>>>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>>>> (unfortunately the bug was marked as "confidential") >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>>>> >>>>> Some adjustments need to be made due to: >>>>> - attribute name in the jar manifest has been changed to >>>>> "Multi-release"; >>>>> - system property has been changed to jdk.util.jar.enableMultiRelease >>>>> and it has value of "true", "force" or "false". >>>>> >>>>> The diff between this patch and the reviewed patch is as follows: >>>>> >>>>> 11c11 >>>>> < + const char* multi_ver = >>>>> Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>>>> --- >>>>> >>>>>> + const char* multi_ver = >>>>>> Arguments::get_property("jdk.util.jar.multiversion"); >>>>>> >>>>> 14c14 >>>>> < + strcmp(multi_ver, "true") == 0 || >>>>> --- >>>>> >>>>>> + strcmp(multi_ver, "enable") == 0 || >>>>>> >>>>> 64c64 >>>>> < @@ -296,6 +345,17 @@ >>>>> --- >>>>> >>>>>> @@ -272,6 +321,17 @@ >>>>>> >>>>> 72c72 >>>>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>>>> --- >>>>> >>>>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> [1]: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html >>>>> >>>> >> From serguei.spitsyn at oracle.com Thu Mar 31 02:52:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Mar 2016 19:52:49 -0700 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FC5BE7.2080009@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> Message-ID: <56FC9101.9020103@oracle.com> Hi Andreas, One simple question so far: Should the _deallocate_list be set to NULL after deletion at L428: 424 ClassLoaderData::~ClassLoaderData() { 425 // Delete free list 426 if (_deallocate_list != NULL) { 427 free_deallocate_list(); 428 delete _deallocate_list; 429 } 430 Thanks, Serguei On 3/30/16 16:06, Coleen Phillimore wrote: > > Andreas, > > Good find! This seems like a safe fix. It's unfortunate to have to > walk the deallocate list, but I think it's short enough and less work > in comparison to having to call free_C_heap_structures on all the > other classes in the dead class loader data. And deallocate_contents > removes the scratch_class from the CLD _klasses list so won't walk it > twice. > > This is really good. > > Coleen > > On 3/30/16 8:12 AM, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for 8135322: >> ConstantPool::release_C_heap_structures not run in some circumstances. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >> >> The way this occurs is: >> >> 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is >> created during class redefinition. >> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not >> cleaned up by ClassLoaderDataGraph::do_unloading because the holding >> ClassLoaderData is already dead. >> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >> InstanceKlass::release_C_heap_structures, which in turn will call >> ConstantPool::release_C_heap_structures. But since there is no >> corresponding InstanceKlass for /merge_cp/ it will never release its >> C heap structures. >> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >> JDK 9 the Monitor has been removed, but we will miss doing a call to >> ConstantPool::unreference_symbols, which is probably not good either. >> >> >> This change adds a call to free everything in the _deallocate_list >> first thing in ClassLoaderData::~ClassLoaderData. >> >> Note: >> Running deallocate_contents() on everything in the list might be >> doing unnecessary work: >> What we really would like to do is run release_C_heap_structures() on >> constant pools in the list that do not have a corresponding >> InstanceKlass. Not sure it's worth the effort to do the filtering, >> since I believe the _deallocate_list is usually not that long. >> >> Note 2: >> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >> more immediately visible effect. >> >> Regards, >> Andreas >> > From serguei.spitsyn at oracle.com Thu Mar 31 03:02:07 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Mar 2016 20:02:07 -0700 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FC9101.9020103@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> <56FC9101.9020103@oracle.com> Message-ID: <56FC932F.7030703@oracle.com> On 3/30/16 19:52, serguei.spitsyn at oracle.com wrote: > Hi Andreas, > > > One simple question so far: > Should the _deallocate_list be set to NULL after deletion at L428: > 424 ClassLoaderData::~ClassLoaderData() { > 425 // Delete free list > 426 if (_deallocate_list != NULL) { > 427 free_deallocate_list(); > 428 delete _deallocate_list; > 429 } > 430 Please, skip my question. It is too paranoid to do so. :) Thanks, Serguei > > > Thanks, > Serguei > > > On 3/30/16 16:06, Coleen Phillimore wrote: >> >> Andreas, >> >> Good find! This seems like a safe fix. It's unfortunate to have to >> walk the deallocate list, but I think it's short enough and less work >> in comparison to having to call free_C_heap_structures on all the >> other classes in the dead class loader data. And >> deallocate_contents removes the scratch_class from the CLD _klasses >> list so won't walk it twice. >> >> This is really good. >> >> Coleen >> >> On 3/30/16 8:12 AM, Andreas Eriksson wrote: >>> Hi, >>> >>> Please review this fix for 8135322: >>> ConstantPool::release_C_heap_structures not run in some circumstances. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >>> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >>> >>> The way this occurs is: >>> >>> 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is >>> created during class redefinition. >>> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not >>> cleaned up by ClassLoaderDataGraph::do_unloading because the holding >>> ClassLoaderData is already dead. >>> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >>> InstanceKlass::release_C_heap_structures, which in turn will call >>> ConstantPool::release_C_heap_structures. But since there is no >>> corresponding InstanceKlass for /merge_cp/ it will never release its >>> C heap structures. >>> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >>> JDK 9 the Monitor has been removed, but we will miss doing a call to >>> ConstantPool::unreference_symbols, which is probably not good >>> either. >>> >>> >>> This change adds a call to free everything in the _deallocate_list >>> first thing in ClassLoaderData::~ClassLoaderData. >>> >>> Note: >>> Running deallocate_contents() on everything in the list might be >>> doing unnecessary work: >>> What we really would like to do is run release_C_heap_structures() >>> on constant pools in the list that do not have a corresponding >>> InstanceKlass. Not sure it's worth the effort to do the filtering, >>> since I believe the _deallocate_list is usually not that long. >>> >>> Note 2: >>> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >>> more immediately visible effect. >>> >>> Regards, >>> Andreas >>> >> > From daniel.daugherty at oracle.com Thu Mar 31 04:18:36 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2016 22:18:36 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: References: <56F1BAB0.2000001@oracle.com> <56FC68CC.601@oracle.com> Message-ID: <56FCA51C.7060408@oracle.com> Carsten, Thanks for the fast re-review! Dan On 3/30/16 6:43 PM, Carsten Varming wrote: > Dear Dan, > > I like the updates to synchronizer.cpp. Nice change. > > Carsten > > On Wed, Mar 30, 2016 at 8:01 PM, Daniel D. Daugherty > > wrote: > > I've updated the fix for 8152358 based on code review comments and > test results. Reminder that 8152358 is a superset of the fixes for > 8077392 and 8131715... > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/1-jdk9-hs-rt/ > > > The files changed in this round relative to round 0: > > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > Copyright update. > > src/share/vm/runtime/sharedRuntime.cpp > > > Changed to disable ObjectSynchronizer::quick_enter() for ARM64 > since testing has shown that ARM64 still has hangs when the > quick_enter() optimization is enabled. See: > > JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 > causes hangs > https://bugs.openjdk.java.net/browse/JDK-8153107 > > I suspect a mis-match between the quick_enter() optimization > and the ARM64 MacroAssembler code... > > src/share/vm/runtime/synchronizer.cpp > > > Moved the init of the BasicLock's displaced_header to be > unconditional instead of only when Atomic::cmpxchg_ptr() > works. See the more detailed comments. > > Also fixed a code review request to rename the 'Lock' param. > > > > Rework ObjectSynchronizer::fast_exit() comments, assert()'s > and included code due to code review comments. This includes > new comments explaining the special case where the BasicLock's > displaced_header is marked as a recursive enter and we have an > inflated Java Monitor (ObjectMonitor). The updated assert()'s > and comments also address the markOopDesc::INFLATING special > case in this function. Absolutely exciting reading here! > > Redoing all the same testing... plus adding a fastdebug instance > to the stress config... > > As always, comments, suggestions and/or questions are welcome. > > Dan > > > On 3/22/16 3:35 PM, Daniel D. Daugherty wrote: > > Greetings, > > As a follow on to my fix for the following bugs: > > JDK-8077392 Stream fork/join tasks occasionally fail to > complete > https://bugs.openjdk.java.net/browse/JDK-8077392 > > JDK-8131715 backout the fix for JDK-8079359 when > JDK-8077392 is fixed > https://bugs.openjdk.java.net/browse/JDK-8131715 > > I have a fix for the following bug: > > JDK-8152358 code and comment cleanups found during the > hunt for 8077392 > https://bugs.openjdk.java.net/browse/JDK-8152358 > > These cleanups are pretty straight forward so I'm not going to > include the usual long, detailed analysis... :-) > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ > > This webrev is a superset of the webrev for the JDK-8077392 and > JDK-8131715 fixes and is the code that I'm currently testing... > > Testing: > > - the original failing test is running in a parallel stress config > on my Solaris X64 server; just under 23 hours and just under > 3000 iterations without a failure in either instance; I'm > planning > to let the stress run go for at least 72 hours. > - RT/SVC nightly equivalent (in progress) > > As always, comments, suggestions and/or questions are welcome. > > Dan > > > From vladimir.kozlov at oracle.com Thu Mar 31 05:21:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Mar 2016 22:21:59 -0700 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56F9BBE6.10207@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> Message-ID: <56FCB3F7.6050403@oracle.com> Sorry for later reply when you send updated webrev already. You changed code in OSR_migration_begin(): - int buf_size_words = max_locals + active_monitor_count*2; + int buf_size_words = max_locals + active_monitor_count * (sizeof(BasicObjectLock) / wordSize); I am suggesting next: + int buf_size_words = max_locals + active_monitor_count * BasicObjectLock::size(); Thanks, Vladimir On 3/28/16 4:19 PM, Daniel D. Daugherty wrote: > On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: >> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >>> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did in c1_LIRAssembler_x86.cpp >> >> I'll take a look. I may leave that cleanup to another pass, if >> you would be OK with it... I'm nearing the end of my 72 hour >> stress test cycle and don't want to repeat it... :-) > > Here's the C1 change: > > $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 2016 -0800 > +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 2016 -0700 > @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { > Register OSR_buf = osrBufferPointer()->as_pointer_register(); > { assert(frame::interpreter_frame_monitor_size() == BasicObjectLock::size(), "adjust code below"); > int monitor_offset = BytesPerWord * method()->max_locals() + > - (2 * BytesPerWord) * (number_of_locks - 1); > + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - 1); > // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in > // the OSR buffer using 2 word entries: first the lock and then > // the oop. > > > Here's the existing code in SharedRuntime::OSR_migration_begin(): > > // Allocate temp buffer, 1 word per local & 2 per active monitor > int buf_size_words = max_locals + active_monitor_count * (sizeof(BasicObjectLock) / wordSize); > intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); > > > so is your suggestion to change: > > sizeof(BasicObjectLock) / wordSize > > to: > > BasicObjectLock::size() > > or am I misunderstanding what you mean? > > Dan > From calvin.cheung at oracle.com Thu Mar 31 05:31:36 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 30 Mar 2016 22:31:36 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <908F986C-5924-4BB7-A7EC-87A36C0BFA7F@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> <56FC6A3C.8@oracle.com> <908F986C-5924-4BB7-A7EC-87A36C0BFA7F@oracle.com> Message-ID: <56FCB638.2000405@oracle.com> Hi Jiangli, On 3/30/16, 6:06 PM, Jiangli Zhou wrote: > Hi Calvin, > > Looks good. Thanks for your quick review. > I have a minor comment. I would suggest to rename ?_is_boot_entry? to ?_is_boot_append? or ?_is_boot_append_entry?. I've picked '_is_boot_append'. Updated webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.03/ Just the changes between webrev.02 and 03: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02-03/ thanks, Calvin > > Thanks, > Jiangli > >> On Mar 30, 2016, at 5:07 PM, Calvin Cheung wrote: >> >> Hi, >> >> I needed to update the webrev to handle the -Xbootclasspath/a. >> To be consistent with non-CDS case, the versioned entries in a multi-release jar will be ignored if the jar is found in the -Xbootclasspath/a. >> Summary of changes: >> - added a bool _is_boot_entry to the ClassPathZipEntry; >> - added a bool parameter to the functions (create_class_path_entry, create_class_path_zip_entry, etc.) which creates a ClassPathZipEntry; >> - open_versioned_entry and is_multiple_versioned are CDS only functions. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ >> >> Testing: >> JPRT >> RBT tests on hotspot_runtime >> >> thanks, >> Calvin >> >> On 3/25/16, 6:42 AM, Coleen Phillimore wrote: >>> Hi Calvin, >>> I didn't really review this but could you add a // INCLUDE_CDS on the #endif in this code. >>> >>> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html >>> >>> Thanks, >>> Coleen >>> >>> On 3/24/16 8:40 PM, Calvin Cheung wrote: >>>> Hi Jiangli, >>>> >>>> I agreed with both of your comments. >>>> >>>> On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >>>>> Hi Calvin, >>>>> >>>>> I have two comments below. >>>>> >>>>> - I?d suggest putting the new block of code (added in open_stream()) in a separate function. The new function should be defined for CDS_ONLY. >>>>> >>>>> - In the bug report, it is suggested that the search for versioned class stops at 8. The changes in the webrev search all versions down to 6. Could you please verify what the spec says. The VM behavior should be the same a the JDK library code. >>>> I've checked that the base version is set to 8 in java.util.jar.JarFile. >>>> >>>> Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ >>>> >>>> thanks, >>>> Calvin >>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Mar 18, 2016, at 1:51 PM, Calvin Cheung wrote: >>>>>> >>>>>> >>>>>> This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. >>>>>> >>>>>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>>>>> (unfortunately the bug was marked as "confidential") >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>>>>> >>>>>> Some adjustments need to be made due to: >>>>>> - attribute name in the jar manifest has been changed to "Multi-release"; >>>>>> - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". >>>>>> >>>>>> The diff between this patch and the reviewed patch is as follows: >>>>>> >>>>>> 11c11 >>>>>> < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>>>>> --- >>>>>>> + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); >>>>>> 14c14 >>>>>> < + strcmp(multi_ver, "true") == 0 || >>>>>> --- >>>>>>> + strcmp(multi_ver, "enable") == 0 || >>>>>> 64c64 >>>>>> < @@ -296,6 +345,17 @@ >>>>>> --- >>>>>>> @@ -272,6 +321,17 @@ >>>>>> 72c72 >>>>>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>>>>> --- >>>>>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>>>>> thanks, >>>>>> Calvin >>>>>> >>>>>> [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From calvin.cheung at oracle.com Thu Mar 31 05:37:45 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 30 Mar 2016 22:37:45 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> <56FC6A3C.8@oracle.com> Message-ID: <56FCB7A9.8040402@oracle.com> Yumin, Thanks for your review. Calvin On 3/30/16, 6:43 PM, yumin qi wrote: > It looks good to me. (I still not a 'R'eviewer). > > Thanks > Yumin > > On Thu, Mar 31, 2016 at 8:07 AM, Calvin Cheung > > wrote: > > Hi, > > I needed to update the webrev to handle the -Xbootclasspath/a. > To be consistent with non-CDS case, the versioned entries in a > multi-release jar will be ignored if the jar is found in the > -Xbootclasspath/a. > Summary of changes: > - added a bool _is_boot_entry to the ClassPathZipEntry; > - added a bool parameter to the functions > (create_class_path_entry, create_class_path_zip_entry, etc.) which > creates a ClassPathZipEntry; > - open_versioned_entry and is_multiple_versioned are CDS only > functions. > > webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ > > > Testing: > JPRT > RBT tests on hotspot_runtime > > thanks, > Calvin > > > On 3/25/16, 6:42 AM, Coleen Phillimore wrote: > > > Hi Calvin, > I didn't really review this but could you add a // INCLUDE_CDS > on the #endif in this code. > > http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html > > > > Thanks, > Coleen > > On 3/24/16 8:40 PM, Calvin Cheung wrote: > > Hi Jiangli, > > I agreed with both of your comments. > > On 3/23/16, 4:24 PM, Jiangli Zhou wrote: > > Hi Calvin, > > I have two comments below. > > - I?d suggest putting the new block of code (added in > open_stream()) in a separate function. The new > function should be defined for CDS_ONLY. > > - In the bug report, it is suggested that the search > for versioned class stops at 8. The changes in the > webrev search all versions down to 6. Could you please > verify what the spec says. The VM behavior should be > the same a the JDK library code. > > I've checked that the base version is set to 8 in > java.util.jar.JarFile. > > Here's an updated webrev: > http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ > > > thanks, > Calvin > > > Thanks, > Jiangli > > On Mar 18, 2016, at 1:51 PM, Calvin > Cheung > wrote: > > > This fix was reviewed in Aug 2015[1] though most > of the review comments was via internal mailing > list. Recently, the JEP 238 (Multiple-Release jar > files) has been checked into jdk9. So it is time > to make the corresponding changes in hotspot. > > JBS: bug: > https://bugs.openjdk.java.net/browse/JDK-8075253 > (unfortunately the bug was marked as > "confidential") > > webrev: > http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ > > > Some adjustments need to be made due to: > - attribute name in the jar manifest has been > changed to "Multi-release"; > - system property has been changed to > jdk.util.jar.enableMultiRelease and it has value > of "true", "force" or "false". > > The diff between this patch and the reviewed patch > is as follows: > > 11c11 > < + const char* multi_ver = > Arguments::get_property("jdk.util.jar.enableMultiRelease"); > --- > > + const char* multi_ver = > Arguments::get_property("jdk.util.jar.multiversion"); > > 14c14 > < + strcmp(multi_ver, > "true") == 0 || > --- > > + strcmp(multi_ver, "enable") == 0 || > > 64c64 > < @@ -296,6 +345,17 @@ > --- > > @@ -272,6 +321,17 @@ > > 72c72 > < + if (strstr(buffer, "Multi-Release: true") > != NULL) { > --- > > + if (strstr(buffer, "Multiversion: true") > != NULL) { > > thanks, > Calvin > > [1]: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html > > > From chris.plummer at oracle.com Thu Mar 31 06:20:41 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 30 Mar 2016 23:20:41 -0700 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported Message-ID: <56FCC1B9.3060007@oracle.com> 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 marcus.larsson at oracle.com Thu Mar 31 07:26:02 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 31 Mar 2016 09:26:02 +0200 Subject: RFR: 8146879: Add option for handling existing log files in UL In-Reply-To: References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com> <56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com> <56EBFCCC.1080701@oracle.com> <56FBDFE1.9040202@oracle.com> Message-ID: <56FCD10A.6050200@oracle.com> Thanks for reviewing! Marcus On 03/30/2016 06:16 PM, Gerard Ziemski wrote: > Look good. > > Thank you for you patience with my review. > > > cheers > >> On Mar 30, 2016, at 9:17 AM, Marcus Larsson wrote: >> >> Hi Gerard, >> >> On 03/22/2016 07:15 PM, Gerard Ziemski wrote: >>> hi Marcus, >>> >>> Thank you for incorporating the feedback. >>> >>> The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line. >>> >>> May I suggest the following implementation instead: >>> >>> static size_t number_of_lines_with_substring_in_file(const char* filename, >>> const char* substr) { >>> ResourceMark rm; >>> size_t ret = 0; >>> FILE* fp = fopen(filename, "r"); >>> assert(fp, "error opening file %s: %s", filename, strerror(errno)); >>> >>> int buflen = 512; >>> char* buf = NEW_RESOURCE_ARRAY(char, buflen); >>> long int pos = 0; >>> >>> while (fgets(buf, buflen, fp) != NULL) { >>> if (buf[strlen(buf) - 1] != '\n') { >>> // rewind to the beginning of the line >>> fseek(fp, pos, SEEK_SET); >>> // double the buffer size and try again >>> buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen); >>> buflen *= 2; >>> } else { >>> // get current file position >>> pos = ftell(fp); >>> >>> if (strstr(buf, substr) != NULL) { >>> ret++; >>> } >>> } >>> } >>> >>> fclose(fp); >>> return ret; >>> } >> Alright, fixed. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/ >> >> Also fixed some failing tests caused by this patch in the previous round of changes. >> >> Thanks, >> Marcus >> >>> cheers >>> >>> >>>> On Mar 18, 2016, at 8:04 AM, Marcus Larsson wrote: >>>> >>>> Updated patch after feedback. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/ >>>> >>>> Tested with internal VM tests through RBT. >>>> >>>> Changes: >>>> * Rotation filecount is now limited to 1000 files. >>>> * Removed loop in os::compare_file_modified_times. >>>> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file. >>>> * Added test case to check that logging to a directory gives the intended error message. >>>> * Fixed test help method to handle arbitrary length log lines. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 03/11/2016 03:21 PM, Marcus Larsson wrote: >>>>> Third time's the charm. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/ >>>>> >>>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0). >>>>> >>>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file. >>>>> >>>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know. >>>>> >>>>> Tested with included internal VM tests through RBT. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 2016-03-01 15:05, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote: >>>>>>> Hi again, >>>>>>> >>>>>>> Taking a different approach to this. >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/ >>>>>>> >>>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate). >>>>>>> >>>>>>> Tested with included jtreg test through JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/ >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879 >>>>>>>> >>>>>>>> Testing: >>>>>>>> Included test through JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus From serguei.spitsyn at oracle.com Thu Mar 31 07:38:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Mar 2016 00:38:44 -0700 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported In-Reply-To: <56FCC1B9.3060007@oracle.com> References: <56FCC1B9.3060007@oracle.com> Message-ID: <56FCD404.8030601@oracle.com> 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 marcus.larsson at oracle.com Thu Mar 31 07:48:18 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 31 Mar 2016 09:48:18 +0200 Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <56FBDE02.2030900@gmail.com> References: <56FBDE02.2030900@gmail.com> Message-ID: <56FCD642.3000107@oracle.com> 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 Mar 31 09:24:42 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 18:24:42 +0900 Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <56FCD642.3000107@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> Message-ID: <56FCECDA.3070204@gmail.com> 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 cheleswer.sahu at oracle.com Thu Mar 31 09:46:55 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 31 Mar 2016 02:46:55 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: 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> Message-ID: 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(cons >>>>>>>> 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 andreas.eriksson at oracle.com Thu Mar 31 10:00:38 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 31 Mar 2016 12:00:38 +0200 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FC5BE7.2080009@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> Message-ID: <56FCF546.2060809@oracle.com> Thanks Coleen! - Andreas On 2016-03-31 01:06, Coleen Phillimore wrote: > > Andreas, > > Good find! This seems like a safe fix. It's unfortunate to have to > walk the deallocate list, but I think it's short enough and less work > in comparison to having to call free_C_heap_structures on all the > other classes in the dead class loader data. And deallocate_contents > removes the scratch_class from the CLD _klasses list so won't walk it > twice. > > This is really good. > > Coleen > > On 3/30/16 8:12 AM, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for 8135322: >> ConstantPool::release_C_heap_structures not run in some circumstances. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >> >> The way this occurs is: >> >> 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is >> created during class redefinition. >> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not >> cleaned up by ClassLoaderDataGraph::do_unloading because the holding >> ClassLoaderData is already dead. >> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >> InstanceKlass::release_C_heap_structures, which in turn will call >> ConstantPool::release_C_heap_structures. But since there is no >> corresponding InstanceKlass for /merge_cp/ it will never release its >> C heap structures. >> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >> JDK 9 the Monitor has been removed, but we will miss doing a call to >> ConstantPool::unreference_symbols, which is probably not good either. >> >> >> This change adds a call to free everything in the _deallocate_list >> first thing in ClassLoaderData::~ClassLoaderData. >> >> Note: >> Running deallocate_contents() on everything in the list might be >> doing unnecessary work: >> What we really would like to do is run release_C_heap_structures() on >> constant pools in the list that do not have a corresponding >> InstanceKlass. Not sure it's worth the effort to do the filtering, >> since I believe the _deallocate_list is usually not that long. >> >> Note 2: >> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >> more immediately visible effect. >> >> Regards, >> Andreas >> > From andreas.eriksson at oracle.com Thu Mar 31 10:01:45 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 31 Mar 2016 12:01:45 +0200 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FC932F.7030703@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> <56FC9101.9020103@oracle.com> <56FC932F.7030703@oracle.com> Message-ID: <56FCF589.9030203@oracle.com> On 2016-03-31 05:02, serguei.spitsyn at oracle.com wrote: > On 3/30/16 19:52, serguei.spitsyn at oracle.com wrote: >> Hi Andreas, >> >> >> One simple question so far: >> Should the _deallocate_list be set to NULL after deletion at L428: >> 424 ClassLoaderData::~ClassLoaderData() { >> 425 // Delete free list >> 426 if (_deallocate_list != NULL) { >> 427 free_deallocate_list(); >> 428 delete _deallocate_list; >> 429 } >> 430 > > Please, skip my question. > It is too paranoid to do so. :) Alright, thanks for looking at this! - Andreas > > > Thanks, > Serguei > > >> >> >> Thanks, >> Serguei >> >> >> On 3/30/16 16:06, Coleen Phillimore wrote: >>> >>> Andreas, >>> >>> Good find! This seems like a safe fix. It's unfortunate to have to >>> walk the deallocate list, but I think it's short enough and less >>> work in comparison to having to call free_C_heap_structures on all >>> the other classes in the dead class loader data. And >>> deallocate_contents removes the scratch_class from the CLD _klasses >>> list so won't walk it twice. >>> >>> This is really good. >>> >>> Coleen >>> >>> On 3/30/16 8:12 AM, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Please review this fix for 8135322: >>>> ConstantPool::release_C_heap_structures not run in some circumstances. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >>>> >>>> The way this occurs is: >>>> >>>> 1. A ConstantPool, /merge_cp/, without a corresponding >>>> InstanceKlass is >>>> created during class redefinition. >>>> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is >>>> not >>>> cleaned up by ClassLoaderDataGraph::do_unloading because the >>>> holding >>>> ClassLoaderData is already dead. >>>> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >>>> InstanceKlass::release_C_heap_structures, which in turn will call >>>> ConstantPool::release_C_heap_structures. But since there is no >>>> corresponding InstanceKlass for /merge_cp/ it will never release >>>> its >>>> C heap structures. >>>> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >>>> JDK 9 the Monitor has been removed, but we will miss doing a >>>> call to >>>> ConstantPool::unreference_symbols, which is probably not good >>>> either. >>>> >>>> >>>> This change adds a call to free everything in the _deallocate_list >>>> first thing in ClassLoaderData::~ClassLoaderData. >>>> >>>> Note: >>>> Running deallocate_contents() on everything in the list might be >>>> doing unnecessary work: >>>> What we really would like to do is run release_C_heap_structures() >>>> on constant pools in the list that do not have a corresponding >>>> InstanceKlass. Not sure it's worth the effort to do the filtering, >>>> since I believe the _deallocate_list is usually not that long. >>>> >>>> Note 2: >>>> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >>>> more immediately visible effect. >>>> >>>> Regards, >>>> Andreas >>>> >>> >> > From marcus.larsson at oracle.com Thu Mar 31 10:13:46 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 31 Mar 2016 12:13:46 +0200 Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <56FCECDA.3070204@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> Message-ID: <56FCF85A.7010908@oracle.com> Hi, On 03/31/2016 11:24 AM, 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/ Looks good! I can sponsor. Marcus > > > 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 Mar 31 12:50:29 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 21:50:29 +0900 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant Message-ID: <56FD1D15.2060703@gmail.com> 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/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From marcus.larsson at oracle.com Thu Mar 31 13:11:38 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 31 Mar 2016 15:11:38 +0200 Subject: RFR: JDK-8153191: UL: Separator in VM.log output is redundant In-Reply-To: <56FD1D15.2060703@gmail.com> References: <56FD1D15.2060703@gmail.com> Message-ID: <56FD220A.2090600@oracle.com> 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 Thu Mar 31 13:30:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 22:30:33 +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: <56FD2679.9030109@gmail.com> 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. Sorry, I was not check it. I closed JDK-8153191 as duplicate. > Also, please note that UL belongs to the serviceability subcomponent, > and patches like this should probably go to the serviceability-dev > mailing list. 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 Thu Mar 31 13:33:44 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 22:33:44 +0900 Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <56FCECDA.3070204@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> Message-ID: <56FD2738.8050500@gmail.com> 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 Mar 31 13:35:02 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Mar 2016 22:35:02 +0900 Subject: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <56FBDE2F.60701@gmail.com> References: <56FBDE2F.60701@gmail.com> Message-ID: <56FD2786.9020102@gmail.com> 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 daniel.daugherty at oracle.com Thu Mar 31 14:37:57 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 31 Mar 2016 08:37:57 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56FCB3F7.6050403@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> <56FCB3F7.6050403@oracle.com> Message-ID: <56FD3645.80007@oracle.com> Thanks for closing the loop on this part of the review... I think we're on the same page about what to change. I have a vague memory of trying to change: int buf_size_words = max_locals + active_monitor_count*2; to: int buf_size_words = max_locals + active_monitor_count * BasicObjectLock::size(); but it didn't compile for some reason so I went the other way. I'll take a look one more time before pushing the changeset. Still doing stress testing so I have time... Dan On 3/30/16 11:21 PM, Vladimir Kozlov wrote: > Sorry for later reply when you send updated webrev already. > > You changed code in OSR_migration_begin(): > - int buf_size_words = max_locals + active_monitor_count*2; > + int buf_size_words = max_locals + active_monitor_count * > (sizeof(BasicObjectLock) / wordSize); > > I am suggesting next: > > + int buf_size_words = max_locals + active_monitor_count * > BasicObjectLock::size(); > > Thanks, > Vladimir > > On 3/28/16 4:19 PM, Daniel D. Daugherty wrote: >> On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: >>> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >>>> In sharedRuntime.cpp you could use BasicObjectLock::size() as you >>>> did in c1_LIRAssembler_x86.cpp >>> >>> I'll take a look. I may leave that cleanup to another pass, if >>> you would be OK with it... I'm nearing the end of my 72 hour >>> stress test cycle and don't want to repeat it... :-) >> >> Here's the C1 change: >> >> $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 >> 2016 -0800 >> +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 >> 2016 -0700 >> @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { >> Register OSR_buf = osrBufferPointer()->as_pointer_register(); >> { assert(frame::interpreter_frame_monitor_size() == >> BasicObjectLock::size(), "adjust code below"); >> int monitor_offset = BytesPerWord * method()->max_locals() + >> - (2 * BytesPerWord) * (number_of_locks - 1); >> + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - 1); >> // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in >> // the OSR buffer using 2 word entries: first the lock and then >> // the oop. >> >> >> Here's the existing code in SharedRuntime::OSR_migration_begin(): >> >> // Allocate temp buffer, 1 word per local & 2 per active monitor >> int buf_size_words = max_locals + active_monitor_count * >> (sizeof(BasicObjectLock) / wordSize); >> intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); >> >> >> so is your suggestion to change: >> >> sizeof(BasicObjectLock) / wordSize >> >> to: >> >> BasicObjectLock::size() >> >> or am I misunderstanding what you mean? >> >> Dan >> From jiangli.zhou at oracle.com Thu Mar 31 15:05:02 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 31 Mar 2016 08:05:02 -0700 Subject: RFR(S): 8075253: Multiversion JAR feature: CDS does not support MV-JARs In-Reply-To: <56FCB638.2000405@oracle.com> References: <56EC6A3F.7070500@oracle.com> <56F48916.7040604@oracle.com> <56F54047.1010306@oracle.com> <56FC6A3C.8@oracle.com> <908F986C-5924-4BB7-A7EC-87A36C0BFA7F@oracle.com> <56FCB638.2000405@oracle.com> Message-ID: Hi Calvin, The update looks good. Thanks, Jiangli > On Mar 30, 2016, at 10:31 PM, Calvin Cheung wrote: > > Hi Jiangli, > > On 3/30/16, 6:06 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> Looks good. > Thanks for your quick review. >> I have a minor comment. I would suggest to rename ?_is_boot_entry? to ?_is_boot_append? or ?_is_boot_append_entry?. > I've picked '_is_boot_append'. > Updated webrev: > http://cr.openjdk.java.net/~ccheung/8075253/webrev.03/ > > Just the changes between webrev.02 and 03: > http://cr.openjdk.java.net/~ccheung/8075253/webrev.02-03/ > > thanks, > Calvin >> >> Thanks, >> Jiangli >> >>> On Mar 30, 2016, at 5:07 PM, Calvin Cheung wrote: >>> >>> Hi, >>> >>> I needed to update the webrev to handle the -Xbootclasspath/a. >>> To be consistent with non-CDS case, the versioned entries in a multi-release jar will be ignored if the jar is found in the -Xbootclasspath/a. >>> Summary of changes: >>> - added a bool _is_boot_entry to the ClassPathZipEntry; >>> - added a bool parameter to the functions (create_class_path_entry, create_class_path_zip_entry, etc.) which creates a ClassPathZipEntry; >>> - open_versioned_entry and is_multiple_versioned are CDS only functions. >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.02/ >>> >>> Testing: >>> JPRT >>> RBT tests on hotspot_runtime >>> >>> thanks, >>> Calvin >>> >>> On 3/25/16, 6:42 AM, Coleen Phillimore wrote: >>>> Hi Calvin, >>>> I didn't really review this but could you add a // INCLUDE_CDS on the #endif in this code. >>>> >>>> http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/src/share/vm/classfile/classLoader.cpp.udiff.html >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 3/24/16 8:40 PM, Calvin Cheung wrote: >>>>> Hi Jiangli, >>>>> >>>>> I agreed with both of your comments. >>>>> >>>>> On 3/23/16, 4:24 PM, Jiangli Zhou wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> I have two comments below. >>>>>> >>>>>> - I?d suggest putting the new block of code (added in open_stream()) in a separate function. The new function should be defined for CDS_ONLY. >>>>>> >>>>>> - In the bug report, it is suggested that the search for versioned class stops at 8. The changes in the webrev search all versions down to 6. Could you please verify what the spec says. The VM behavior should be the same a the JDK library code. >>>>> I've checked that the base version is set to 8 in java.util.jar.JarFile. >>>>> >>>>> Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.01/ >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Mar 18, 2016, at 1:51 PM, Calvin Cheung wrote: >>>>>>> >>>>>>> >>>>>>> This fix was reviewed in Aug 2015[1] though most of the review comments was via internal mailing list. Recently, the JEP 238 (Multiple-Release jar files) has been checked into jdk9. So it is time to make the corresponding changes in hotspot. >>>>>>> >>>>>>> JBS: bug: https://bugs.openjdk.java.net/browse/JDK-8075253 >>>>>>> (unfortunately the bug was marked as "confidential") >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8075253/webrev.00/ >>>>>>> >>>>>>> Some adjustments need to be made due to: >>>>>>> - attribute name in the jar manifest has been changed to "Multi-release"; >>>>>>> - system property has been changed to jdk.util.jar.enableMultiRelease and it has value of "true", "force" or "false". >>>>>>> >>>>>>> The diff between this patch and the reviewed patch is as follows: >>>>>>> >>>>>>> 11c11 >>>>>>> < + const char* multi_ver = Arguments::get_property("jdk.util.jar.enableMultiRelease"); >>>>>>> --- >>>>>>>> + const char* multi_ver = Arguments::get_property("jdk.util.jar.multiversion"); >>>>>>> 14c14 >>>>>>> < + strcmp(multi_ver, "true") == 0 || >>>>>>> --- >>>>>>>> + strcmp(multi_ver, "enable") == 0 || >>>>>>> 64c64 >>>>>>> < @@ -296,6 +345,17 @@ >>>>>>> --- >>>>>>>> @@ -272,6 +321,17 @@ >>>>>>> 72c72 >>>>>>> < + if (strstr(buffer, "Multi-Release: true") != NULL) { >>>>>>> --- >>>>>>>> + if (strstr(buffer, "Multiversion: true") != NULL) { >>>>>>> thanks, >>>>>>> Calvin >>>>>>> >>>>>>> [1]: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015589.html From max.ockner at oracle.com Thu Mar 31 18:08:28 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 31 Mar 2016 14:08:28 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: References: <56FAD0E3.5090508@oracle.com> Message-ID: <56FD679C.8070803@oracle.com> (Replies in line) On 3/30/2016 9:31 AM, Thomas St?fe wrote: > Hi Max, > > Disclaimer: not a (R)eviewer. > > Do we really need a list of all tags and all decorators? > Just going by what we currently put in the hs_err file, I think this may be the first "Do we really need" we've ever asked for this type of change. All joking aside, I think it is a good idea to direct users toward proper UL usage whenever we have a chance. > Also: I assume what you print is the Log state as it is at the time > the hs-err file is printed. If logging was enabled/changed during > lifetime of the VM, e.g. with jcmd, would it be possible to see that? > At least a warning if logging was not enabled from the start on. > Would it be possible? Yes, but I think this would require a framework change. It does not look like any marks are made when the LogConfiguration changes during runtime, and we would need to record that in order to know what to print when we dump into hs_err. Thanks, Max > Kind Regards, Thomas > > > > > On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner > wrote: > > Hello, > Please review another Unified Logging change. They are almost > done, and we are serious this time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8151526 > webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ > > > The logging configuration is now printed in each hs_err file. The > output is the same as you would see from -Xlog:logging=trace and > it is obtained from LogConfiguration::describe(). > > Below is a sample of the hs_err contents. The Logging info is > printed after VM Arguments and Whitebox, and before Environment > Variables. > > VM Arguments: > java_command: Kaboom > java_class_path (initial): . > Launcher Type: SUN_STANDARD > > Logging: > Available log levels: off, trace, debug, info, warning, error > Available log decorators: time (t), uptime (u), timemillis (tm), > uptimemillis (um), timenanos (tn), uptimenanos (un), hostname > (hn), pid (p), tid (ti), level (l), tags (tg) > Available log tags: alloc, age, barrier, biasedlocking, bot, > census, classhisto, classresolve, classinit, classload, > classloaderdata, classunload, classpath, compaction, cpu, cset, > defaultmethods, ergo, exceptions, exit, freelist, gc, heap, > humongous, ihop, itables, jni, liveness, logging, marking, > metaspace, modules, monitorinflation, os, phases, plab, promotion, > preorder, protectiondomain, ref, refine, region, remset, > safepoint, safepointcleanup, scavenge, scrub, stacktrace, start, > startuptime, state, stats, stringdedup, stringtable, survivor, > sweep, task, thread, tlab, time, verboseverification, verify, > vmoperation, vtables > Log output configuration: > #0: stdout all=off uptime,level,tags, > #1: stderr all=warning uptime,level,tags, > > Environment Variables: > JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk > PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin > SHELL=/bin/bash > OS=Linux > > From dmitry.samersoff at oracle.com Thu Mar 31 18:54:51 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 31 Mar 2016 21:54:51 +0300 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: 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> Message-ID: <56FD727B.1000209@oracle.com> 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(cons >>>>>>>>> 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 >>>>>>>>> >>>>>> >>>> >>> > -- 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 kevin.walls at oracle.com Thu Mar 31 19:32:00 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 31 Mar 2016 20:32:00 +0100 Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56FD727B.1000209@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> Message-ID: <56FD7B30.8020105@oracle.com> 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(cons >>>>>>>>>> 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 daniel.daugherty at oracle.com Thu Mar 31 19:45:58 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 31 Mar 2016 13:45:58 -0600 Subject: RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392 In-Reply-To: <56FD3645.80007@oracle.com> References: <56F1BAB0.2000001@oracle.com> <56F45BB3.8000006@oracle.com> <56F46331.6050006@oracle.com> <56F9BBE6.10207@oracle.com> <56FCB3F7.6050403@oracle.com> <56FD3645.80007@oracle.com> Message-ID: <56FD7E76.7000207@oracle.com> So this change: $ diff src/share/vm/runtime/sharedRuntime.cpp{.cr1,} 2956c2956 < int buf_size_words = max_locals + active_monitor_count * (sizeof(BasicObjectLock) / wordSize); --- > int buf_size_words = max_locals + active_monitor_count * BasicObjectLock::size(); relative to code review round 1 passes JPRT build and test. I'll include it in the final changeset for 8152358. Dan On 3/31/16 8:37 AM, Daniel D. Daugherty wrote: > Thanks for closing the loop on this part of the review... > > I think we're on the same page about what to change. > I have a vague memory of trying to change: > > int buf_size_words = max_locals + active_monitor_count*2; > > to: > > int buf_size_words = max_locals + active_monitor_count * > BasicObjectLock::size(); > > but it didn't compile for some reason so I went the other way. > I'll take a look one more time before pushing the changeset. > Still doing stress testing so I have time... > > Dan > > > On 3/30/16 11:21 PM, Vladimir Kozlov wrote: >> Sorry for later reply when you send updated webrev already. >> >> You changed code in OSR_migration_begin(): >> - int buf_size_words = max_locals + active_monitor_count*2; >> + int buf_size_words = max_locals + active_monitor_count * >> (sizeof(BasicObjectLock) / wordSize); >> >> I am suggesting next: >> >> + int buf_size_words = max_locals + active_monitor_count * >> BasicObjectLock::size(); >> >> Thanks, >> Vladimir >> >> On 3/28/16 4:19 PM, Daniel D. Daugherty wrote: >>> On 3/24/16 3:59 PM, Daniel D. Daugherty wrote: >>>> On 3/24/16 3:27 PM, Vladimir Kozlov wrote: >>>>> In sharedRuntime.cpp you could use BasicObjectLock::size() as you >>>>> did in c1_LIRAssembler_x86.cpp >>>> >>>> I'll take a look. I may leave that cleanup to another pass, if >>>> you would be OK with it... I'm nearing the end of my 72 hour >>>> stress test cycle and don't want to repeat it... :-) >>> >>> Here's the C1 change: >>> >>> $ hg diff src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>> diff -r b9efb94d011a src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>> --- a/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 07 11:28:06 >>> 2016 -0800 >>> +++ b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Mon Mar 28 16:12:30 >>> 2016 -0700 >>> @@ -312,7 +312,7 @@ void LIR_Assembler::osr_entry() { >>> Register OSR_buf = osrBufferPointer()->as_pointer_register(); >>> { assert(frame::interpreter_frame_monitor_size() == >>> BasicObjectLock::size(), "adjust code below"); >>> int monitor_offset = BytesPerWord * method()->max_locals() + >>> - (2 * BytesPerWord) * (number_of_locks - 1); >>> + (BasicObjectLock::size() * BytesPerWord) * (number_of_locks - >>> 1); >>> // SharedRuntime::OSR_migration_begin() packs BasicObjectLocks in >>> // the OSR buffer using 2 word entries: first the lock and then >>> // the oop. >>> >>> >>> Here's the existing code in SharedRuntime::OSR_migration_begin(): >>> >>> // Allocate temp buffer, 1 word per local & 2 per active monitor >>> int buf_size_words = max_locals + active_monitor_count * >>> (sizeof(BasicObjectLock) / wordSize); >>> intptr_t *buf = NEW_C_HEAP_ARRAY(intptr_t,buf_size_words, mtCode); >>> >>> >>> so is your suggestion to change: >>> >>> sizeof(BasicObjectLock) / wordSize >>> >>> to: >>> >>> BasicObjectLock::size() >>> >>> or am I misunderstanding what you mean? >>> >>> Dan >>> > >