From harsha.wardhana.b at oracle.com Mon May 2 05:23:54 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 2 May 2016 10:53:54 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> <5722E11E.9020403@oracle.com> Message-ID: <5726E46A.1090903@oracle.com> Hi Jaroslav, Thanks for pointing out the @required tag. It's a nifty Jtreg feature. Below is webrev for updated patch. http://cr.openjdk.java.net/~hb/8154166/webrev.02/ -Harsha On Friday 29 April 2016 02:15 PM, Jaroslav Bachorik wrote: > > > On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B > wrote: > > Hi Jaroslav, > > I am not sure how @required tag works. I searched code base and it > is not used in any file. Also, the documentation on Jtreg page is > sparse. > > Could you paste an example as to how to use it? > > > Please, take a look > at jdk/test/java/lang/management/MemoryMXBean/LowMemoryTest.java - > actually, it is '@requires' tag. > > > Also, I would still think that repeated gc via weak-reference is > right and defensive approach. So I would like to leave that in > place unless it is causing any side-effects. > > > No objections here. It does not break anything and makes the test > intentions clearer. > > -JB- > > > Thanks > Harsha > > > On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: >> >> >> On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B >> > > wrote: >> >> Hi, >> >> Please review below patch to disable concurrent GC option. >> http://cr.openjdk.java.net/~hb/8154166/webrev.01/ >> >> >> >> I'm sorry to be a PITA, but why it is not possible to use the >> @require tag? >> >> >> >> Jaroslav, >> >> According to Javadoc of Runtime.gc(), >> >> https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- >> >> The call will only make it's best effort to do a GC and >> provides no guarantee that a given object can be collected >> even if GC runs. >> It does not say that Runtime.gc() call will block till entire >> GC cycle is finished and hence we cannot be making that >> assumption. >> >> >> I know, I had the same discussion a while ago when fixing some >> other tests failing when run with allowed concurrent explicit GC >> and I was pointed to the fact that all the known implementation >> actually do wait until the complete GC cycle is over before >> returning. Otherwise all those tests relying on some memory >> having been reclaimed or some counters having been increased >> would have to be considered random. >> >> >> Hence it is required that we encapsulate the target object in >> WeakReference and repeatedly call GC till weakRef returns null. >> Granted that we will have a small window when weakRef returns >> null and the target object is not removed from memory. But I >> see no way how to fix that problem. >> >> >> Exactly. The only guarantee for all the GC related metrics having >> been updated before proceeding with the test is being able to run >> the explicit GC in blocking manner. Otherwise the tests are not >> really deterministic and can intermittently fail. >> >> -JB- >> >> >> -Harsha >> >> >> On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: >>> The reproducer would be very time sensitive as with the >>> provided 'ExplicitGCInvokesConcurrent' it will run GC >>> concurrently with the invoker. Otherwise, in the current >>> implementation, calling Runtime.gc() would guarantee the GC >>> cycle has finished before that method returns. >>> >>> The WeakReference javadoc >>> (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) >>> is only stating that the referenced object will be made >>> finalizable at the same time as the reference is cleared. As >>> a consequence a cleared reference might not always mean that >>> the heap usage has been changed (unless a particular GC >>> implementation makes some additional guarantees). >>> >>> I know we were stabilizing a bunch of related tests relying >>> on GC doing its work before checking for some >>> post-conditions and the only way to make the tests reliable >>> was to forbid running those tests with >>> '-XX:+ExplicitGCInvokesConcurrent'. >>> >>> -JB- >>> >>> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B >>> wrote: >>> >>> Hello, >>> >>> The issue was not reproducible with or without, >>> >>> "-XX:+ExplicitGCInvokesConcurrent" >>> >>> Flag. The patch ensures that GC happens before we start >>> measuring memory. Without the patch, GC might or might >>> not happen. >>> >>> -Harsha >>> >>> >>> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >>>> Hi, >>>> >>>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the below simple fix for issue, >>>> >>>> issue : >>>> https://bugs.openjdk.java.net/browse/JDK-8154166 >>>> webrev : >>>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>>> >>>> >>>> Shouldn't this test rather declare the conditions when >>>> it is supposed to work? According to the issue this was >>>> caused by introducing the >>>> "-XX:+ExplicitGCInvokesConcurrent" which makes it very >>>> tricky to make any assumptions about the GC process. >>>> >>>> See eg. >>>> jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >>>> for enabling the test only for allowed configurations. >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>> >>>> >>>> -Harsha >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bachorik at gmail.com Mon May 2 06:19:17 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Mon, 2 May 2016 08:19:17 +0200 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: <5726E46A.1090903@oracle.com> References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> <5722E11E.9020403@oracle.com> <5726E46A.1090903@oracle.com> Message-ID: Reviewed. Thanks! -JB- On Mon, May 2, 2016 at 7:23 AM, Harsha Wardhana B < harsha.wardhana.b at oracle.com> wrote: > Hi Jaroslav, > > Thanks for pointing out the @required tag. It's a nifty Jtreg feature. > > Below is webrev for updated patch. > > http://cr.openjdk.java.net/~hb/8154166/webrev.02/ > > -Harsha > > > On Friday 29 April 2016 02:15 PM, Jaroslav Bachorik wrote: > > > > On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B < > harsha.wardhana.b at oracle.com> wrote: > >> Hi Jaroslav, >> >> I am not sure how @required tag works. I searched code base and it is not >> used in any file. Also, the documentation on Jtreg page is sparse. >> >> Could you paste an example as to how to use it? >> > > Please, take a look > at jdk/test/java/lang/management/MemoryMXBean/LowMemoryTest.java - > actually, it is '@requires' tag. > > >> >> Also, I would still think that repeated gc via weak-reference is right >> and defensive approach. So I would like to leave that in place unless it is >> causing any side-effects. >> > > No objections here. It does not break anything and makes the test > intentions clearer. > > -JB- > > >> >> Thanks >> Harsha >> >> >> On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: >> >> >> >> On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B < >> harsha.wardhana.b at oracle.com> wrote: >> >>> Hi, >>> >>> Please review below patch to disable concurrent GC option. >>> http://cr.openjdk.java.net/~hb/8154166/webrev.01/ >>> >> >> I'm sorry to be a PITA, but why it is not possible to use the @require >> tag? >> >> >>> >>> >>> Jaroslav, >>> >>> According to Javadoc of Runtime.gc(), >>> >>> https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- >>> >>> The call will only make it's best effort to do a GC and provides no >>> guarantee that a given object can be collected even if GC runs. >>> It does not say that Runtime.gc() call will block till entire GC cycle >>> is finished and hence we cannot be making that assumption. >>> >> >> I know, I had the same discussion a while ago when fixing some other >> tests failing when run with allowed concurrent explicit GC and I was >> pointed to the fact that all the known implementation actually do wait >> until the complete GC cycle is over before returning. Otherwise all those >> tests relying on some memory having been reclaimed or some counters having >> been increased would have to be considered random. >> >> >>> >>> Hence it is required that we encapsulate the target object in >>> WeakReference and repeatedly call GC till weakRef returns null. >>> Granted that we will have a small window when weakRef returns null and >>> the target object is not removed from memory. But I see no way how to fix >>> that problem. >>> >> >> Exactly. The only guarantee for all the GC related metrics having been >> updated before proceeding with the test is being able to run the explicit >> GC in blocking manner. Otherwise the tests are not really deterministic and >> can intermittently fail. >> >> -JB- >> >> >>> >>> -Harsha >>> >>> >>> On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: >>> >>> The reproducer would be very time sensitive as with the provided >>> 'ExplicitGCInvokesConcurrent' it will run GC concurrently with the invoker. >>> Otherwise, in the current implementation, calling Runtime.gc() would >>> guarantee the GC cycle has finished before that method returns. >>> >>> The WeakReference javadoc ( >>> >>> https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) >>> is only stating that the referenced object will be made finalizable at the >>> same time as the reference is cleared. As a consequence a cleared reference >>> might not always mean that the heap usage has been changed (unless a >>> particular GC implementation makes some additional guarantees). >>> >>> I know we were stabilizing a bunch of related tests relying on GC doing >>> its work before checking for some post-conditions and the only way to make >>> the tests reliable was to forbid running those tests with >>> '-XX:+ExplicitGCInvokesConcurrent'. >>> >>> -JB- >>> >>> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B < >>> harsha.wardhana.b at oracle.com> wrote: >>> >>>> Hello, >>>> >>>> The issue was not reproducible with or without, >>>> >>>> "-XX:+ExplicitGCInvokesConcurrent" >>>> >>>> Flag. The patch ensures that GC happens before we start measuring >>>> memory. Without the patch, GC might or might not happen. >>>> >>>> -Harsha >>>> >>>> >>>> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote: >>>> >>>> Hi, >>>> >>>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B < >>>> harsha.wardhana.b at oracle.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the below simple fix for issue, >>>>> >>>>> issue : >>>>> https://bugs.openjdk.java.net/browse/JDK-8154166 >>>>> webrev : >>>>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>>>> >>>> >>>> Shouldn't this test rather declare the conditions when it is supposed >>>> to work? According to the issue this was caused by introducing the "-XX:+ExplicitGCInvokesConcurrent" >>>> which makes it very tricky to make any assumptions about the GC process. >>>> >>>> See eg. jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >>>> for enabling the test only for allowed configurations. >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>> >>>>> >>>>> >>>>> -Harsha >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Mon May 2 06:30:08 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 2 May 2016 12:00:08 +0530 Subject: RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException In-Reply-To: References: <5719CE6F.3030704@oracle.com> <571B4B29.8040808@oracle.com> <571DC6F3.2090502@oracle.com> <5722E11E.9020403@oracle.com> <5726E46A.1090903@oracle.com> Message-ID: <5726F3F0.1030204@oracle.com> Thanks Jaroslav for the review. On Monday 02 May 2016 11:49 AM, Jaroslav Bachorik wrote: > Reviewed. > > Thanks! > > -JB- > > On Mon, May 2, 2016 at 7:23 AM, Harsha Wardhana B > > > wrote: > > Hi Jaroslav, > > Thanks for pointing out the @required tag. It's a nifty Jtreg feature. > > Below is webrev for updated patch. > > http://cr.openjdk.java.net/~hb/8154166/webrev.02/ > > > -Harsha > > > On Friday 29 April 2016 02:15 PM, Jaroslav Bachorik wrote: >> >> >> On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B >> > > wrote: >> >> Hi Jaroslav, >> >> I am not sure how @required tag works. I searched code base >> and it is not used in any file. Also, the documentation on >> Jtreg page is sparse. >> >> Could you paste an example as to how to use it? >> >> >> Please, take a look >> at jdk/test/java/lang/management/MemoryMXBean/LowMemoryTest.java >> - actually, it is '@requires' tag. >> >> >> Also, I would still think that repeated gc via weak-reference >> is right and defensive approach. So I would like to leave >> that in place unless it is causing any side-effects. >> >> >> No objections here. It does not break anything and makes the test >> intentions clearer. >> >> -JB- >> >> >> Thanks >> Harsha >> >> >> On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote: >>> >>> >>> On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B >>> >> > wrote: >>> >>> Hi, >>> >>> Please review below patch to disable concurrent GC option. >>> http://cr.openjdk.java.net/~hb/8154166/webrev.01/ >>> >>> >>> >>> I'm sorry to be a PITA, but why it is not possible to use >>> the @require tag? >>> >>> >>> >>> Jaroslav, >>> >>> According to Javadoc of Runtime.gc(), >>> >>> https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc-- >>> >>> The call will only make it's best effort to do a GC and >>> provides no guarantee that a given object can be >>> collected even if GC runs. >>> It does not say that Runtime.gc() call will block till >>> entire GC cycle is finished and hence we cannot be >>> making that assumption. >>> >>> >>> I know, I had the same discussion a while ago when fixing >>> some other tests failing when run with allowed concurrent >>> explicit GC and I was pointed to the fact that all the known >>> implementation actually do wait until the complete GC cycle >>> is over before returning. Otherwise all those tests relying >>> on some memory having been reclaimed or some counters having >>> been increased would have to be considered random. >>> >>> >>> Hence it is required that we encapsulate the target >>> object in WeakReference and repeatedly call GC till >>> weakRef returns null. >>> Granted that we will have a small window when weakRef >>> returns null and the target object is not removed from >>> memory. But I see no way how to fix that problem. >>> >>> >>> Exactly. The only guarantee for all the GC related metrics >>> having been updated before proceeding with the test is being >>> able to run the explicit GC in blocking manner. Otherwise >>> the tests are not really deterministic and can >>> intermittently fail. >>> >>> -JB- >>> >>> >>> -Harsha >>> >>> >>> On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote: >>>> The reproducer would be very time sensitive as with the >>>> provided 'ExplicitGCInvokesConcurrent' it will run GC >>>> concurrently with the invoker. Otherwise, in the >>>> current implementation, calling Runtime.gc() would >>>> guarantee the GC cycle has finished before that method >>>> returns. >>>> >>>> The WeakReference javadoc >>>> (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html) >>>> is only stating that the referenced object will be made >>>> finalizable at the same time as the reference is >>>> cleared. As a consequence a cleared reference might not >>>> always mean that the heap usage has been changed >>>> (unless a particular GC implementation makes some >>>> additional guarantees). >>>> >>>> I know we were stabilizing a bunch of related tests >>>> relying on GC doing its work before checking for some >>>> post-conditions and the only way to make the tests >>>> reliable was to forbid running those tests with >>>> '-XX:+ExplicitGCInvokesConcurrent'. >>>> >>>> -JB- >>>> >>>> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B >>>> >>> > wrote: >>>> >>>> Hello, >>>> >>>> The issue was not reproducible with or without, >>>> >>>> "-XX:+ExplicitGCInvokesConcurrent" >>>> >>>> Flag. The patch ensures that GC happens before we >>>> start measuring memory. Without the patch, GC might >>>> or might not happen. >>>> >>>> -Harsha >>>> >>>> >>>> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik >>>> wrote: >>>>> Hi, >>>>> >>>>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B >>>>> >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the below simple fix for issue, >>>>> >>>>> issue : >>>>> https://bugs.openjdk.java.net/browse/JDK-8154166 >>>>> webrev : >>>>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/ >>>>> >>>>> >>>>> >>>>> Shouldn't this test rather declare the conditions >>>>> when it is supposed to work? According to the >>>>> issue this was caused by introducing the >>>>> "-XX:+ExplicitGCInvokesConcurrent" which makes it >>>>> very tricky to make any assumptions about the GC >>>>> process. >>>>> >>>>> See eg. >>>>> jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java >>>>> for enabling the test only for allowed configurations. >>>>> >>>>> Cheers, >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>> -Harsha >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Mon May 2 08:44:53 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2016 10:44:53 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5723B714.7000503@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> Message-ID: <1462178693.5579.18.camel@redhat.com> On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote: > On 4/29/16 01:56, Severin Gehwolf wrote: > > Hi Serguei, > > > > On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: > > > Hi Severin, > > > > > > The fix looks good in general. > > > I'm testing both fixes together at the moment. > > That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. > > > > > A couple of questions... > > > > > > It seems, there are more places where an invokerLock critical section is missed. > > Right. > > > > > The following functions: > > > ? - invoker_enableInvokeRequests > > This should be fixed with the patch for JDK-8154529 > > > > > ? - invokeConstructor > > > ? - invokeStatic > > > ? - invokeNonvirtual > > > ? - invokeVirtual > > > ? - saveGlobalRef > > Correct. The intent would be to fix the callsites of saveGlobalRef. If > > we fix invoke* then saveGlobalRef should not be an issue. I didn't want > > to include this in this fix since it's pretty hairy and would like to > > fix this in incremental steps. > > > > > The first function is easy to fix. > > > The last 5 functions are called from the invoker_doInvoke() that we already had a problem with. > > > I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time? > > I'm not sure yet. Perhaps locking only while?saveGlobalRef is being > > called in invoke* functions will help. > > > > > I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues. > > Please keep me in the loop about your test results. > ? > Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are all passed. > > I also ran the 4 previously failed tests in big loops of 1000 runs: > ??? com/sun/jdi/InvokeTest.java > ? ? com/sun/jdi/InvokeHangTest.java > ? ? com/sun/jdi/InterfaceMethodsTest.java > ? ? com/sun/jdi/OomDebugTest.java? (new test introduced in the webrev) I suggest to run InvokeTest, InvokeHangTest and InterfaceMethodsTest in a loop. Those never failed for me in such a scenario. > The OomDebugTest.java failed with a timeout (most likely, a deadlock). > Please, find the OomDebugTest.jtr file in attachments. Correct. This is what I was seeing. See the last comment of the bug: https://bugs.openjdk.java.net/browse/JDK-8153711 It has the jstack output of the hung OomDebugTestTarg JVM. I'm not convinced this is the same failure we were seeing in?JDK-4858370 since the stack suggests it's doing a GC upon a newInstance of a primitive array. It also does not seem like the same issue as the deadlocks exposed by locking during an invoke, because it was reproducible fairly consistently with?InvokeHangTest. It looks to me like a new issue. Probably one which was there before, but is only exposed by the new test. The new test stress-tests the GC with a debugger attached. Of course, this is going to be hard to prove since it would just run out of memory prior the patch. Thoughts? Cheers, Severin > Thanks, > Serguei? > > > > > > > Thanks for your help! > > > > Cheers, > > Severin > > > > > Thanks, > > > Serguei > > > > > > > > > On 4/28/16 02:00, Severin Gehwolf wrote: > > > > On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: > > > > > > Hi Severin, > > > > > > > > > > > > I postpone a push for this fix. > > > > > > > > > > > > There are two nsk.jdi test failures (they look like deadlocks): > > > > > > ? nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) > > > > > > ? nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) > > > > > > > > > > > > and one jtreg sun/com/jdi failure (it looks like a deadlock too): > > > > > > ? com/sun/jdi/InvokeHangTes.java > > > > > > > > > > > > > > > > > > I'll double check if these failures are regressions caused by your fix? > > > > > > or not. > > > > > I confirm, the failures above are new regressions introduced by the fix. > > > > > The tests fail consistently with the fix and do not fail without the fix. > > > > OK this was caused by the locking done in invoker_doInvoke(). Note that > > > > holding either of them invoker lock or event handler lock causes this. > > > > > > > > Here is a new webrev with those hunks removed. It's sufficient to grab > > > > the locks again in invoke_completeInvokeRequest() when clearing the > > > > global references in order to not get those failures we've seen when > > > > the fix for JDK-4858370 was in place. > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ > > > > > > > > Testing done: > > > > ?-?com/sun/jdi/InvokeTest.java?com/sun/jdi/InvokeHangTest.java and > > > > ? ?sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. > > > > ?- regular com/sun/jdi test set: no regressions > > > > > > > > Note that there are some rare cases where OomDebugTest times out which > > > > seems to be caused by the GC, though. See the bug for details. Since > > > > this problem is rare, it's still worthwhile having that test included. > > > > If it turns out a problem in practice we could consider disabling the > > > > test. > > > > > > > > Thoughts? > > > > > > > > Cheers, > > > > Severin > > > ? > ? From cheleswer.sahu at oracle.com Mon May 2 09:51:36 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Mon, 2 May 2016 02:51:36 -0700 (PDT) Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd Message-ID: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8150900. Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ Enhancement Brief: A new variant of flag "diagnostic_pd" is implemented. All flags which are diagnostic in nature and platform dependent can be placed under this variant. These flags can be enable using "-XX:+UnlockDiagnosticVMOptions". At present I have placed 4 flags under "diagnostic_pd" 1. 1. InitArrayShortSize 2. 2. ImplicitNullChecks 3. 3. InlineFrequencyCount 4. 4. PostLoopMultiversioning Regards, Cheleswer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerard.ziemski at oracle.com Mon May 2 15:36:55 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 2 May 2016 10:36:55 -0500 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: References: Message-ID: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> hi Cheleswer, #1 Shouldn?t the following files be modified as well? : open: src/cpu/sparc/vm/globals_sparc.hpp src/cpu/x86/vm/globals_x86.hpp src/cpu/zero/vm/globals_zero.hpp closed: cpu/arm/vm/globals_arm.hpp share/vm/runtime/globals_ext.hpp share/vm/runtime/os_ext.hpp #2 Bunch of header files need to be updated with 2016 for Copyright: /* - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ #3 What tests have you run? Did you do: a) JPRT hotspot b) RBT hs-nightly-runtime Please email me if you need help with those. #4 Just heads up that I will be shortly asking for review of my fix (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches many of the same file, so one of us will have a tricky merge cheers > On May 2, 2016, at 4:51 AM, Cheleswer Sahu wrote: > > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8150900. > > > > Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ > > > > Enhancement Brief: A new variant of flag "diagnostic_pd" is implemented. All flags which are diagnostic in nature and platform dependent can be placed > > under this variant. These flags can be enable using "-XX:+UnlockDiagnosticVMOptions". > > At present I have placed 4 flags under "diagnostic_pd" > > 1. 1. InitArrayShortSize > > 2. 2. ImplicitNullChecks > > 3. 3. InlineFrequencyCount > > 4. 4. PostLoopMultiversioning > > > > > > Regards, > > Cheleswer From serguei.spitsyn at oracle.com Mon May 2 22:06:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 2 May 2016 15:06:00 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> References: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> Message-ID: <5727CF48.7020007@oracle.com> Hi Alexander, Could you, fix a couple of minor issues? test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java 58 for(Module mod : my.modules()) { 59 if(!jvmtiModules.contains(mod)) { A space is missed after the 'for' and 'if' keywords. test/serviceability/jvmti/GetModulesInfo/ModulesInfo.java. 31 boolean compareExcludingUnnamed(ModulesInfo other) { I'd suggest to call it compareNamed. Otherwise, the new test looks great. Thanks a lot for taking care about it! Thanks, Serguei On 4/29/16 06:12, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these test-only changes (adding a new test). > > CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the modules info as returned by the JVMTI" > Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/ > > The new test verifies that JVMTI returns the correct info about the modules loaded at the application startup. > It also verifies that the returned info is consistent with the same info returned by the Java API. > It then loads a new named module and checks the correctness of the JVMTI info again. > > Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. > The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. > > Best regards, > Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Tue May 3 05:03:44 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 2 May 2016 22:03:44 -0700 (PDT) Subject: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely In-Reply-To: <57236D43.1020704@oracle.com> References: <770ADA57-57E4-4634-AA3B-EA0A2118F229@oracle.com> <88b669d0-82cb-48d5-ba40-878127fce72c@default> <57221B97.5040506@oracle.com> <890dc06b-99b7-4105-b734-9d9df227d74c@default> <57236D43.1020704@oracle.com> Message-ID: Thanks for the review Dan.? I have made the suggested changes: ? http://cr.openjdk.java.net/~sballal/8154144/webrev.01/ ? I have also run the following tests successfully: 1.???? Rbt for nsk.jdb.testlist, nsk.jdi.testlist, nsk.jdwp.testlist, nsk.jvmti.testlist 2.???? Jtreg for com/sun/jdi/ directory. ? -Sharath Ballal ? ? From: Daniel D. Daugherty Sent: Friday, April 29, 2016 7:49 PM To: Sharath Ballal; Staffan Larsen Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Thanks for the additional details. I'm good with the concept of this fix. > http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ General comment ??? Please update the copyright years before you push. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ??? No comments. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ??? L763: ??????????????????? if(!isShuttingDown()) { ??????? Nit: please add a space between 'if' and '('. Thumbs up. Dan P.S. Part of me wonders if this line: L764: MessageOutput.println("Input stream closed."); should change to: L764: MessageOutput.println("Input stream closed unexpectedly."); But that would likely require updating the tests that look for this pattern. Probably not worth it. On 4/28/16 11:55 PM, Sharath Ballal wrote: Hi Dan, ? The debugger has received a ?vmDeathEvent? and as part of handling this event, the System.exit() is being called (handleExitEvent() in EventHandler.java).? So the fact that debuggee has finished executing, is known to the debugger and the debugger is explicitly cleaning up after that.? This is similar to the breakpoint you mentioned.? Instead of breakpoint, we have an event.? Now as part of the explicit cleanup the readLine() (which is always blocking) sometimes returns with a ?null?.? Since we know we are cleaning up and we also know that the debuggee has done executing, I am avoiding printing the error message. ? -Sharath Ballal ? ? From: Daniel D. Daugherty Sent: Thursday, April 28, 2016 7:48 PM To: Sharath Ballal; Staffan Larsen Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? > When JDB is done, as part of the shutdown it calls System.exit() > at Env.java:92 in a different thread 'event-handler'. Based on the above line from below, I'm even more convinced that this bug is hit because the debuggee VM is allowed to run off the end of main() and that creates a race between debuggee VM's attempt to exit and the debugger trying to control the test execution. While this fix makes this bug "go away", I don't think this is the right solution. You're basically trying to harden our ability to handle this race condition instead of closing the race condition. I'll repeat part of the comment that I added to the bug on 04.13: > One possible solution is to add a breakpoint after main() returns and change > the debuggee <-> debugger protocol to always expect one final breakpoint. > Positive enforcement that the test reaches that point and it should catch any > accidental "run of the end of main()" issues. Dan On 4/28/16 2:25 AM, Sharath Ballal wrote: Hi Staffan, The root cause of this problem is that BufferedReader.readLine() is intermittently returning 'null' during System.exit(0). In TTY.java:751 we are always blocking on readLine(). Whenever a user enters a command in JDB, the readLine() returns the command, which gets executed. This is running in the 'main' thread. When JDB is done, as part of the shutdown it calls System.exit() at Env.java:92 in a different thread 'event-handler'. Usually (in the passing cases) calling System.exit() is the end of the process and readLine() doesn't return 'null', but in the failing case readLine() at TTY.java:751 returns 'null'. This causes the string "Input stream closed." to be printed. The jtreg testcase looks for this string to decide that the testcase failed. ? The fix I have done is avoiding the print because we know that we are shutting down and hence can discard the ?null? returned by readLine(). ? Regarding the testing, I have run few of the failing jtreg testcases about 200 times and not seen the problem (earlier I was able to recreate without the fix).? I have to do other tests, but sent for review to do it in parallel. jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 708 BufferedReader in = 709 new BufferedReader(new InputStreamReader(System.in)); ....... ....... 748 // Process interactive commands. 749 MessageOutput.printPrompt(); 750 while (true) { 751 String ln = in.readLine(); 752 if (ln == null) { 753 MessageOutput.println("Input stream closed."); 754 ln = "quit"; 755 } jdk/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java 79 static void shutdown(String message) { 80 if (connection != null) { 81 try { 82 connection.disposeVM(); 83 } catch (VMDisconnectedException e) { 84 // Shutting down after the VM has gone away. This is 85 // not an error, and we just ignore it. 86 } 87 } 88 if (message != null) { 89 MessageOutput.lnprint(message); 90 MessageOutput.println(); 91 } 92 System.exit(0); 93 } ? ? -Sharath Ballal ? ? From: Staffan Larsen Sent: Thursday, April 28, 2016 1:17 PM To: Sharath Ballal Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8154144 Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Hi Sharath, ? Can you explain more how this help with the problem in the bug?? ? It looks like you are trying to avoid a race by not printing the "Input stream closed.? message while shutting down. You added this: 136???????????? ((TTY)notifier).setShuttingDown(true); 137???????????? Env.shutdown(shutdownMessageKey); The call on line 137 will result in a System.exit(0) call if I am reading the code right. So?adding the shutdown flag to line 136 will maybe make the race smaller, but isn?t really solving it? ? What kind of testing have you run this fix through? ? Thanks, /Staffan ? ? ? On 28 apr. 2016, at 09:22, Sharath Ballal wrote: ? Hi, ? Pls review the change for bug? ? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8154144"JDK-8154144?- Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely ? Webrev: http://cr.openjdk.java.net/~sballal/8154144/webrev.00/ ? -Sharath Ballal ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheleswer.sahu at oracle.com Tue May 3 06:34:06 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Mon, 2 May 2016 23:34:06 -0700 (PDT) Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> Message-ID: <736d4731-1763-434a-99d2-376fbe01443d@default> Hi Gerard, > -----Original Message----- > From: Gerard Ziemski > Sent: Monday, May 02, 2016 9:07 PM > To: Cheleswer Sahu > Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- > dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > hi Cheleswer, > > > #1 Shouldn?t the following files be modified as well? : > > open: > > src/cpu/sparc/vm/globals_sparc.hpp > src/cpu/x86/vm/globals_x86.hpp > src/cpu/zero/vm/globals_zero.hpp > > closed: > > cpu/arm/vm/globals_arm.hpp I have implemented "diagnostic_pd" using "product_pd" as a reference implementation. "product_pd" is not implemented for " ARCH_FLAGS ", therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" type. > share/vm/runtime/globals_ext.hpp > share/vm/runtime/os_ext.hpp These 2 files are under closed repository, so I have initiated a separate internal review request for those changes. > > > #2 Bunch of header files need to be updated with 2016 for Copyright: > > /* > - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. > * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > I agree, I will update the copyright headers. > #3 What tests have you run? Did you do: > > a) JPRT hotspot > b) RBT hs-nightly-runtime > I have run JPRT hostspot tests for this. It shows no error. > Please email me if you need help with those. > > > #4 Just heads up that I will be shortly asking for review of my fix > (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches many > of the same file, so one of us will have a tricky merge > Thanks for informing about this. Regards, Cheleswer > > cheers > > > On May 2, 2016, at 4:51 AM, Cheleswer Sahu > wrote: > > > > Hi, > > > > > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8150900. > > > > > > > > Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ > > > > > > > > Enhancement Brief: A new variant of flag "diagnostic_pd" is implemented. > All flags which are diagnostic in nature and platform dependent can be placed > > > > under this variant. These flags can be enable using "- > XX:+UnlockDiagnosticVMOptions". > > > > At present I have placed 4 flags under "diagnostic_pd" > > > > 1. 1. InitArrayShortSize > > > > 2. 2. ImplicitNullChecks > > > > 3. 3. InlineFrequencyCount > > > > 4. 4. PostLoopMultiversioning > > > > > > > > > > > > Regards, > > > > Cheleswer > From andreas.eriksson at oracle.com Tue May 3 09:12:33 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 3 May 2016 11:12:33 +0200 Subject: RFR: 8149790: NegativeArraySizeException with hprof In-Reply-To: References: <5710FD55.9060209@oracle.com> <57113129.5060802@oracle.com> <95a0309a-abe9-18f3-ce3f-b1043b8fd067@oracle.com> <571903D5.3050703@oracle.com> Message-ID: <21b19655-f8e8-ab26-df1b-d89506250bde@oracle.com> Hi, Could I get a Reviewer to take a look at this please? - Andreas On 2016-04-21 19:35, Andreas Eriksson wrote: > > On 2016-04-21 18:46, Erik Gahlin wrote: >> On 2016-04-21 15:47, Andreas Eriksson wrote: >>> Hi, >>> >>> >>> On 2016-04-15 20:21, Erik Gahlin wrote: >>>> Looks good, not a Reviewer. >>> >>> Thanks. >>> >>>> >>>> Do you really need curly braces in the switch clauses? >>> >>> In JavaValueArray.java they were needed before my change but not >>> after. Do you want me to remove them? >>> In JavaObject.java they are needed because the 'value' variable is a >>> different type in each clause, I could refactor so that I could >>> remove the curly braces, but I don't think it is worth the effort. >>> >> I was thinking about JavaValueArray.java. >> >> It would look better without them, but no need to create an updated >> webrev just for that. > > Alright, I'll change that before I push. > > Could a Reviewer take a look as well? > > - Andreas > >> >> Erik >> >>> - Andreas >>> >>>> >>>> Erik >>>> >>>> On 2016-04-15 16:40, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> Please review this test fix for 8149790: >>>>> NegativeArraySizeException with hprof >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8149790 >>>>> http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ >>>>> >>>>> Changes are to the hprof verifier, which now will pass heap dump >>>>> content around as JavaThing arrays instead of byte arrays, since >>>>> the latter cannot be guaranteed to be able to hold all the >>>>> elements of large arrays. >>>>> >>>>> There is still a problem where the test will timeout on machines >>>>> with lots of memory (seen on machines with 200+GB of memory) >>>>> because the verification takes a long time. I'll file a new bug >>>>> for that problem. >>>>> >>>>> Regards, >>>>> Andreas >>>> >>> >> > From serguei.spitsyn at oracle.com Tue May 3 10:21:16 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 3 May 2016 03:21:16 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <1462178693.5579.18.camel@redhat.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> <1462178693.5579.18.camel@redhat.com> Message-ID: <57287B9C.8060907@oracle.com> Hi Severin, Please, find my comments below. On 5/2/16 01:44, Severin Gehwolf wrote: > On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote: >> On 4/29/16 01:56, Severin Gehwolf wrote: >>> Hi Serguei, >>> >>> On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: >>>> Hi Severin, >>>> >>>> The fix looks good in general. >>>> I'm testing both fixes together at the moment. >>> That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. >>> >>>> A couple of questions... >>>> >>>> It seems, there are more places where an invokerLock critical section is missed. >>> Right. >>> >>>> The following functions: >>>> - invoker_enableInvokeRequests >>> This should be fixed with the patch for JDK-8154529 >>> >>>> - invokeConstructor >>>> - invokeStatic >>>> - invokeNonvirtual >>>> - invokeVirtual >>>> - saveGlobalRef >>> Correct. The intent would be to fix the callsites of saveGlobalRef. If >>> we fix invoke* then saveGlobalRef should not be an issue. I didn't want >>> to include this in this fix since it's pretty hairy and would like to >>> fix this in incremental steps. >>> >>>> The first function is easy to fix. >>>> The last 5 functions are called from the invoker_doInvoke() that we already had a problem with. >>>> I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time? >>> I'm not sure yet. Perhaps locking only while saveGlobalRef is being >>> called in invoke* functions will help. >>> >>>> I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues. >>> Please keep me in the loop about your test results. >> >> Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are all passed. >> >> I also ran the 4 previously failed tests in big loops of 1000 runs: >> com/sun/jdi/InvokeTest.java >> com/sun/jdi/InvokeHangTest.java >> com/sun/jdi/InterfaceMethodsTest.java >> com/sun/jdi/OomDebugTest.java (new test introduced in the webrev) > I suggest to run InvokeTest, InvokeHangTest and InterfaceMethodsTest in > a loop. Those never failed for me in such a scenario. > >> The OomDebugTest.java failed with a timeout (most likely, a deadlock). >> Please, find the OomDebugTest.jtr file in attachments. > Correct. This is what I was seeing. See the last comment of the bug: > https://bugs.openjdk.java.net/browse/JDK-8153711 Need to check if it is the same as I'm seeing. > > It has the jstack output of the hung OomDebugTestTarg JVM. I'm not > convinced this is the same failure we were seeing in JDK-4858370 since > the stack suggests it's doing a GC upon a newInstance of a primitive > array. It also does not seem like the same issue as the deadlocks > exposed by locking during an invoke, because it was reproducible fairly > consistently with InvokeHangTest. Agreed. > > It looks to me like a new issue. Probably one which was there before, > but is only exposed by the new test. The new test stress-tests the GC > with a debugger attached. Of course, this is going to be hard to prove > since it would just run out of memory prior the patch. Thanks. Your analysis seems to be reasonable. I tend to agree with it but need more time to convince myself. > Thoughts? Let me double check the above. If the analysis is correct then I'd suggest to file new bug and push your fix as is. Thanks, Serguei > > Cheers, > Severin > > > >> Thanks, >> Serguei >> >> >> >>> Thanks for your help! >>> >>> Cheers, >>> Severin >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/28/16 02:00, Severin Gehwolf wrote: >>>>> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> I postpone a push for this fix. >>>>>>> >>>>>>> There are two nsk.jdi test failures (they look like deadlocks): >>>>>>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) >>>>>>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>>>>>> >>>>>>> and one jtreg sun/com/jdi failure (it looks like a deadlock too): >>>>>>> com/sun/jdi/InvokeHangTes.java >>>>>>> >>>>>>> >>>>>>> I'll double check if these failures are regressions caused by your fix >>>>>>> or not. >>>>>> I confirm, the failures above are new regressions introduced by the fix. >>>>>> The tests fail consistently with the fix and do not fail without the fix. >>>>> OK this was caused by the locking done in invoker_doInvoke(). Note that >>>>> holding either of them invoker lock or event handler lock causes this. >>>>> >>>>> Here is a new webrev with those hunks removed. It's sufficient to grab >>>>> the locks again in invoke_completeInvokeRequest() when clearing the >>>>> global references in order to not get those failures we've seen when >>>>> the fix for JDK-4858370 was in place. >>>>> >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ >>>>> >>>>> Testing done: >>>>> - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and >>>>> sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. >>>>> - regular com/sun/jdi test set: no regressions >>>>> >>>>> Note that there are some rare cases where OomDebugTest times out which >>>>> seems to be caused by the GC, though. See the bug for details. Since >>>>> this problem is rare, it's still worthwhile having that test included. >>>>> If it turns out a problem in practice we could consider disabling the >>>>> test. >>>>> >>>>> Thoughts? >>>>> >>>>> Cheers, >>>>> Severin >>>> >> From yasuenag at gmail.com Tue May 3 11:43:08 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 May 2016 20:43:08 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <571638D1.3040702@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> Message-ID: <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ This patch makes to show option string of LogFileOutput. Thanks, Yasumasa On 2016/04/19 22:55, Yasumasa Suenaga wrote: > I adapted changes to jdk9/hs/hotspot repos. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ > > Please review. > > > Yasumasa > > > On 2016/04/18 23:09, Yasumasa Suenaga wrote: >> PING: >> >> I've sent review request for JDK-8153074. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >> >> If this patch is merged, user can confirm output option via VM.log jcmd. >> >> >> Please review and sponsor it. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>> CC'ed to serviceability-dev. >>>> >>>> Could you review it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This request review is related to [1]. >>>>> >>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>> >>>>> Output sample: >>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>>> >>>>> I uploaded webrev. Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>> >>>>> From yasuenag at gmail.com Tue May 3 11:44:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 May 2016 20:44:22 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <57189F3C.8070300@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> Message-ID: <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ Thanks, Yasumasa On 2016/04/21 18:37, Yasumasa Suenaga wrote: > Hi David, > >> So it just registered with me that currently filesize is interpreted as a value in KB. With this change it will be in bytes - that means tests will need fixing eg: >> >> hotspot/test/serviceability/logging/TestLogRotation.java > > Thanks! > I've fixed it in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ > > Following jtreg tests are passed: > > - hotspot/test/gc/logging > - hotspot/test/runtime/logging > - hotspot/test/serviceability/logging > > > Yasumasa > > > On 2016/04/21 14:43, David Holmes wrote: >> Hi Yasumasa, >> >> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> ... on 32-bit size_t and julong are not the same size so we would >>>> still need to ensure we don't specify a filesize that is greater than >>>> SIZE_MAX on 32-bit. >>> >>> Oh... I understood. >>> I've fixed and uploaded new webrev. Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >> >> So it just registered with me that currently filesize is interpreted as a value in KB. With this change it will be in bytes - that means tests will need fixing eg: >> >> hotspot/test/serviceability/logging/TestLogRotation.java >> >> That change in semantics may not be desirable, but I'll leave that to the owners of this code to decide (and I hope they jump in soon!) >> >> I note that in the existing range check: >> >> if (value == SIZE_MAX || value > SIZE_MAX / K) { >> >> the first clause is redundant. So your change seems okay. >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/20 15:04, David Holmes wrote: >>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> > You still removed the size bounds checks: >>>>> > >>>>> > 190 size_t value = parse_value(value_str); >>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>> > 192 errstream->print_cr("Invalid option: %s must be in range >>>>> [0, " >>>>> > 193 SIZE_FORMAT "]", FileSizeOptionKey, >>>>> SIZE_MAX / K); >>>>> > 194 success = false; >>>>> >>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>> >>>> Ah I hadn't realized this was an external value, I thought it was some >>>> internally enforced maximum file size limit. So this is just an >>>> overflow check really, and ... >>>> >>>>> Arguments::atojulong(atomull) checks value range [2]. >>>> >>>> ... we already do an overflow check in here, but ... >>>> >>>>> Thus I do not think we do not need to check value range in >>>>> LogFileOutput::parse_options(). >>>> >>>> ... on 32-bit size_t and julong are not the same size so we would >>>> still need to ensure we don't specify a filesize that is greater than >>>> SIZE_MAX on 32-bit. >>>> >>>>> >>>>> > Thanks, I had missed that example usage buried in there, but am still >>>>> > surprised none of these "options" for the handling the file are >>>>> > explicitly documented. >>>>> >>>>> I do not know how we can documented about it. >>>>> (Is it internal process in Oracle?) >>>> >>>> No I just meant that amongst all that help text you already modified, >>>> there is nothing, that I could see, that actually describes the >>>> possible options for filesize. >>>> >>>> Thanks, >>>> David >>>> >>>>> I can help for it if I can >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> [1] >>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>> >>>>> [2] >>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>> >>>>> >>>>> 2016/04/20 11:24 "David Holmes" >>>> >: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>> > Hi David, >>>>> > >>>>> > Thank you for your comment. >>>>> > >>>>> > I uploaded new webrev. Could you review again? >>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>> >>>>> You still removed the size bounds checks: >>>>> >>>>> 190 size_t value = parse_value(value_str); >>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>> 192 errstream->print_cr("Invalid option: %s must be in >>>>> range [0, " >>>>> 193 SIZE_FORMAT "]", >>>>> FileSizeOptionKey, >>>>> SIZE_MAX / K); >>>>> 194 success = false; >>>>> >>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>> "m" mean >>>>> >> memory? atojulong would seem more appropriate regardless. >>>>> > >>>>> > I renamed to atojulong() in new webrev. >>>>> > >>>>> >> Not directly related to your change but I was surprised that the >>>>> >> various log file options don't seem to be documented anywhere >>>>> in the >>>>> >> -Xlog:help output. >>>>> > >>>>> > I updated help message in new webrev. >>>>> >>>>> Thanks, I had missed that example usage buried in there, but am >>>>> still >>>>> surprised none of these "options" for the handling the file are >>>>> explicitly documented. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Yasumasa >>>>> > >>>>> > >>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>> >> Hi Yasumasa, >>>>> >> >>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>> >>> PING: >>>>> >>> >>>>> >>> I've sent review request for JDK-8153073. >>>>> >>> Could you review it? >>>>> >>> >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>> >>>>> >>> If this patch is merged, user can set logfile size with k/m/g. >>>>> >> >>>>> >> Your webrev seems out of date with respect to the current >>>>> code - the >>>>> >> logfile size processing is done in >>>>> LogFileOutput::parse_options not >>>>> >> configure_rotation. And of course you now need to work with >>>>> jdk9/hs not >>>>> >> hs-rt. >>>>> >> >>>>> >> That aside: >>>>> >> >>>>> >> src/share/vm/runtime/arguments.cpp >>>>> >> >>>>> >> I don't think you need to add the Arguments:: to the atomull >>>>> calls when >>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>> >> >>>>> >> This comment could be updated to delete "memory" >>>>> >> >>>>> >> 788 // Parses a memory size specification string. >>>>> >> >>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>> "m" mean >>>>> >> memory? atojulong would seem more appropriate regardless. >>>>> >> >>>>> >> --- >>>>> >> >>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>> >> >>>>> >> You removed the size checking logic. >>>>> >> >>>>> >> Not directly related to your change but I was surprised that the >>>>> >> various log file options don't seem to be documented anywhere >>>>> in the >>>>> >> -Xlog:help output. >>>>> >> >>>>> >> Thanks, >>>>> >> David >>>>> >> ----- >>>>> >> >>>>> >>> >>>>> >>> Please review it. >>>>> >>> >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Yasumasa >>>>> >>> >>>>> >>> >>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>> >>>> PING: Could you review it? >>>>> >>>> We need more reviewer. >>>>> >>>> >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>>> >>>>> >>>> >>>>> >>>> Thanks, >>>>> >>>> >>>>> >>>> Yasumasa >>>>> >>>> >>>>> >>>> >>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>> >>>>> CC'ed to serviceability-dev. >>>>> >>>>> >>>>> >>>>> Could you review it? >>>>> >>>>> >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi Marcus, >>>>> >>>>>> >>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>> logFileOutput.cpp. >>>>> >>>>>> >>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So build was >>>>> succeeded. >>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>> >>>>>> >>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>> >>>>>> >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Thanks, >>>>> >>>>>> >>>>> >>>>>> Yasumasa >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>> >>>>>>> Hi, >>>>> >>>>>>> >>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>> >>>>>>>> Hi all, >>>>> >>>>>>>> >>>>> >>>>>>>> This request review is related to [1]. >>>>> >>>>>>>> >>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>> >>>>>>>> >>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>> >>>>>>>> >>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>> >>>>>>>> >>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>> >>>>>>> >>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>> logFileOutput.cpp. >>>>> >>>>>>> >>>>> >>>>>>> Apart from that, this looks good to me. >>>>> >>>>>>> >>>>> >>>>>>> Thanks, >>>>> >>>>>>> Marcus >>>>> >>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> Thanks, >>>>> >>>>>>>> >>>>> >>>>>>>> Yasumasa >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> [1] >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>> >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> From david.holmes at oracle.com Tue May 3 12:25:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 May 2016 22:25:32 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> Message-ID: Adding in the runtime team as they now own UL. I've reviewed the change from a coding perspective - the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. Thanks, David On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ > > > Thanks, > > Yasumasa > > > On 2016/04/21 18:37, Yasumasa Suenaga wrote: >> Hi David, >> >>> So it just registered with me that currently filesize is interpreted >>> as a value in KB. With this change it will be in bytes - that means >>> tests will need fixing eg: >>> >>> hotspot/test/serviceability/logging/TestLogRotation.java >> >> Thanks! >> I've fixed it in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >> >> Following jtreg tests are passed: >> >> - hotspot/test/gc/logging >> - hotspot/test/runtime/logging >> - hotspot/test/serviceability/logging >> >> >> Yasumasa >> >> >> On 2016/04/21 14:43, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>> still need to ensure we don't specify a filesize that is greater than >>>>> SIZE_MAX on 32-bit. >>>> >>>> Oh... I understood. >>>> I've fixed and uploaded new webrev. Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>> >>> So it just registered with me that currently filesize is interpreted >>> as a value in KB. With this change it will be in bytes - that means >>> tests will need fixing eg: >>> >>> hotspot/test/serviceability/logging/TestLogRotation.java >>> >>> That change in semantics may not be desirable, but I'll leave that to >>> the owners of this code to decide (and I hope they jump in soon!) >>> >>> I note that in the existing range check: >>> >>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>> >>> the first clause is redundant. So your change seems okay. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/20 15:04, David Holmes wrote: >>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> > You still removed the size bounds checks: >>>>>> > >>>>>> > 190 size_t value = parse_value(value_str); >>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>> range >>>>>> [0, " >>>>>> > 193 SIZE_FORMAT "]", >>>>>> FileSizeOptionKey, >>>>>> SIZE_MAX / K); >>>>>> > 194 success = false; >>>>>> >>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>> >>>>> Ah I hadn't realized this was an external value, I thought it was some >>>>> internally enforced maximum file size limit. So this is just an >>>>> overflow check really, and ... >>>>> >>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>> >>>>> ... we already do an overflow check in here, but ... >>>>> >>>>>> Thus I do not think we do not need to check value range in >>>>>> LogFileOutput::parse_options(). >>>>> >>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>> still need to ensure we don't specify a filesize that is greater than >>>>> SIZE_MAX on 32-bit. >>>>> >>>>>> >>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>> still >>>>>> > surprised none of these "options" for the handling the file are >>>>>> > explicitly documented. >>>>>> >>>>>> I do not know how we can documented about it. >>>>>> (Is it internal process in Oracle?) >>>>> >>>>> No I just meant that amongst all that help text you already modified, >>>>> there is nothing, that I could see, that actually describes the >>>>> possible options for filesize. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I can help for it if I can >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> [1] >>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>> >>>>>> >>>>>> [2] >>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>> >>>>>> >>>>>> >>>>>> 2016/04/20 11:24 "David Holmes" >>>>> >: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>> > Hi David, >>>>>> > >>>>>> > Thank you for your comment. >>>>>> > >>>>>> > I uploaded new webrev. Could you review again? >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>> >>>>>> You still removed the size bounds checks: >>>>>> >>>>>> 190 size_t value = parse_value(value_str); >>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>> 192 errstream->print_cr("Invalid option: %s must be in >>>>>> range [0, " >>>>>> 193 SIZE_FORMAT "]", >>>>>> FileSizeOptionKey, >>>>>> SIZE_MAX / K); >>>>>> 194 success = false; >>>>>> >>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>> "m" mean >>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>> > >>>>>> > I renamed to atojulong() in new webrev. >>>>>> > >>>>>> >> Not directly related to your change but I was surprised >>>>>> that the >>>>>> >> various log file options don't seem to be documented anywhere >>>>>> in the >>>>>> >> -Xlog:help output. >>>>>> > >>>>>> > I updated help message in new webrev. >>>>>> >>>>>> Thanks, I had missed that example usage buried in there, but am >>>>>> still >>>>>> surprised none of these "options" for the handling the file are >>>>>> explicitly documented. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> > >>>>>> > Thanks, >>>>>> > >>>>>> > Yasumasa >>>>>> > >>>>>> > >>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>> >> Hi Yasumasa, >>>>>> >> >>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>> >>> PING: >>>>>> >>> >>>>>> >>> I've sent review request for JDK-8153073. >>>>>> >>> Could you review it? >>>>>> >>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>> >>> >>>>>> >>> If this patch is merged, user can set logfile size with >>>>>> k/m/g. >>>>>> >> >>>>>> >> Your webrev seems out of date with respect to the current >>>>>> code - the >>>>>> >> logfile size processing is done in >>>>>> LogFileOutput::parse_options not >>>>>> >> configure_rotation. And of course you now need to work with >>>>>> jdk9/hs not >>>>>> >> hs-rt. >>>>>> >> >>>>>> >> That aside: >>>>>> >> >>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>> >> >>>>>> >> I don't think you need to add the Arguments:: to the atomull >>>>>> calls when >>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>> >> >>>>>> >> This comment could be updated to delete "memory" >>>>>> >> >>>>>> >> 788 // Parses a memory size specification string. >>>>>> >> >>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>> "m" mean >>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>> >> >>>>>> >> --- >>>>>> >> >>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>> >> >>>>>> >> You removed the size checking logic. >>>>>> >> >>>>>> >> Not directly related to your change but I was surprised >>>>>> that the >>>>>> >> various log file options don't seem to be documented anywhere >>>>>> in the >>>>>> >> -Xlog:help output. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> David >>>>>> >> ----- >>>>>> >> >>>>>> >>> >>>>>> >>> Please review it. >>>>>> >>> >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Yasumasa >>>>>> >>> >>>>>> >>> >>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>> >>>> PING: Could you review it? >>>>>> >>>> We need more reviewer. >>>>>> >>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Thanks, >>>>>> >>>> >>>>>> >>>> Yasumasa >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>> >>>>> CC'ed to serviceability-dev. >>>>>> >>>>> >>>>>> >>>>> Could you review it? >>>>>> >>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks, >>>>>> >>>>> >>>>>> >>>>> Yasumasa >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi Marcus, >>>>>> >>>>>> >>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>> logFileOutput.cpp. >>>>>> >>>>>> >>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>> build was >>>>>> succeeded. >>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>> >>>>>> >>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>> >>>>>>> Hi, >>>>>> >>>>>>> >>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>>>> Hi all, >>>>>> >>>>>>>> >>>>>> >>>>>>>> This request review is related to [1]. >>>>>> >>>>>>>> >>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>> >>>>>>>> >>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>> >>>>>>>> >>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>> >>>>>>>> >>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>> >>>>>>> >>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>> logFileOutput.cpp. >>>>>> >>>>>>> >>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>> >>>>>>> >>>>>> >>>>>>> Thanks, >>>>>> >>>>>>> Marcus >>>>>> >>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> Thanks, >>>>>> >>>>>>>> >>>>>> >>>>>>>> Yasumasa >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> [1] >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>> >>>>>> From david.holmes at oracle.com Tue May 3 12:30:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 May 2016 22:30:12 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> Message-ID: Adding in runtime. David On 3/05/2016 9:43 PM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ > > This patch makes to show option string of LogFileOutput. > > > Thanks, > > Yasumasa > > > On 2016/04/19 22:55, Yasumasa Suenaga wrote: >> I adapted changes to jdk9/hs/hotspot repos. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >> >> Please review. >> >> >> Yasumasa >> >> >> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>> PING: >>> >>> I've sent review request for JDK-8153074. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>> >>> If this patch is merged, user can confirm output option via VM.log jcmd. >>> >>> >>> Please review and sponsor it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>> CC'ed to serviceability-dev. >>>>> >>>>> Could you review it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This request review is related to [1]. >>>>>> >>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>> >>>>>> Output sample: >>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 >>>>>> time,level, >>>>>> >>>>>> I uploaded webrev. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>> >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>> >>>>>> >>>>>> From marcus.larsson at oracle.com Tue May 3 12:41:33 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 May 2016 14:41:33 +0200 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> Message-ID: <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> Hi, On 05/03/2016 02:25 PM, David Holmes wrote: > Adding in the runtime team as they now own UL. > > I've reviewed the change from a coding perspective - the question for > the UL owners is whether the change in semantics is appropriate: > previously the filesize was interpreted as a value in KB, whereas now, > without a suffix, it is just bytes. > > Thanks, > David > > On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ This seems broken to me, we're passing &_rotate_size (a size_t*) to atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) then that's a problem, no? Thanks, Marcus >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> So it just registered with me that currently filesize is interpreted >>>> as a value in KB. With this change it will be in bytes - that means >>>> tests will need fixing eg: >>>> >>>> hotspot/test/serviceability/logging/TestLogRotation.java >>> >>> Thanks! >>> I've fixed it in new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>> >>> Following jtreg tests are passed: >>> >>> - hotspot/test/gc/logging >>> - hotspot/test/runtime/logging >>> - hotspot/test/serviceability/logging >>> >>> >>> Yasumasa >>> >>> >>> On 2016/04/21 14:43, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>> still need to ensure we don't specify a filesize that is greater >>>>>> than >>>>>> SIZE_MAX on 32-bit. >>>>> >>>>> Oh... I understood. >>>>> I've fixed and uploaded new webrev. Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>> >>>> So it just registered with me that currently filesize is interpreted >>>> as a value in KB. With this change it will be in bytes - that means >>>> tests will need fixing eg: >>>> >>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>> >>>> That change in semantics may not be desirable, but I'll leave that to >>>> the owners of this code to decide (and I hope they jump in soon!) >>>> >>>> I note that in the existing range check: >>>> >>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>> >>>> the first clause is redundant. So your change seems okay. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> > You still removed the size bounds checks: >>>>>>> > >>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>>> range >>>>>>> [0, " >>>>>>> > 193 SIZE_FORMAT "]", >>>>>>> FileSizeOptionKey, >>>>>>> SIZE_MAX / K); >>>>>>> > 194 success = false; >>>>>>> >>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>> >>>>>> Ah I hadn't realized this was an external value, I thought it was >>>>>> some >>>>>> internally enforced maximum file size limit. So this is just an >>>>>> overflow check really, and ... >>>>>> >>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>> >>>>>> ... we already do an overflow check in here, but ... >>>>>> >>>>>>> Thus I do not think we do not need to check value range in >>>>>>> LogFileOutput::parse_options(). >>>>>> >>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>> still need to ensure we don't specify a filesize that is greater >>>>>> than >>>>>> SIZE_MAX on 32-bit. >>>>>> >>>>>>> >>>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>>> still >>>>>>> > surprised none of these "options" for the handling the file are >>>>>>> > explicitly documented. >>>>>>> >>>>>>> I do not know how we can documented about it. >>>>>>> (Is it internal process in Oracle?) >>>>>> >>>>>> No I just meant that amongst all that help text you already >>>>>> modified, >>>>>> there is nothing, that I could see, that actually describes the >>>>>> possible options for filesize. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I can help for it if I can >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> [1] >>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] >>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>> >: >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>> > Hi David, >>>>>>> > >>>>>>> > Thank you for your comment. >>>>>>> > >>>>>>> > I uploaded new webrev. Could you review again? >>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>> >>>>>>> You still removed the size bounds checks: >>>>>>> >>>>>>> 190 size_t value = parse_value(value_str); >>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>> be in >>>>>>> range [0, " >>>>>>> 193 SIZE_FORMAT "]", >>>>>>> FileSizeOptionKey, >>>>>>> SIZE_MAX / K); >>>>>>> 194 success = false; >>>>>>> >>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>> "m" mean >>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>> > >>>>>>> > I renamed to atojulong() in new webrev. >>>>>>> > >>>>>>> >> Not directly related to your change but I was surprised >>>>>>> that the >>>>>>> >> various log file options don't seem to be documented >>>>>>> anywhere >>>>>>> in the >>>>>>> >> -Xlog:help output. >>>>>>> > >>>>>>> > I updated help message in new webrev. >>>>>>> >>>>>>> Thanks, I had missed that example usage buried in there, but am >>>>>>> still >>>>>>> surprised none of these "options" for the handling the file are >>>>>>> explicitly documented. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> > >>>>>>> > Thanks, >>>>>>> > >>>>>>> > Yasumasa >>>>>>> > >>>>>>> > >>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>> >> Hi Yasumasa, >>>>>>> >> >>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>> >>> PING: >>>>>>> >>> >>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>> >>> Could you review it? >>>>>>> >>> >>>>>>> >>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>> >>> >>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>> k/m/g. >>>>>>> >> >>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>> code - the >>>>>>> >> logfile size processing is done in >>>>>>> LogFileOutput::parse_options not >>>>>>> >> configure_rotation. And of course you now need to work with >>>>>>> jdk9/hs not >>>>>>> >> hs-rt. >>>>>>> >> >>>>>>> >> That aside: >>>>>>> >> >>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>> >> >>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>> atomull >>>>>>> calls when >>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>> >> >>>>>>> >> This comment could be updated to delete "memory" >>>>>>> >> >>>>>>> >> 788 // Parses a memory size specification string. >>>>>>> >> >>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>> "m" mean >>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>> >> >>>>>>> >> --- >>>>>>> >> >>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>> >> >>>>>>> >> You removed the size checking logic. >>>>>>> >> >>>>>>> >> Not directly related to your change but I was surprised >>>>>>> that the >>>>>>> >> various log file options don't seem to be documented >>>>>>> anywhere >>>>>>> in the >>>>>>> >> -Xlog:help output. >>>>>>> >> >>>>>>> >> Thanks, >>>>>>> >> David >>>>>>> >> ----- >>>>>>> >> >>>>>>> >>> >>>>>>> >>> Please review it. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> Thanks, >>>>>>> >>> >>>>>>> >>> Yasumasa >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>> >>>> PING: Could you review it? >>>>>>> >>>> We need more reviewer. >>>>>>> >>>> >>>>>>> >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> Thanks, >>>>>>> >>>> >>>>>>> >>>> Yasumasa >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>> >>>>> >>>>>>> >>>>> Could you review it? >>>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> Thanks, >>>>>>> >>>>> >>>>>>> >>>>> Yasumasa >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>> >>>>>> Hi Marcus, >>>>>>> >>>>>> >>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>> logFileOutput.cpp. >>>>>>> >>>>>> >>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>> build was >>>>>>> succeeded. >>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>> >>>>>> >>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Thanks, >>>>>>> >>>>>> >>>>>>> >>>>>> Yasumasa >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>> >>>>>>>> >>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>> k/m/g . >>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>> logFileOutput.cpp. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Yasumasa >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> [1] >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> From yasuenag at gmail.com Tue May 3 13:49:00 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 May 2016 22:49:00 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> Message-ID: <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> > This seems broken to me, we're passing &_rotate_size (a size_t*) to atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) then that's a problem, no? Thanks, Marcus! I changed type of _rotate_size and _current_size to julong in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >> the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. Is it no problem? Thanks, Yasumasa On 2016/05/03 21:41, Marcus Larsson wrote: > Hi, > > > On 05/03/2016 02:25 PM, David Holmes wrote: >> Adding in the runtime team as they now own UL. >> >> I've reviewed the change from a coding perspective - the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. >> >> Thanks, >> David >> >> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ > > This seems broken to me, we're passing &_rotate_size (a size_t*) to atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) then that's a problem, no? > > Thanks, > Marcus > >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> So it just registered with me that currently filesize is interpreted >>>>> as a value in KB. With this change it will be in bytes - that means >>>>> tests will need fixing eg: >>>>> >>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>> >>>> Thanks! >>>> I've fixed it in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>> >>>> Following jtreg tests are passed: >>>> >>>> - hotspot/test/gc/logging >>>> - hotspot/test/runtime/logging >>>> - hotspot/test/serviceability/logging >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/21 14:43, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>> still need to ensure we don't specify a filesize that is greater than >>>>>>> SIZE_MAX on 32-bit. >>>>>> >>>>>> Oh... I understood. >>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>> >>>>> So it just registered with me that currently filesize is interpreted >>>>> as a value in KB. With this change it will be in bytes - that means >>>>> tests will need fixing eg: >>>>> >>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>> >>>>> That change in semantics may not be desirable, but I'll leave that to >>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>> >>>>> I note that in the existing range check: >>>>> >>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>> >>>>> the first clause is redundant. So your change seems okay. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> > You still removed the size bounds checks: >>>>>>>> > >>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>> range >>>>>>>> [0, " >>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>> FileSizeOptionKey, >>>>>>>> SIZE_MAX / K); >>>>>>>> > 194 success = false; >>>>>>>> >>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>> >>>>>>> Ah I hadn't realized this was an external value, I thought it was some >>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>> overflow check really, and ... >>>>>>> >>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>> >>>>>>> ... we already do an overflow check in here, but ... >>>>>>> >>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>> LogFileOutput::parse_options(). >>>>>>> >>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>> still need to ensure we don't specify a filesize that is greater than >>>>>>> SIZE_MAX on 32-bit. >>>>>>> >>>>>>>> >>>>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>>>> still >>>>>>>> > surprised none of these "options" for the handling the file are >>>>>>>> > explicitly documented. >>>>>>>> >>>>>>>> I do not know how we can documented about it. >>>>>>>> (Is it internal process in Oracle?) >>>>>>> >>>>>>> No I just meant that amongst all that help text you already modified, >>>>>>> there is nothing, that I could see, that actually describes the >>>>>>> possible options for filesize. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I can help for it if I can >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> [1] >>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>> >>>>>>>> >>>>>>>> [2] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>> >: >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>> > Hi David, >>>>>>>> > >>>>>>>> > Thank you for your comment. >>>>>>>> > >>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>> >>>>>>>> You still removed the size bounds checks: >>>>>>>> >>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>> 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>> range [0, " >>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>> FileSizeOptionKey, >>>>>>>> SIZE_MAX / K); >>>>>>>> 194 success = false; >>>>>>>> >>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>> "m" mean >>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>> > >>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>> > >>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>> that the >>>>>>>> >> various log file options don't seem to be documented anywhere >>>>>>>> in the >>>>>>>> >> -Xlog:help output. >>>>>>>> > >>>>>>>> > I updated help message in new webrev. >>>>>>>> >>>>>>>> Thanks, I had missed that example usage buried in there, but am >>>>>>>> still >>>>>>>> surprised none of these "options" for the handling the file are >>>>>>>> explicitly documented. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > >>>>>>>> > Yasumasa >>>>>>>> > >>>>>>>> > >>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>> >> Hi Yasumasa, >>>>>>>> >> >>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>> >>> PING: >>>>>>>> >>> >>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>> >>> Could you review it? >>>>>>>> >>> >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>> >>> >>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>> k/m/g. >>>>>>>> >> >>>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>>> code - the >>>>>>>> >> logfile size processing is done in >>>>>>>> LogFileOutput::parse_options not >>>>>>>> >> configure_rotation. And of course you now need to work with >>>>>>>> jdk9/hs not >>>>>>>> >> hs-rt. >>>>>>>> >> >>>>>>>> >> That aside: >>>>>>>> >> >>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>> >> >>>>>>>> >> I don't think you need to add the Arguments:: to the atomull >>>>>>>> calls when >>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>> >> >>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>> >> >>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>> >> >>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>> "m" mean >>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>> >> >>>>>>>> >> --- >>>>>>>> >> >>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>> >> >>>>>>>> >> You removed the size checking logic. >>>>>>>> >> >>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>> that the >>>>>>>> >> various log file options don't seem to be documented anywhere >>>>>>>> in the >>>>>>>> >> -Xlog:help output. >>>>>>>> >> >>>>>>>> >> Thanks, >>>>>>>> >> David >>>>>>>> >> ----- >>>>>>>> >> >>>>>>>> >>> >>>>>>>> >>> Please review it. >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> Thanks, >>>>>>>> >>> >>>>>>>> >>> Yasumasa >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>> >>>> PING: Could you review it? >>>>>>>> >>>> We need more reviewer. >>>>>>>> >>>> >>>>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Thanks, >>>>>>>> >>>> >>>>>>>> >>>> Yasumasa >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>> >>>>> >>>>>>>> >>>>> Could you review it? >>>>>>>> >>>>> >>>>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Thanks, >>>>>>>> >>>>> >>>>>>>> >>>>> Yasumasa >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>> >>>>>> Hi Marcus, >>>>>>>> >>>>>> >>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>> logFileOutput.cpp. >>>>>>>> >>>>>> >>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>> build was >>>>>>>> succeeded. >>>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>>> >>>>>> >>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Thanks, >>>>>>>> >>>>>> >>>>>>>> >>>>>> Yasumasa >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>> >>>>>>> Hi, >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>> >>>>>>>> >>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>> logFileOutput.cpp. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Thanks, >>>>>>>> >>>>>>> Marcus >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> > From marcus.larsson at oracle.com Tue May 3 13:55:17 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 3 May 2016 15:55:17 +0200 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> Message-ID: <2286a1f9-529b-88f6-2918-07a605abef80@oracle.com> On 05/03/2016 03:49 PM, Yasumasa Suenaga wrote: >> This seems broken to me, we're passing &_rotate_size (a size_t*) to >> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >> then that's a problem, no? > > Thanks, Marcus! > I changed type of _rotate_size and _current_size to julong in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ That's good, but then we shouldn't limit it to SIZE_MAX. The overflow check in logFileOutput.cpp should be removed. > >>> the question for the UL owners is whether the change in semantics is >>> appropriate: previously the filesize was interpreted as a value in >>> KB, whereas now, without a suffix, it is just bytes. > > Is it no problem? No I don't think that's a problem. Thanks, Marcus > > > Thanks, > > Yasumasa > > > On 2016/05/03 21:41, Marcus Larsson wrote: >> Hi, >> >> >> On 05/03/2016 02:25 PM, David Holmes wrote: >>> Adding in the runtime team as they now own UL. >>> >>> I've reviewed the change from a coding perspective - the question >>> for the UL owners is whether the change in semantics is appropriate: >>> previously the filesize was interpreted as a value in KB, whereas >>> now, without a suffix, it is just bytes. >>> >>> Thanks, >>> David >>> >>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >> >> This seems broken to me, we're passing &_rotate_size (a size_t*) to >> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >> then that's a problem, no? >> >> Thanks, >> Marcus >> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> So it just registered with me that currently filesize is interpreted >>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>> tests will need fixing eg: >>>>>> >>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>> >>>>> Thanks! >>>>> I've fixed it in new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>> >>>>> Following jtreg tests are passed: >>>>> >>>>> - hotspot/test/gc/logging >>>>> - hotspot/test/runtime/logging >>>>> - hotspot/test/serviceability/logging >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>> greater than >>>>>>>> SIZE_MAX on 32-bit. >>>>>>> >>>>>>> Oh... I understood. >>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>> >>>>>> So it just registered with me that currently filesize is interpreted >>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>> tests will need fixing eg: >>>>>> >>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>> >>>>>> That change in semantics may not be desirable, but I'll leave >>>>>> that to >>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>> >>>>>> I note that in the existing range check: >>>>>> >>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>> >>>>>> the first clause is redundant. So your change seems okay. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> > You still removed the size bounds checks: >>>>>>>>> > >>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>> be in >>>>>>>>> range >>>>>>>>> [0, " >>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>> FileSizeOptionKey, >>>>>>>>> SIZE_MAX / K); >>>>>>>>> > 194 success = false; >>>>>>>>> >>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>> >>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>> was some >>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>> overflow check really, and ... >>>>>>>> >>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>> >>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>> >>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>> LogFileOutput::parse_options(). >>>>>>>> >>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>> greater than >>>>>>>> SIZE_MAX on 32-bit. >>>>>>>> >>>>>>>>> >>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>> but am >>>>>>>>> still >>>>>>>>> > surprised none of these "options" for the handling the file >>>>>>>>> are >>>>>>>>> > explicitly documented. >>>>>>>>> >>>>>>>>> I do not know how we can documented about it. >>>>>>>>> (Is it internal process in Oracle?) >>>>>>>> >>>>>>>> No I just meant that amongst all that help text you already >>>>>>>> modified, >>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>> possible options for filesize. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I can help for it if I can >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [2] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>> >: >>>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>> > Hi David, >>>>>>>>> > >>>>>>>>> > Thank you for your comment. >>>>>>>>> > >>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>> >>>>>>>>> You still removed the size bounds checks: >>>>>>>>> >>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>> be in >>>>>>>>> range [0, " >>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>> FileSizeOptionKey, >>>>>>>>> SIZE_MAX / K); >>>>>>>>> 194 success = false; >>>>>>>>> >>>>>>>>> >> Which makes me wonder if atomull needs renaming - does >>>>>>>>> the >>>>>>>>> "m" mean >>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>> > >>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>> > >>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>> that the >>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>> anywhere >>>>>>>>> in the >>>>>>>>> >> -Xlog:help output. >>>>>>>>> > >>>>>>>>> > I updated help message in new webrev. >>>>>>>>> >>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>> but am >>>>>>>>> still >>>>>>>>> surprised none of these "options" for the handling the >>>>>>>>> file are >>>>>>>>> explicitly documented. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > >>>>>>>>> > Yasumasa >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>> >> Hi Yasumasa, >>>>>>>>> >> >>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>> PING: >>>>>>>>> >>> >>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>> >>> Could you review it? >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>> >>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>> k/m/g. >>>>>>>>> >> >>>>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>>>> code - the >>>>>>>>> >> logfile size processing is done in >>>>>>>>> LogFileOutput::parse_options not >>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>> with >>>>>>>>> jdk9/hs not >>>>>>>>> >> hs-rt. >>>>>>>>> >> >>>>>>>>> >> That aside: >>>>>>>>> >> >>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>> >> >>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>> atomull >>>>>>>>> calls when >>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>> >> >>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>> >> >>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>> >> >>>>>>>>> >> Which makes me wonder if atomull needs renaming - does >>>>>>>>> the >>>>>>>>> "m" mean >>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>> >> >>>>>>>>> >> --- >>>>>>>>> >> >>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>> >> >>>>>>>>> >> You removed the size checking logic. >>>>>>>>> >> >>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>> that the >>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>> anywhere >>>>>>>>> in the >>>>>>>>> >> -Xlog:help output. >>>>>>>>> >> >>>>>>>>> >> Thanks, >>>>>>>>> >> David >>>>>>>>> >> ----- >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> Please review it. >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Thanks, >>>>>>>>> >>> >>>>>>>>> >>> Yasumasa >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>> >>>> PING: Could you review it? >>>>>>>>> >>>> We need more reviewer. >>>>>>>>> >>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Thanks, >>>>>>>>> >>>> >>>>>>>>> >>>> Yasumasa >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Could you review it? >>>>>>>>> >>>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Thanks, >>>>>>>>> >>>>> >>>>>>>>> >>>>> Yasumasa >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>> logFileOutput.cpp. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>> build was >>>>>>>>> succeeded. >>>>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Thanks, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Yasumasa >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>> >>>>>>> Hi, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>> Hi all, >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>> >>>>>>>> >>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>> k/m/g . >>>>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>> logFileOutput.cpp. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Thanks, >>>>>>>>> >>>>>>> Marcus >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Thanks, >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> [1] >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >> From yasuenag at gmail.com Tue May 3 14:05:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 May 2016 23:05:33 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <2286a1f9-529b-88f6-2918-07a605abef80@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <2286a1f9-529b-88f6-2918-07a605abef80@oracle.com> Message-ID: <32a62a2e-8782-04b1-ccb8-9d27e89b2be8@gmail.com> Hi Marcus, > That's good, but then we shouldn't limit it to SIZE_MAX. The overflow check in logFileOutput.cpp should be removed. In Linux 32 bits system, we cannot open > 4GB size file because we do not pass O_LARGEFILE. (we use fopen(3)) In manpage [1], we should use _FILE_OFFSET_BITS rather than O_LARGEFILE. However, makefiles for Linux, this macro is used for ostream.cpp only. Thus I think we should keep the limit of SIZE_MAX for LogFileOutput. >>>> the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. >> >> Is it no problem? > > No I don't think that's a problem. Thanks! Yasumasa [1] http://man7.org/linux/man-pages/man2/open.2.html On 2016/05/03 22:55, Marcus Larsson wrote: > > > On 05/03/2016 03:49 PM, Yasumasa Suenaga wrote: >>> This seems broken to me, we're passing &_rotate_size (a size_t*) to atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) then that's a problem, no? >> >> Thanks, Marcus! >> I changed type of _rotate_size and _current_size to julong in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ > > That's good, but then we shouldn't limit it to SIZE_MAX. The overflow check in logFileOutput.cpp should be removed. > >> >>>> the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. >> >> Is it no problem? > > No I don't think that's a problem. > > Thanks, > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/03 21:41, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>> Adding in the runtime team as they now own UL. >>>> >>>> I've reviewed the change from a coding perspective - the question for the UL owners is whether the change in semantics is appropriate: previously the filesize was interpreted as a value in KB, whereas now, without a suffix, it is just bytes. >>>> >>>> Thanks, >>>> David >>>> >>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>> >>> This seems broken to me, we're passing &_rotate_size (a size_t*) to atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) then that's a problem, no? >>> >>> Thanks, >>> Marcus >>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> So it just registered with me that currently filesize is interpreted >>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>> tests will need fixing eg: >>>>>>> >>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>> >>>>>> Thanks! >>>>>> I've fixed it in new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>> >>>>>> Following jtreg tests are passed: >>>>>> >>>>>> - hotspot/test/gc/logging >>>>>> - hotspot/test/runtime/logging >>>>>> - hotspot/test/serviceability/logging >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>> still need to ensure we don't specify a filesize that is greater than >>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>> >>>>>>>> Oh... I understood. >>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>> >>>>>>> So it just registered with me that currently filesize is interpreted >>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>> tests will need fixing eg: >>>>>>> >>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>> >>>>>>> That change in semantics may not be desirable, but I'll leave that to >>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>> >>>>>>> I note that in the existing range check: >>>>>>> >>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>> >>>>>>> the first clause is redundant. So your change seems okay. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>> > >>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>>>> range >>>>>>>>>> [0, " >>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>> FileSizeOptionKey, >>>>>>>>>> SIZE_MAX / K); >>>>>>>>>> > 194 success = false; >>>>>>>>>> >>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>> >>>>>>>>> Ah I hadn't realized this was an external value, I thought it was some >>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>> overflow check really, and ... >>>>>>>>> >>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>> >>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>> >>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>> >>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>> still need to ensure we don't specify a filesize that is greater than >>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>>>>>> still >>>>>>>>>> > surprised none of these "options" for the handling the file are >>>>>>>>>> > explicitly documented. >>>>>>>>>> >>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>> >>>>>>>>> No I just meant that amongst all that help text you already modified, >>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>> possible options for filesize. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I can help for it if I can >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>> >: >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>> > Hi David, >>>>>>>>>> > >>>>>>>>>> > Thank you for your comment. >>>>>>>>>> > >>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>> >>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>> >>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>>>> range [0, " >>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>> FileSizeOptionKey, >>>>>>>>>> SIZE_MAX / K); >>>>>>>>>> 194 success = false; >>>>>>>>>> >>>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>>> "m" mean >>>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>>> > >>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>> > >>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>> that the >>>>>>>>>> >> various log file options don't seem to be documented anywhere >>>>>>>>>> in the >>>>>>>>>> >> -Xlog:help output. >>>>>>>>>> > >>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>> >>>>>>>>>> Thanks, I had missed that example usage buried in there, but am >>>>>>>>>> still >>>>>>>>>> surprised none of these "options" for the handling the file are >>>>>>>>>> explicitly documented. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > Thanks, >>>>>>>>>> > >>>>>>>>>> > Yasumasa >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>> >> >>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> PING: >>>>>>>>>> >>> >>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>> >>> Could you review it? >>>>>>>>>> >>> >>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>> >>>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>>> k/m/g. >>>>>>>>>> >> >>>>>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>>>>> code - the >>>>>>>>>> >> logfile size processing is done in >>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>> >> configure_rotation. And of course you now need to work with >>>>>>>>>> jdk9/hs not >>>>>>>>>> >> hs-rt. >>>>>>>>>> >> >>>>>>>>>> >> That aside: >>>>>>>>>> >> >>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>> >> >>>>>>>>>> >> I don't think you need to add the Arguments:: to the atomull >>>>>>>>>> calls when >>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>> >> >>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>> >> >>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>> >> >>>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>>> "m" mean >>>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>>> >> >>>>>>>>>> >> --- >>>>>>>>>> >> >>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>> >> >>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>> >> >>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>> that the >>>>>>>>>> >> various log file options don't seem to be documented anywhere >>>>>>>>>> in the >>>>>>>>>> >> -Xlog:help output. >>>>>>>>>> >> >>>>>>>>>> >> Thanks, >>>>>>>>>> >> David >>>>>>>>>> >> ----- >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> Please review it. >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> Thanks, >>>>>>>>>> >>> >>>>>>>>>> >>> Yasumasa >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>> >>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> Thanks, >>>>>>>>>> >>>> >>>>>>>>>> >>>> Yasumasa >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Could you review it? >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Thanks, >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Yasumasa >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>> logFileOutput.cpp. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>> build was >>>>>>>>>> succeeded. >>>>>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Thanks, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>> >>>>>>> Hi, >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>>> >>>>>>>> >>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with k/m/g . >>>>>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>> logFileOutput.cpp. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>> >>>>>>> Marcus >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> [1] >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>> > From daniel.daugherty at oracle.com Tue May 3 18:47:36 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 3 May 2016 12:47:36 -0600 Subject: URGENT RFR (XXS) 8155958 quarantine failing tests from JDK-8155957 Message-ID: <4de75e90-e305-1e8c-e766-eb0c0efc3a2b@oracle.com> Greetings, I need a review of the following quarantine change: http://cr.openjdk.java.net/~dcubed/8155958-webrev/0-jdk9-hs-hotspot/ RBT testing is in progress to verify that fix does quarantine the failing tests. Thanks, in advance, for any comments, questions or suggestions. Dan From dmitry.samersoff at oracle.com Tue May 3 18:50:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 3 May 2016 21:50:43 +0300 Subject: URGENT RFR (XXS) 8155958 quarantine failing tests from JDK-8155957 In-Reply-To: <4de75e90-e305-1e8c-e766-eb0c0efc3a2b@oracle.com> References: <4de75e90-e305-1e8c-e766-eb0c0efc3a2b@oracle.com> Message-ID: <5728F303.3080801@oracle.com> Dan, Looks good for me. -Dmitry On 2016-05-03 21:47, Daniel D. Daugherty wrote: > Greetings, > > > I need a review of the following quarantine change: > > > http://cr.openjdk.java.net/~dcubed/8155958-webrev/0-jdk9-hs-hotspot/ > > > RBT testing is in progress to verify that fix does quarantine the > > failing tests. > > > Thanks, in advance, for any comments, questions or suggestions. > > > Dan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Tue May 3 19:02:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 3 May 2016 12:02:56 -0700 Subject: URGENT RFR (XXS) 8155958 quarantine failing tests from JDK-8155957 In-Reply-To: <5728F303.3080801@oracle.com> References: <4de75e90-e305-1e8c-e766-eb0c0efc3a2b@oracle.com> <5728F303.3080801@oracle.com> Message-ID: <5728F5E0.6050804@oracle.com> +1 Thanks, Serguei On 5/3/16 11:50, Dmitry Samersoff wrote: > Dan, > > Looks good for me. > > -Dmitry > > On 2016-05-03 21:47, Daniel D. Daugherty wrote: >> Greetings, >> >> >> I need a review of the following quarantine change: >> >> >> http://cr.openjdk.java.net/~dcubed/8155958-webrev/0-jdk9-hs-hotspot/ >> >> >> RBT testing is in progress to verify that fix does quarantine the >> >> failing tests. >> >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> >> Dan >> > From daniel.daugherty at oracle.com Tue May 3 19:07:30 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 3 May 2016 13:07:30 -0600 Subject: URGENT RFR (XXS) 8155958 quarantine failing tests from JDK-8155957 In-Reply-To: <5728F5E0.6050804@oracle.com> References: <4de75e90-e305-1e8c-e766-eb0c0efc3a2b@oracle.com> <5728F303.3080801@oracle.com> <5728F5E0.6050804@oracle.com> Message-ID: <140ea3d7-7f83-2159-206d-4655c7a7df0f@oracle.com> Thanks! Dan On 5/3/16 1:02 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > > On 5/3/16 11:50, Dmitry Samersoff wrote: >> Dan, >> >> Looks good for me. >> >> -Dmitry >> >> On 2016-05-03 21:47, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> >>> I need a review of the following quarantine change: >>> >>> >>> http://cr.openjdk.java.net/~dcubed/8155958-webrev/0-jdk9-hs-hotspot/ >>> >>> >>> RBT testing is in progress to verify that fix does quarantine the >>> >>> failing tests. >>> >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> >>> Dan >>> >> > From robbin.ehn at oracle.com Tue May 3 19:25:46 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 3 May 2016 21:25:46 +0200 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging Message-ID: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> Hi all, Please review this. This changeset moves redefine classes tracing to UL. Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ Passes testsuits jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist with: -Xlog:redefine+class*=trace (a few test won't run with extra options) -XX:TraceRedefineClasses=xyz turns on (aliased with) "-Xlog:redefine+class*=info" and emits a warning. (xyz is ignored) Thanks! /Robbin Example of useage: -Xlog:redefine+class+constantpool*=debug -Xlog:redefine+class+load=info -Xlog:redefine+class*=debug,redefine+class+iklass*=trace Here is an example from a test: [20.279s][debug][redefine,class,update,vtables ] vtable method update: getOptions(()Ljava/util/Properties;), updated default = false [20.279s][debug][redefine,class,subclass ] updated count in subclass=nsk.share.jvmti.ArgumentHandler to 197 [20.279s][info ][redefine,class,load ] redefined name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, obsolete_cnt=0 [20.285s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 [20.285s][trace][redefine,class,iklass,add ] scratch class not added; no methods are running [20.285s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.ArgumentHandler [20.285s][debug][redefine,class,update,constantpool] cpc entry update: getAgentOptionsString(()Ljava/lang/String;) [20.285s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.ArgumentHandler [20.285s][debug][redefine,class,update,constantpool] cpc entry update: (([Ljava/lang/String;)V) [20.285s][info ][redefine,class,load ] redefined name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, obsolete_cnt=0 [20.291s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 [20.291s][trace][redefine,class,iklass,add ] scratch class not added; no methods are running [20.291s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.JVMTITest [20.291s][debug][redefine,class,update,constantpool] cpc entry update: commonInit(([Ljava/lang/String;)[Ljava/lang/String;) [20.291s][info ][redefine,class,load ] redefined name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, obsolete_cnt=0 [20.297s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.TestBug, EMCP_cnt=3 Mapping: RC_TRACE_MESG = "redefine, class, update" - info 0x00000001 = "redefine, class, load" - info 0x00000001 = "redefine, class, load" - debug 0x00000002 = "redefine, class, load, exceptions" - info 0x00000004 = "redefine, class, timer" - info 0x00000008 = "redefine, class, subclass" - debug 0x00000100 = "redefine, class, obsolete, mark" - trace 0x00000200 = "redefine, class, iklass, purge" - trace 0x00000400 = "redefine, class, iklass, add" - trace 0x00000800 = "redefine, class, breakpoint" - debug 0x00001000->0x00002000 = "redefine, class, obsolete" - trace 0x00001000 = "redefine, class, obsolete" - trace 0x00002000 = REMOVED 0x00004000 = "redefine, class, obsolete, metadata" - trace 0x00004000 = "redefine, class, dump" - trace 0x00008000 = "redefine, class, normalize" - trace 0x00010000 = "redefine, class, constantpool" - info 0x00020000 = "redefine, class, constantpool" - debug 0x00040000 = "redefine, class, constantpool" - trace 0x00080000 = "redefine, class, constantpool" - trace 0x00100000-0x00400000 = "redefine, class, update" - info 0x00100000 = "redefine, class, update, vtables" - debug 0x00200000 = "redefine, class, update, itables" - debug 0x00400000 = "redefine, class, update, constantpool" - debug 0x00800000 = "redefine, class, methodcomparator" - debug 0x01000000 = "redefine, class, nmethod" - debug 0x02000000 = "redefine, class, annotation" - debug 0x04000000 = "redefine, class, stackmap" - debug 0x08000000 = "redefine, class, oopmap" - debug -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 3 20:40:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 06:40:50 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> Message-ID: <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >> This seems broken to me, we're passing &_rotate_size (a size_t*) to >> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >> then that's a problem, no? > > Thanks, Marcus! Yes good catch. I would have hoped the compiler would have complained about that on 32-bit. > I changed type of _rotate_size and _current_size to julong in new webrev: I would not have done that but instead used a temporary julong for the parse result, then range check, then assign to the actual _rotate_size etc with a cast. That is less disruptive than changing the existing types IMHO. Thanks, David > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ > >>> the question for the UL owners is whether the change in semantics is >>> appropriate: previously the filesize was interpreted as a value in >>> KB, whereas now, without a suffix, it is just bytes. > > Is it no problem? > > > Thanks, > > Yasumasa > > > On 2016/05/03 21:41, Marcus Larsson wrote: >> Hi, >> >> >> On 05/03/2016 02:25 PM, David Holmes wrote: >>> Adding in the runtime team as they now own UL. >>> >>> I've reviewed the change from a coding perspective - the question for >>> the UL owners is whether the change in semantics is appropriate: >>> previously the filesize was interpreted as a value in KB, whereas >>> now, without a suffix, it is just bytes. >>> >>> Thanks, >>> David >>> >>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >> >> This seems broken to me, we're passing &_rotate_size (a size_t*) to >> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >> then that's a problem, no? >> >> Thanks, >> Marcus >> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> So it just registered with me that currently filesize is interpreted >>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>> tests will need fixing eg: >>>>>> >>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>> >>>>> Thanks! >>>>> I've fixed it in new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>> >>>>> Following jtreg tests are passed: >>>>> >>>>> - hotspot/test/gc/logging >>>>> - hotspot/test/runtime/logging >>>>> - hotspot/test/serviceability/logging >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>> than >>>>>>>> SIZE_MAX on 32-bit. >>>>>>> >>>>>>> Oh... I understood. >>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>> >>>>>> So it just registered with me that currently filesize is interpreted >>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>> tests will need fixing eg: >>>>>> >>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>> >>>>>> That change in semantics may not be desirable, but I'll leave that to >>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>> >>>>>> I note that in the existing range check: >>>>>> >>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>> >>>>>> the first clause is redundant. So your change seems okay. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> > You still removed the size bounds checks: >>>>>>>>> > >>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>>> range >>>>>>>>> [0, " >>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>> FileSizeOptionKey, >>>>>>>>> SIZE_MAX / K); >>>>>>>>> > 194 success = false; >>>>>>>>> >>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>> >>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>> was some >>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>> overflow check really, and ... >>>>>>>> >>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>> >>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>> >>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>> LogFileOutput::parse_options(). >>>>>>>> >>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>> than >>>>>>>> SIZE_MAX on 32-bit. >>>>>>>> >>>>>>>>> >>>>>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>>>>> still >>>>>>>>> > surprised none of these "options" for the handling the file are >>>>>>>>> > explicitly documented. >>>>>>>>> >>>>>>>>> I do not know how we can documented about it. >>>>>>>>> (Is it internal process in Oracle?) >>>>>>>> >>>>>>>> No I just meant that amongst all that help text you already >>>>>>>> modified, >>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>> possible options for filesize. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I can help for it if I can >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [2] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>> >: >>>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>> > Hi David, >>>>>>>>> > >>>>>>>>> > Thank you for your comment. >>>>>>>>> > >>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>> >>>>>>>>> You still removed the size bounds checks: >>>>>>>>> >>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>> be in >>>>>>>>> range [0, " >>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>> FileSizeOptionKey, >>>>>>>>> SIZE_MAX / K); >>>>>>>>> 194 success = false; >>>>>>>>> >>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>> "m" mean >>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>> > >>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>> > >>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>> that the >>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>> anywhere >>>>>>>>> in the >>>>>>>>> >> -Xlog:help output. >>>>>>>>> > >>>>>>>>> > I updated help message in new webrev. >>>>>>>>> >>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>> but am >>>>>>>>> still >>>>>>>>> surprised none of these "options" for the handling the file >>>>>>>>> are >>>>>>>>> explicitly documented. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > >>>>>>>>> > Yasumasa >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>> >> Hi Yasumasa, >>>>>>>>> >> >>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>> PING: >>>>>>>>> >>> >>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>> >>> Could you review it? >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>> >>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>> k/m/g. >>>>>>>>> >> >>>>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>>>> code - the >>>>>>>>> >> logfile size processing is done in >>>>>>>>> LogFileOutput::parse_options not >>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>> with >>>>>>>>> jdk9/hs not >>>>>>>>> >> hs-rt. >>>>>>>>> >> >>>>>>>>> >> That aside: >>>>>>>>> >> >>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>> >> >>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>> atomull >>>>>>>>> calls when >>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>> >> >>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>> >> >>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>> >> >>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>> "m" mean >>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>> >> >>>>>>>>> >> --- >>>>>>>>> >> >>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>> >> >>>>>>>>> >> You removed the size checking logic. >>>>>>>>> >> >>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>> that the >>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>> anywhere >>>>>>>>> in the >>>>>>>>> >> -Xlog:help output. >>>>>>>>> >> >>>>>>>>> >> Thanks, >>>>>>>>> >> David >>>>>>>>> >> ----- >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> Please review it. >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> Thanks, >>>>>>>>> >>> >>>>>>>>> >>> Yasumasa >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>> >>>> PING: Could you review it? >>>>>>>>> >>>> We need more reviewer. >>>>>>>>> >>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> Thanks, >>>>>>>>> >>>> >>>>>>>>> >>>> Yasumasa >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>> >>>>> >>>>>>>>> >>>>> Could you review it? >>>>>>>>> >>>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> Thanks, >>>>>>>>> >>>>> >>>>>>>>> >>>>> Yasumasa >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>> logFileOutput.cpp. >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>> build was >>>>>>>>> succeeded. >>>>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Thanks, >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> Yasumasa >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>> >>>>>>> Hi, >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>> Hi all, >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>> >>>>>>>> >>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>> k/m/g . >>>>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>> logFileOutput.cpp. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> Thanks, >>>>>>>>> >>>>>>> Marcus >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Thanks, >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> [1] >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >> From yasuenag at gmail.com Wed May 4 00:19:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 09:19:36 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> Message-ID: <57294018.6060309@gmail.com> Hi David, Marcus, > I would not have done that but instead used a temporary julong for the parse result, then range check, then assign to the actual _rotate_size etc with a cast. Thanks. However, I guess we will encounter error when we access to > 2GB size file. (Sorry, 4GB is incorrect.) I do not investigate for it yet. So I'm not sure whether it is correct. In terms of this issue, should I keep range check and use julong temporary value for _rotate_size? Yasumasa On 2016/05/04 5:40, David Holmes wrote: > On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>> then that's a problem, no? >> >> Thanks, Marcus! > > Yes good catch. I would have hoped the compiler would have complained about that on 32-bit. > >> I changed type of _rotate_size and _current_size to julong in new webrev: > > I would not have done that but instead used a temporary julong for the parse result, then range check, then assign to the actual _rotate_size etc with a cast. That is less disruptive than changing the existing types IMHO. > > Thanks, > David > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >> >>>> the question for the UL owners is whether the change in semantics is >>>> appropriate: previously the filesize was interpreted as a value in >>>> KB, whereas now, without a suffix, it is just bytes. >> >> Is it no problem? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/03 21:41, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>> Adding in the runtime team as they now own UL. >>>> >>>> I've reviewed the change from a coding perspective - the question for >>>> the UL owners is whether the change in semantics is appropriate: >>>> previously the filesize was interpreted as a value in KB, whereas >>>> now, without a suffix, it is just bytes. >>>> >>>> Thanks, >>>> David >>>> >>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>> >>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>> then that's a problem, no? >>> >>> Thanks, >>> Marcus >>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> So it just registered with me that currently filesize is interpreted >>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>> tests will need fixing eg: >>>>>>> >>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>> >>>>>> Thanks! >>>>>> I've fixed it in new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>> >>>>>> Following jtreg tests are passed: >>>>>> >>>>>> - hotspot/test/gc/logging >>>>>> - hotspot/test/runtime/logging >>>>>> - hotspot/test/serviceability/logging >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>> than >>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>> >>>>>>>> Oh... I understood. >>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>> >>>>>>> So it just registered with me that currently filesize is interpreted >>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>> tests will need fixing eg: >>>>>>> >>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>> >>>>>>> That change in semantics may not be desirable, but I'll leave that to >>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>> >>>>>>> I note that in the existing range check: >>>>>>> >>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>> >>>>>>> the first clause is redundant. So your change seems okay. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>> > >>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must be in >>>>>>>>>> range >>>>>>>>>> [0, " >>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>> FileSizeOptionKey, >>>>>>>>>> SIZE_MAX / K); >>>>>>>>>> > 194 success = false; >>>>>>>>>> >>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>> >>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>> was some >>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>> overflow check really, and ... >>>>>>>>> >>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>> >>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>> >>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>> >>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>> than >>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > Thanks, I had missed that example usage buried in there, but am >>>>>>>>>> still >>>>>>>>>> > surprised none of these "options" for the handling the file are >>>>>>>>>> > explicitly documented. >>>>>>>>>> >>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>> >>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>> modified, >>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>> possible options for filesize. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I can help for it if I can >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [2] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>> >: >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>> > Hi David, >>>>>>>>>> > >>>>>>>>>> > Thank you for your comment. >>>>>>>>>> > >>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>> >>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>> >>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>> be in >>>>>>>>>> range [0, " >>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>> FileSizeOptionKey, >>>>>>>>>> SIZE_MAX / K); >>>>>>>>>> 194 success = false; >>>>>>>>>> >>>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>>> "m" mean >>>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>>> > >>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>> > >>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>> that the >>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>> anywhere >>>>>>>>>> in the >>>>>>>>>> >> -Xlog:help output. >>>>>>>>>> > >>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>> >>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>> but am >>>>>>>>>> still >>>>>>>>>> surprised none of these "options" for the handling the file >>>>>>>>>> are >>>>>>>>>> explicitly documented. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > Thanks, >>>>>>>>>> > >>>>>>>>>> > Yasumasa >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>> >> >>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> PING: >>>>>>>>>> >>> >>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>> >>> Could you review it? >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>> >>>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>>> k/m/g. >>>>>>>>>> >> >>>>>>>>>> >> Your webrev seems out of date with respect to the current >>>>>>>>>> code - the >>>>>>>>>> >> logfile size processing is done in >>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>>> with >>>>>>>>>> jdk9/hs not >>>>>>>>>> >> hs-rt. >>>>>>>>>> >> >>>>>>>>>> >> That aside: >>>>>>>>>> >> >>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>> >> >>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>> atomull >>>>>>>>>> calls when >>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>> >> >>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>> >> >>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>> >> >>>>>>>>>> >> Which makes me wonder if atomull needs renaming - does the >>>>>>>>>> "m" mean >>>>>>>>>> >> memory? atojulong would seem more appropriate regardless. >>>>>>>>>> >> >>>>>>>>>> >> --- >>>>>>>>>> >> >>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>> >> >>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>> >> >>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>> that the >>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>> anywhere >>>>>>>>>> in the >>>>>>>>>> >> -Xlog:help output. >>>>>>>>>> >> >>>>>>>>>> >> Thanks, >>>>>>>>>> >> David >>>>>>>>>> >> ----- >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> Please review it. >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> Thanks, >>>>>>>>>> >>> >>>>>>>>>> >>> Yasumasa >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>> >>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> Thanks, >>>>>>>>>> >>>> >>>>>>>>>> >>>> Yasumasa >>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Could you review it? >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Thanks, >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> Yasumasa >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>> logFileOutput.cpp. >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>> build was >>>>>>>>>> succeeded. >>>>>>>>>> >>>>>> However, it should be included in logFileOutput.cpp . >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Thanks, >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>> >>>>>>> Hi, >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>>> >>>>>>>> >>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>> k/m/g . >>>>>>>>>> >>>>>>>> I think we can use option parser in arguments.cpp . >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>> logFileOutput.cpp. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>> >>>>>>> Marcus >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> [1] >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>> From david.holmes at oracle.com Wed May 4 01:45:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 11:45:52 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <57294018.6060309@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> Message-ID: <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: > Hi David, Marcus, > >> I would not have done that but instead used a temporary julong for the >> parse result, then range check, then assign to the actual _rotate_size >> etc with a cast. > > Thanks. > However, I guess we will encounter error when we access to > 2GB size file. > (Sorry, 4GB is incorrect.) That would seem to be a different issue. > I do not investigate for it yet. So I'm not sure whether it is correct. > In terms of this issue, should I keep range check and use julong temporary > value for _rotate_size? I would go this route yes. Use the Arguments code to do the parsing; apply the same range check as exists today (which may or may not be sufficient, but that is a different issue), then assign. Thanks, David > > Yasumasa > > > On 2016/05/04 5:40, David Holmes wrote: >> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>> then that's a problem, no? >>> >>> Thanks, Marcus! >> >> Yes good catch. I would have hoped the compiler would have complained >> about that on 32-bit. >> >>> I changed type of _rotate_size and _current_size to julong in new >>> webrev: >> >> I would not have done that but instead used a temporary julong for the >> parse result, then range check, then assign to the actual _rotate_size >> etc with a cast. That is less disruptive than changing the existing >> types IMHO. >> >> Thanks, >> David >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>> >>>>> the question for the UL owners is whether the change in semantics is >>>>> appropriate: previously the filesize was interpreted as a value in >>>>> KB, whereas now, without a suffix, it is just bytes. >>> >>> Is it no problem? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>> Adding in the runtime team as they now own UL. >>>>> >>>>> I've reviewed the change from a coding perspective - the question for >>>>> the UL owners is whether the change in semantics is appropriate: >>>>> previously the filesize was interpreted as a value in KB, whereas >>>>> now, without a suffix, it is just bytes. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>> >>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>> then that's a problem, no? >>>> >>>> Thanks, >>>> Marcus >>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> So it just registered with me that currently filesize is >>>>>>>> interpreted >>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>> tests will need fixing eg: >>>>>>>> >>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>> >>>>>>> Thanks! >>>>>>> I've fixed it in new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>> >>>>>>> Following jtreg tests are passed: >>>>>>> >>>>>>> - hotspot/test/gc/logging >>>>>>> - hotspot/test/runtime/logging >>>>>>> - hotspot/test/serviceability/logging >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>> than >>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>> >>>>>>>>> Oh... I understood. >>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>> >>>>>>>> So it just registered with me that currently filesize is >>>>>>>> interpreted >>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>> tests will need fixing eg: >>>>>>>> >>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>> >>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>> that to >>>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>>> >>>>>>>> I note that in the existing range check: >>>>>>>> >>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>> >>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>> > >>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>> be in >>>>>>>>>>> range >>>>>>>>>>> [0, " >>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>> > 194 success = false; >>>>>>>>>>> >>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>> >>>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>>> was some >>>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>>> overflow check really, and ... >>>>>>>>>> >>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>> >>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>> >>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>> >>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>> than >>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>>>> but am >>>>>>>>>>> still >>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>> file are >>>>>>>>>>> > explicitly documented. >>>>>>>>>>> >>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>> >>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>> modified, >>>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>>> possible options for filesize. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I can help for it if I can >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [2] >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> > Hi David, >>>>>>>>>>> > >>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>> > >>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>> >>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>> be in >>>>>>>>>>> range [0, " >>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>> 194 success = false; >>>>>>>>>>> >>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>> does the >>>>>>>>>>> "m" mean >>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>> regardless. >>>>>>>>>>> > >>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>> > >>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>> that the >>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>> anywhere >>>>>>>>>>> in the >>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>> > >>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>> >>>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>>> but am >>>>>>>>>>> still >>>>>>>>>>> surprised none of these "options" for the handling the file >>>>>>>>>>> are >>>>>>>>>>> explicitly documented. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > Thanks, >>>>>>>>>>> > >>>>>>>>>>> > Yasumasa >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>> >> >>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> PING: >>>>>>>>>>> >>> >>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>> >>> Could you review it? >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>> >>> >>>>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>>>> k/m/g. >>>>>>>>>>> >> >>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>> current >>>>>>>>>>> code - the >>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>>>> with >>>>>>>>>>> jdk9/hs not >>>>>>>>>>> >> hs-rt. >>>>>>>>>>> >> >>>>>>>>>>> >> That aside: >>>>>>>>>>> >> >>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>> >> >>>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>>> atomull >>>>>>>>>>> calls when >>>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>>> >> >>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>> >> >>>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>>> >> >>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>> does the >>>>>>>>>>> "m" mean >>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>> regardless. >>>>>>>>>>> >> >>>>>>>>>>> >> --- >>>>>>>>>>> >> >>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>> >> >>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>> >> >>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>> that the >>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>> anywhere >>>>>>>>>>> in the >>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>> >> >>>>>>>>>>> >> Thanks, >>>>>>>>>>> >> David >>>>>>>>>>> >> ----- >>>>>>>>>>> >> >>>>>>>>>>> >>> >>>>>>>>>>> >>> Please review it. >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> Thanks, >>>>>>>>>>> >>> >>>>>>>>>>> >>> Yasumasa >>>>>>>>>>> >>> >>>>>>>>>>> >>> >>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Thanks, >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>>> build was >>>>>>>>>>> succeeded. >>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>> k/m/g . >>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>> arguments.cpp . >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>> >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>> From marcus.larsson at oracle.com Wed May 4 06:49:39 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 08:49:39 +0200 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> Message-ID: Hi, On 05/04/2016 03:45 AM, David Holmes wrote: > On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >> Hi David, Marcus, >> >>> I would not have done that but instead used a temporary julong for the >>> parse result, then range check, then assign to the actual _rotate_size >>> etc with a cast. >> >> Thanks. >> However, I guess we will encounter error when we access to > 2GB size >> file. >> (Sorry, 4GB is incorrect.) > > That would seem to be a different issue. > >> I do not investigate for it yet. So I'm not sure whether it is correct. >> In terms of this issue, should I keep range check and use julong >> temporary >> value for _rotate_size? > > I would go this route yes. Use the Arguments code to do the parsing; > apply the same range check as exists today (which may or may not be > sufficient, but that is a different issue), then assign. I think that would be better too. Thanks, Marcus > > Thanks, > David > >> >> Yasumasa >> >> >> On 2016/05/04 5:40, David Holmes wrote: >>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>> then that's a problem, no? >>>> >>>> Thanks, Marcus! >>> >>> Yes good catch. I would have hoped the compiler would have complained >>> about that on 32-bit. >>> >>>> I changed type of _rotate_size and _current_size to julong in new >>>> webrev: >>> >>> I would not have done that but instead used a temporary julong for the >>> parse result, then range check, then assign to the actual _rotate_size >>> etc with a cast. That is less disruptive than changing the existing >>> types IMHO. >>> >>> Thanks, >>> David >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>> >>>>>> the question for the UL owners is whether the change in semantics is >>>>>> appropriate: previously the filesize was interpreted as a value in >>>>>> KB, whereas now, without a suffix, it is just bytes. >>>> >>>> Is it no problem? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>> Adding in the runtime team as they now own UL. >>>>>> >>>>>> I've reviewed the change from a coding perspective - the question >>>>>> for >>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>> previously the filesize was interpreted as a value in KB, whereas >>>>>> now, without a suffix, it is just bytes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>> >>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>> then that's a problem, no? >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>> interpreted >>>>>>>>> as a value in KB. With this change it will be in bytes - that >>>>>>>>> means >>>>>>>>> tests will need fixing eg: >>>>>>>>> >>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>> >>>>>>>> Thanks! >>>>>>>> I've fixed it in new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>> >>>>>>>> Following jtreg tests are passed: >>>>>>>> >>>>>>>> - hotspot/test/gc/logging >>>>>>>> - hotspot/test/runtime/logging >>>>>>>> - hotspot/test/serviceability/logging >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we >>>>>>>>>>> would >>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>> greater >>>>>>>>>>> than >>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>> >>>>>>>>>> Oh... I understood. >>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>> >>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>> interpreted >>>>>>>>> as a value in KB. With this change it will be in bytes - that >>>>>>>>> means >>>>>>>>> tests will need fixing eg: >>>>>>>>> >>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>> >>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>> that to >>>>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>>>> >>>>>>>>> I note that in the existing range check: >>>>>>>>> >>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>> >>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>> > >>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>> be in >>>>>>>>>>>> range >>>>>>>>>>>> [0, " >>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>> >>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>> >>>>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>>>> was some >>>>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>>>> overflow check really, and ... >>>>>>>>>>> >>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>> >>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>> >>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>> >>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we >>>>>>>>>>> would >>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>> greater >>>>>>>>>>> than >>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>>>>> but am >>>>>>>>>>>> still >>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>> file are >>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>> >>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>> >>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>> modified, >>>>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>>>> possible options for filesize. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [2] >>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> > Hi David, >>>>>>>>>>>> > >>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>> > >>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>> >>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / >>>>>>>>>>>> K) { >>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>> be in >>>>>>>>>>>> range [0, " >>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>> 194 success = false; >>>>>>>>>>>> >>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>> does the >>>>>>>>>>>> "m" mean >>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>> regardless. >>>>>>>>>>>> > >>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>> > >>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>> surprised >>>>>>>>>>>> that the >>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>> anywhere >>>>>>>>>>>> in the >>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>> > >>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>>>> but am >>>>>>>>>>>> still >>>>>>>>>>>> surprised none of these "options" for the handling the >>>>>>>>>>>> file >>>>>>>>>>>> are >>>>>>>>>>>> explicitly documented. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks, >>>>>>>>>>>> > >>>>>>>>>>>> > Yasumasa >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>> >> >>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> PING: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> If this patch is merged, user can set logfile size >>>>>>>>>>>> with >>>>>>>>>>>> k/m/g. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>> current >>>>>>>>>>>> code - the >>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>>>>> with >>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>> >> >>>>>>>>>>>> >> That aside: >>>>>>>>>>>> >> >>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>> >> >>>>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>>>> atomull >>>>>>>>>>>> calls when >>>>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>>>> >> >>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>> >> >>>>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>> does the >>>>>>>>>>>> "m" mean >>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>> regardless. >>>>>>>>>>>> >> >>>>>>>>>>>> >> --- >>>>>>>>>>>> >> >>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>> >> >>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>> surprised >>>>>>>>>>>> that the >>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>> anywhere >>>>>>>>>>>> in the >>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Thanks, >>>>>>>>>>>> >> David >>>>>>>>>>>> >> ----- >>>>>>>>>>>> >> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>>>> build was >>>>>>>>>>>> succeeded. >>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>> below: >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>> k/m/g . >>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>> From marcus.larsson at oracle.com Wed May 4 09:33:18 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 11:33:18 +0200 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> Message-ID: <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> Hi, On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ I would prefer to generate the option string from the actual options rather than saving the string from when it was configured. This would also produce/print the options for outputs that are using the defaults (which is not the case now). The filesize option could then use byte_size_in_proper_unit and proper_unit_for_byte_size to make it easier to read. Also, get_option_string() should just be called option_string(). Thanks, Marcus > > This patch makes to show option string of LogFileOutput. > > > Thanks, > > Yasumasa > > > On 2016/04/19 22:55, Yasumasa Suenaga wrote: >> I adapted changes to jdk9/hs/hotspot repos. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >> >> Please review. >> >> >> Yasumasa >> >> >> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>> PING: >>> >>> I've sent review request for JDK-8153074. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>> >>> If this patch is merged, user can confirm output option via VM.log >>> jcmd. >>> >>> >>> Please review and sponsor it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>> CC'ed to serviceability-dev. >>>>> >>>>> Could you review it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This request review is related to [1]. >>>>>> >>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>> >>>>>> Output sample: >>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 >>>>>> time,level, >>>>>> >>>>>> I uploaded webrev. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>> >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>> >>>>>> From alexander.kulyakhtin at oracle.com Wed May 4 12:17:11 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 4 May 2016 05:17:11 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: Hi Sergey, Thank you very much for the review. Please, find the updated webrev with your findings corrected at: http://cr.openjdk.java.net/~akulyakh/8153978_02/index.html Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Cc: aleksey.voytilov at oracle.com Sent: Tuesday, May 3, 2016 1:06:05 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, Could you, fix a couple of minor issues? test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java 58 for(Module mod : my.modules()) { 59 if(!jvmtiModules.contains(mod)) { A space is missed after the 'for' and 'if' keywords. test/serviceability/jvmti/GetModulesInfo/ModulesInfo.java. 31 boolean compareExcludingUnnamed(ModulesInfo other) { I'd suggest to call it compareNamed. Otherwise, the new test looks great. Thanks a lot for taking care about it! Thanks, Serguei On 4/29/16 06:12, Alexander Kulyakhtin wrote: Hi, Could you, please, review these test-only changes (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the modules info as returned by the JVMTI" Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/ The new test verifies that JVMTI returns the correct info about the modules loaded at the application startup. It also verifies that the returned info is consistent with the same info returned by the Java API. It then loads a new named module and checks the correctness of the JVMTI info again. Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. Best regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed May 4 12:29:23 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 21:29:23 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> Message-ID: Hi David, Marcus, Thank you for your comment. I uploaded new webrev. Could you review it again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ Thanks, Yasumasa On 2016/05/04 15:49, Marcus Larsson wrote: > Hi, > > On 05/04/2016 03:45 AM, David Holmes wrote: >> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>> Hi David, Marcus, >>> >>>> I would not have done that but instead used a temporary julong for the >>>> parse result, then range check, then assign to the actual _rotate_size >>>> etc with a cast. >>> >>> Thanks. >>> However, I guess we will encounter error when we access to > 2GB size file. >>> (Sorry, 4GB is incorrect.) >> >> That would seem to be a different issue. >> >>> I do not investigate for it yet. So I'm not sure whether it is correct. >>> In terms of this issue, should I keep range check and use julong temporary >>> value for _rotate_size? >> >> I would go this route yes. Use the Arguments code to do the parsing; apply the same range check as exists today (which may or may not be sufficient, but that is a different issue), then assign. > > I think that would be better too. > > Thanks, > Marcus > >> >> Thanks, >> David >> >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 5:40, David Holmes wrote: >>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>>> then that's a problem, no? >>>>> >>>>> Thanks, Marcus! >>>> >>>> Yes good catch. I would have hoped the compiler would have complained >>>> about that on 32-bit. >>>> >>>>> I changed type of _rotate_size and _current_size to julong in new >>>>> webrev: >>>> >>>> I would not have done that but instead used a temporary julong for the >>>> parse result, then range check, then assign to the actual _rotate_size >>>> etc with a cast. That is less disruptive than changing the existing >>>> types IMHO. >>>> >>>> Thanks, >>>> David >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>> >>>>>>> the question for the UL owners is whether the change in semantics is >>>>>>> appropriate: previously the filesize was interpreted as a value in >>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>> >>>>> Is it no problem? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>> Adding in the runtime team as they now own UL. >>>>>>> >>>>>>> I've reviewed the change from a coding perspective - the question for >>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>> previously the filesize was interpreted as a value in KB, whereas >>>>>>> now, without a suffix, it is just bytes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review and sponsor it? >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>> >>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>>> then that's a problem, no? >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>> interpreted >>>>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>>>> tests will need fixing eg: >>>>>>>>>> >>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> I've fixed it in new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>> >>>>>>>>> Following jtreg tests are passed: >>>>>>>>> >>>>>>>>> - hotspot/test/gc/logging >>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>>>> than >>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>> >>>>>>>>>>> Oh... I understood. >>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>> >>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>> interpreted >>>>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>>>> tests will need fixing eg: >>>>>>>>>> >>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>> >>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>> that to >>>>>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>>>>> >>>>>>>>>> I note that in the existing range check: >>>>>>>>>> >>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>> >>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>> > >>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>> be in >>>>>>>>>>>>> range >>>>>>>>>>>>> [0, " >>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>> >>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>> >>>>>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>>>>> was some >>>>>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>> >>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>> >>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>> >>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>> >>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>>>> than >>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>> but am >>>>>>>>>>>>> still >>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>> file are >>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>> >>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>> >>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>> modified, >>>>>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [2] >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>> >>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>> be in >>>>>>>>>>>>> range [0, " >>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>> >>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>> does the >>>>>>>>>>>>> "m" mean >>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>> regardless. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>> > >>>>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>>>> that the >>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>> anywhere >>>>>>>>>>>>> in the >>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>> but am >>>>>>>>>>>>> still >>>>>>>>>>>>> surprised none of these "options" for the handling the file >>>>>>>>>>>>> are >>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>> current >>>>>>>>>>>>> code - the >>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>>>>>> with >>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>>>>> atomull >>>>>>>>>>>>> calls when >>>>>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>> does the >>>>>>>>>>>>> "m" mean >>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>> regardless. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> --- >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>>>> that the >>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>> anywhere >>>>>>>>>>>>> in the >>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>> >> David >>>>>>>>>>>>> >> ----- >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>>>>> build was >>>>>>>>>>>>> succeeded. >>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>> >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>> > From marcus.larsson at oracle.com Wed May 4 12:38:44 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 14:38:44 +0200 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> Message-ID: <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> Hi, On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: > Hi David, Marcus, > > Thank you for your comment. > I uploaded new webrev. Could you review it again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ Can you join these two cases: 193 if (!success) { 194 break; 195 } else if (value > SIZE_MAX) { into something like if (!success || values > SIZE_MAX) { so that we properly fail to configure the output and print the error message when atojulong fails as well? Also, I think you probably need a static_cast here: 201 _rotate_size = value; to avoid compiler warnings on 32-bit platforms. Thanks, Marcus > > > Thanks, > > Yasumasa > > > On 2016/05/04 15:49, Marcus Larsson wrote: >> Hi, >> >> On 05/04/2016 03:45 AM, David Holmes wrote: >>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>> Hi David, Marcus, >>>> >>>>> I would not have done that but instead used a temporary julong for >>>>> the >>>>> parse result, then range check, then assign to the actual >>>>> _rotate_size >>>>> etc with a cast. >>>> >>>> Thanks. >>>> However, I guess we will encounter error when we access to > 2GB >>>> size file. >>>> (Sorry, 4GB is incorrect.) >>> >>> That would seem to be a different issue. >>> >>>> I do not investigate for it yet. So I'm not sure whether it is >>>> correct. >>>> In terms of this issue, should I keep range check and use julong >>>> temporary >>>> value for _rotate_size? >>> >>> I would go this route yes. Use the Arguments code to do the parsing; >>> apply the same range check as exists today (which may or may not be >>> sufficient, but that is a different issue), then assign. >> >> I think that would be better too. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> David >>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 5:40, David Holmes wrote: >>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>> sizeof(size_t) >>>>>>> then that's a problem, no? >>>>>> >>>>>> Thanks, Marcus! >>>>> >>>>> Yes good catch. I would have hoped the compiler would have complained >>>>> about that on 32-bit. >>>>> >>>>>> I changed type of _rotate_size and _current_size to julong in new >>>>>> webrev: >>>>> >>>>> I would not have done that but instead used a temporary julong for >>>>> the >>>>> parse result, then range check, then assign to the actual >>>>> _rotate_size >>>>> etc with a cast. That is less disruptive than changing the existing >>>>> types IMHO. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>> >>>>>>>> the question for the UL owners is whether the change in >>>>>>>> semantics is >>>>>>>> appropriate: previously the filesize was interpreted as a value in >>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>> >>>>>> Is it no problem? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>> >>>>>>>> I've reviewed the change from a coding perspective - the >>>>>>>> question for >>>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>>> previously the filesize was interpreted as a value in KB, whereas >>>>>>>> now, without a suffix, it is just bytes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>> >>>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>> sizeof(size_t) >>>>>>> then that's a problem, no? >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>> interpreted >>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>> that means >>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>> >>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>> >>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>> >>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>> we would >>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>> greater >>>>>>>>>>>>> than >>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>> >>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>> interpreted >>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>> that means >>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>> >>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>> >>>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>>> that to >>>>>>>>>>> the owners of this code to decide (and I hope they jump in >>>>>>>>>>> soon!) >>>>>>>>>>> >>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>> >>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>> >>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / >>>>>>>>>>>>>> K) { >>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>> be in >>>>>>>>>>>>>> range >>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>> >>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>> >>>>>>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>>>>>> was some >>>>>>>>>>>>> internally enforced maximum file size limit. So this is >>>>>>>>>>>>> just an >>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>> >>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>> >>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>> >>>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>> >>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>> we would >>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>> greater >>>>>>>>>>>>> than >>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>>> but am >>>>>>>>>>>>>> still >>>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>>> file are >>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>> >>>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>>> modified, >>>>>>>>>>>>> there is nothing, that I could see, that actually >>>>>>>>>>>>> describes the >>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [2] >>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>> >: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX >>>>>>>>>>>>>> / K) { >>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>> be in >>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>> does the >>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>> surprised >>>>>>>>>>>>>> that the >>>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>>> but am >>>>>>>>>>>>>> still >>>>>>>>>>>>>> surprised none of these "options" for the handling >>>>>>>>>>>>>> the file >>>>>>>>>>>>>> are >>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile >>>>>>>>>>>>>> size with >>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> code - the >>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>> >> configure_rotation. And of course you now need to >>>>>>>>>>>>>> work >>>>>>>>>>>>>> with >>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>>>>>> atomull >>>>>>>>>>>>>> calls when >>>>>>>>>>>>>> >> you are executing in Arguments code - lines 2643, >>>>>>>>>>>>>> 2660 >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>> does the >>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>> surprised >>>>>>>>>>>>>> that the >>>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>> >> David >>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp >>>>>>>>>>>>>> . So >>>>>>>>>>>>>> build was >>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>>>> below: >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed May 4 12:59:39 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 21:59:39 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> Message-ID: <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> Hi Marcus, Thank you for your comment. http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ I fixed to use _rotate_size and _file_count directly to show VM.log list jcmd. I do not store option string, and I added new function to print option string. Could you review it again? Thanks. Yasumasa On 2016/05/04 18:33, Marcus Larsson wrote: > Hi, > > > On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ > > I would prefer to generate the option string from the actual options rather than saving the string from when it was configured. This would also produce/print the options for outputs that are using the defaults (which is not the case now). The filesize option could then use byte_size_in_proper_unit and proper_unit_for_byte_size to make it easier to read. > > Also, get_option_string() should just be called option_string(). > > Thanks, > Marcus > >> >> This patch makes to show option string of LogFileOutput. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>> I adapted changes to jdk9/hs/hotspot repos. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>> >>> Please review. >>> >>> >>> Yasumasa >>> >>> >>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>> PING: >>>> >>>> I've sent review request for JDK-8153074. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>> >>>> If this patch is merged, user can confirm output option via VM.log jcmd. >>>> >>>> >>>> Please review and sponsor it. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>> CC'ed to serviceability-dev. >>>>>> >>>>>> Could you review it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This request review is related to [1]. >>>>>>> >>>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>>> >>>>>>> Output sample: >>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>>>>> >>>>>>> I uploaded webrev. Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>> >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>> >>>>>>> > From marcus.larsson at oracle.com Wed May 4 13:35:35 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 15:35:35 +0200 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> Message-ID: Hi, On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: > Hi Marcus, > > Thank you for your comment. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ Looks better. The format for _rotate_size should be SIZE_FORMAT. While we're at it I think it would be good (as I mentioned) to use a proper unit for the filesize. Basically changing 93 out->print("filecount=%u,filesize=%lu ", _file_count, _rotate_size); into 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); Thanks, Marcus > > I fixed to use _rotate_size and _file_count directly to show VM.log > list jcmd. > I do not store option string, and I added new function to print option > string. > > Could you review it again? > > > Thanks. > > Yasumasa > > > On 2016/05/04 18:33, Marcus Larsson wrote: >> Hi, >> >> >> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >> >> I would prefer to generate the option string from the actual options >> rather than saving the string from when it was configured. This would >> also produce/print the options for outputs that are using the >> defaults (which is not the case now). The filesize option could then >> use byte_size_in_proper_unit and proper_unit_for_byte_size to make it >> easier to read. >> >> Also, get_option_string() should just be called option_string(). >> >> Thanks, >> Marcus >> >>> >>> This patch makes to show option string of LogFileOutput. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>> I adapted changes to jdk9/hs/hotspot repos. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>> >>>> Please review. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>> PING: >>>>> >>>>> I've sent review request for JDK-8153074. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>> >>>>> If this patch is merged, user can confirm output option via VM.log >>>>> jcmd. >>>>> >>>>> >>>>> Please review and sponsor it. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>> CC'ed to serviceability-dev. >>>>>>> >>>>>>> Could you review it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>> >>>>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>>>> >>>>>>>> Output sample: >>>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 >>>>>>>> time,level, >>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>> >>>>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed May 4 13:43:48 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 22:43:48 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> Message-ID: <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> Thanks, Marcus! > into something like > > if (!success || values > SIZE_MAX) { > Also, I think you probably need a static_cast here: > > 201 _rotate_size = value; I applied them to new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.07/ Thanks, Yasumasa On 2016/05/04 21:38, Marcus Larsson wrote: > Hi, > > > On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: >> Hi David, Marcus, >> >> Thank you for your comment. >> I uploaded new webrev. Could you review it again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ > > Can you join these two cases: > > 193 if (!success) { > 194 break; > 195 } else if (value > SIZE_MAX) { > > > into something like > > if (!success || values > SIZE_MAX) { > > so that we properly fail to configure the output and print the error message when atojulong fails as well? > > > Also, I think you probably need a static_cast here: > > 201 _rotate_size = value; > > to avoid compiler warnings on 32-bit platforms. > > Thanks, > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/04 15:49, Marcus Larsson wrote: >>> Hi, >>> >>> On 05/04/2016 03:45 AM, David Holmes wrote: >>>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>>> Hi David, Marcus, >>>>> >>>>>> I would not have done that but instead used a temporary julong for the >>>>>> parse result, then range check, then assign to the actual _rotate_size >>>>>> etc with a cast. >>>>> >>>>> Thanks. >>>>> However, I guess we will encounter error when we access to > 2GB size file. >>>>> (Sorry, 4GB is incorrect.) >>>> >>>> That would seem to be a different issue. >>>> >>>>> I do not investigate for it yet. So I'm not sure whether it is correct. >>>>> In terms of this issue, should I keep range check and use julong temporary >>>>> value for _rotate_size? >>>> >>>> I would go this route yes. Use the Arguments code to do the parsing; apply the same range check as exists today (which may or may not be sufficient, but that is a different issue), then assign. >>> >>> I think that would be better too. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/04 5:40, David Holmes wrote: >>>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>>>>> then that's a problem, no? >>>>>>> >>>>>>> Thanks, Marcus! >>>>>> >>>>>> Yes good catch. I would have hoped the compiler would have complained >>>>>> about that on 32-bit. >>>>>> >>>>>>> I changed type of _rotate_size and _current_size to julong in new >>>>>>> webrev: >>>>>> >>>>>> I would not have done that but instead used a temporary julong for the >>>>>> parse result, then range check, then assign to the actual _rotate_size >>>>>> etc with a cast. That is less disruptive than changing the existing >>>>>> types IMHO. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>>> >>>>>>>>> the question for the UL owners is whether the change in semantics is >>>>>>>>> appropriate: previously the filesize was interpreted as a value in >>>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>>> >>>>>>> Is it no problem? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>>> >>>>>>>>> I've reviewed the change from a coding perspective - the question for >>>>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>>>> previously the filesize was interpreted as a value in KB, whereas >>>>>>>>> now, without a suffix, it is just bytes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>> >>>>>>>> This seems broken to me, we're passing &_rotate_size (a size_t*) to >>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > sizeof(size_t) >>>>>>>> then that's a problem, no? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>> interpreted >>>>>>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>> >>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>>> >>>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>>>>>> than >>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>> >>>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>> interpreted >>>>>>>>>>>> as a value in KB. With this change it will be in bytes - that means >>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>> >>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>> >>>>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>>>> that to >>>>>>>>>>>> the owners of this code to decide (and I hope they jump in soon!) >>>>>>>>>>>> >>>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>>> >>>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>> >>>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>> range >>>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ah I hadn't realized this was an external value, I thought it >>>>>>>>>>>>>> was some >>>>>>>>>>>>>> internally enforced maximum file size limit. So this is just an >>>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so we would >>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is greater >>>>>>>>>>>>>> than >>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>> still >>>>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>>>> file are >>>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>>>> modified, >>>>>>>>>>>>>> there is nothing, that I could see, that actually describes the >>>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>>> >: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, I had missed that example usage buried in there, >>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>> still >>>>>>>>>>>>>>> surprised none of these "options" for the handling the file >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile size with >>>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> code - the >>>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>>> >> configure_rotation. And of course you now need to work >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: to the >>>>>>>>>>>>>>> atomull >>>>>>>>>>>>>>> calls when >>>>>>>>>>>>>>> >> you are executing in Arguments code - lines 2643, 2660 >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> 788 // Parses a memory size specification string. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Not directly related to your change but I was surprised >>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>> >> various log file options don't seem to be documented >>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> arguments.hpp is included in precompiled.hpp . So >>>>>>>>>>>>>>> build was >>>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as below: >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>> > From marcus.larsson at oracle.com Wed May 4 13:49:44 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 15:49:44 +0200 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com> <56FCECDA.3070204@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> Message-ID: <44d10204-1838-b7e4-4994-3b25868c53c4@oracle.com> On 05/04/2016 03:43 PM, Yasumasa Suenaga wrote: > Thanks, Marcus! > >> into something like >> >> if (!success || values > SIZE_MAX) { > >> Also, I think you probably need a static_cast here: >> >> 201 _rotate_size = value; > > I applied them to new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.07/ Looks good! Thanks for fixing this. Marcus > > > Thanks, > > Yasumasa > > > On 2016/05/04 21:38, Marcus Larsson wrote: >> Hi, >> >> >> On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: >>> Hi David, Marcus, >>> >>> Thank you for your comment. >>> I uploaded new webrev. Could you review it again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ >> >> Can you join these two cases: >> >> 193 if (!success) { >> 194 break; >> 195 } else if (value > SIZE_MAX) { >> >> >> into something like >> >> if (!success || values > SIZE_MAX) { >> >> so that we properly fail to configure the output and print the error >> message when atojulong fails as well? >> >> >> Also, I think you probably need a static_cast here: >> >> 201 _rotate_size = value; >> >> to avoid compiler warnings on 32-bit platforms. >> >> Thanks, >> Marcus >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 15:49, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 05/04/2016 03:45 AM, David Holmes wrote: >>>>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, Marcus, >>>>>> >>>>>>> I would not have done that but instead used a temporary julong >>>>>>> for the >>>>>>> parse result, then range check, then assign to the actual >>>>>>> _rotate_size >>>>>>> etc with a cast. >>>>>> >>>>>> Thanks. >>>>>> However, I guess we will encounter error when we access to > 2GB >>>>>> size file. >>>>>> (Sorry, 4GB is incorrect.) >>>>> >>>>> That would seem to be a different issue. >>>>> >>>>>> I do not investigate for it yet. So I'm not sure whether it is >>>>>> correct. >>>>>> In terms of this issue, should I keep range check and use julong >>>>>> temporary >>>>>> value for _rotate_size? >>>>> >>>>> I would go this route yes. Use the Arguments code to do the >>>>> parsing; apply the same range check as exists today (which may or >>>>> may not be sufficient, but that is a different issue), then assign. >>>> >>>> I think that would be better too. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/04 5:40, David Holmes wrote: >>>>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>> size_t*) to >>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>> sizeof(size_t) >>>>>>>>> then that's a problem, no? >>>>>>>> >>>>>>>> Thanks, Marcus! >>>>>>> >>>>>>> Yes good catch. I would have hoped the compiler would have >>>>>>> complained >>>>>>> about that on 32-bit. >>>>>>> >>>>>>>> I changed type of _rotate_size and _current_size to julong in new >>>>>>>> webrev: >>>>>>> >>>>>>> I would not have done that but instead used a temporary julong >>>>>>> for the >>>>>>> parse result, then range check, then assign to the actual >>>>>>> _rotate_size >>>>>>> etc with a cast. That is less disruptive than changing the existing >>>>>>> types IMHO. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>>>> >>>>>>>>>> the question for the UL owners is whether the change in >>>>>>>>>> semantics is >>>>>>>>>> appropriate: previously the filesize was interpreted as a >>>>>>>>>> value in >>>>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>>>> >>>>>>>> Is it no problem? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>>>> >>>>>>>>>> I've reviewed the change from a coding perspective - the >>>>>>>>>> question for >>>>>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>>>>> previously the filesize was interpreted as a value in KB, >>>>>>>>>> whereas >>>>>>>>>> now, without a suffix, it is just bytes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>> >>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>> size_t*) to >>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>> sizeof(size_t) >>>>>>>>> then that's a problem, no? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>> interpreted >>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>> that means >>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>> >>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>>>> >>>>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>>>> >>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>> interpreted >>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>> that means >>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>> >>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>> >>>>>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>>>>> that to >>>>>>>>>>>>> the owners of this code to decide (and I hope they jump in >>>>>>>>>>>>> soon!) >>>>>>>>>>>>> >>>>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>>>> >>>>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>> >>>>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX >>>>>>>>>>>>>>>> / K) { >>>>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>> range >>>>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ah I hadn't realized this was an external value, I >>>>>>>>>>>>>>> thought it >>>>>>>>>>>>>>> was some >>>>>>>>>>>>>>> internally enforced maximum file size limit. So this is >>>>>>>>>>>>>>> just an >>>>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>>>>> file are >>>>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>>>>> modified, >>>>>>>>>>>>>>> there is nothing, that I could see, that actually >>>>>>>>>>>>>>> describes the >>>>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > >>>>>>>>>>>>>>>> SIZE_MAX / K) { >>>>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>> surprised none of these "options" for the handling >>>>>>>>>>>>>>>> the file >>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile >>>>>>>>>>>>>>>> size with >>>>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> code - the >>>>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>>>> >> configure_rotation. And of course you now need >>>>>>>>>>>>>>>> to work >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: >>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>> atomull >>>>>>>>>>>>>>>> calls when >>>>>>>>>>>>>>>> >> you are executing in Arguments code - lines >>>>>>>>>>>>>>>> 2643, 2660 >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> 788 // Parses a memory size specification >>>>>>>>>>>>>>>> string. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> arguments.hpp is included in >>>>>>>>>>>>>>>> precompiled.hpp . So >>>>>>>>>>>>>>>> build was >>>>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review >>>>>>>>>>>>>>>> again? >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>>>>>> below: >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> >>>> >> From yasuenag at gmail.com Wed May 4 14:12:15 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 23:12:15 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> Message-ID: <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> Hi Marcus, > 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); Thanks, I applied it to new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ Could you review again? Yasumasa On 2016/05/04 22:35, Marcus Larsson wrote: > Hi, > > > On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >> Hi Marcus, >> >> Thank you for your comment. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ > > Looks better. The format for _rotate_size should be SIZE_FORMAT. > > While we're at it I think it would be good (as I mentioned) to use a proper unit for the filesize. Basically changing > > 93 out->print("filecount=%u,filesize=%lu ", _file_count, _rotate_size); > > into > > 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); > > > Thanks, > Marcus > >> >> I fixed to use _rotate_size and _file_count directly to show VM.log list jcmd. >> I do not store option string, and I added new function to print option string. >> >> Could you review it again? >> >> >> Thanks. >> >> Yasumasa >> >> >> On 2016/05/04 18:33, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>> >>> I would prefer to generate the option string from the actual options rather than saving the string from when it was configured. This would also produce/print the options for outputs that are using the defaults (which is not the case now). The filesize option could then use byte_size_in_proper_unit and proper_unit_for_byte_size to make it easier to read. >>> >>> Also, get_option_string() should just be called option_string(). >>> >>> Thanks, >>> Marcus >>> >>>> >>>> This patch makes to show option string of LogFileOutput. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>> >>>>> Please review. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>> PING: >>>>>> >>>>>> I've sent review request for JDK-8153074. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>> >>>>>> If this patch is merged, user can confirm output option via VM.log jcmd. >>>>>> >>>>>> >>>>>> Please review and sponsor it. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>> CC'ed to serviceability-dev. >>>>>>>> >>>>>>>> Could you review it? >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This request review is related to [1]. >>>>>>>>> >>>>>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>>>>> >>>>>>>>> Output sample: >>>>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>>>>>>> >>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>> >>>>>>>>> >>> > From marcus.larsson at oracle.com Wed May 4 14:38:34 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 16:38:34 +0200 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> Message-ID: Hi, On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote: > Hi Marcus, > >> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", >> _file_count, byte_size_in_proper_unit(_rotate_size), >> proper_unit_for_byte_size(_rotate_size)); > > Thanks, I applied it to new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ Looks OK. Thanks, Marcus > > Could you review again? > > > Yasumasa > > > On 2016/05/04 22:35, Marcus Larsson wrote: >> Hi, >> >> >> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>> Thank you for your comment. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ >> >> Looks better. The format for _rotate_size should be SIZE_FORMAT. >> >> While we're at it I think it would be good (as I mentioned) to use a >> proper unit for the filesize. Basically changing >> >> 93 out->print("filecount=%u,filesize=%lu ", _file_count, _rotate_size); >> >> into >> >> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", >> _file_count, byte_size_in_proper_unit(_rotate_size), >> proper_unit_for_byte_size(_rotate_size)); >> >> >> Thanks, >> Marcus >> >>> >>> I fixed to use _rotate_size and _file_count directly to show VM.log >>> list jcmd. >>> I do not store option string, and I added new function to print >>> option string. >>> >>> Could you review it again? >>> >>> >>> Thanks. >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 18:33, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>> >>>> I would prefer to generate the option string from the actual >>>> options rather than saving the string from when it was configured. >>>> This would also produce/print the options for outputs that are >>>> using the defaults (which is not the case now). The filesize option >>>> could then use byte_size_in_proper_unit and >>>> proper_unit_for_byte_size to make it easier to read. >>>> >>>> Also, get_option_string() should just be called option_string(). >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> This patch makes to show option string of LogFileOutput. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>> >>>>>> Please review. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>>> PING: >>>>>>> >>>>>>> I've sent review request for JDK-8153074. >>>>>>> Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>> >>>>>>> If this patch is merged, user can confirm output option via >>>>>>> VM.log jcmd. >>>>>>> >>>>>>> >>>>>>> Please review and sponsor it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review and sponsor it? >>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>>> CC'ed to serviceability-dev. >>>>>>>>> >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> This request review is related to [1]. >>>>>>>>>> >>>>>>>>>> I want to see output option (filecount, filesize) in VM.log >>>>>>>>>> jcmd. >>>>>>>>>> >>>>>>>>>> Output sample: >>>>>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 >>>>>>>>>> time,level, >>>>>>>>>> >>>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>> >>>>>>>>>> >>>> >> From yasuenag at gmail.com Wed May 4 14:47:31 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 May 2016 23:47:31 +0900 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name Message-ID: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> Hi all, This review request relates to [1]. We cannot change heapdump name (heap.bin) when we genarate heapdump via jhsdb. When we use jmap, we can change heapdump name through file option. I want to set it like a jmap. I uploaded webrev for this enhancement. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html From dmitry.samersoff at oracle.com Wed May 4 19:30:17 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 4 May 2016 22:30:17 +0300 Subject: RFR(M): 8155091: Remove SA related functions from tmtools Message-ID: <572A4DC9.3050902@oracle.com> Everybody, Please review the changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ We are spitting tmtools (jstack, jmap, jinfo) into two separate sets of tools to reduce a cost of SA support. This is the last part of the split - removal of SA related code from jstack, jmap and jinfo. tmtools should support cooperative (attach api based) way to interact with java process only, coredump (non-cooperative access) is supported through a separate launcher - jhsdb. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Wed May 4 19:37:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 20:37:31 +0100 Subject: RFR(M): 8155091: Remove SA related functions from tmtools In-Reply-To: <572A4DC9.3050902@oracle.com> References: <572A4DC9.3050902@oracle.com> Message-ID: <572A4F7B.50403@oracle.com> Dmitry - did the ToolProvider spi go away too? On 04/05/2016 20:30, Dmitry Samersoff wrote: > Everybody, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ > > We are spitting tmtools (jstack, jmap, jinfo) into two separate sets > of tools to reduce a cost of SA support. > > This is the last part of the split - removal of SA related code from > jstack, jmap and jinfo. > > tmtools should support cooperative (attach api based) way to interact > with java process only, coredump (non-cooperative access) is supported > through a separate launcher - jhsdb. > > -Dmitry > From dmitry.samersoff at oracle.com Wed May 4 19:40:24 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 4 May 2016 22:40:24 +0300 Subject: RFR(M): 8155091: Remove SA related functions from tmtools In-Reply-To: <572A4F7B.50403@oracle.com> References: <572A4DC9.3050902@oracle.com> <572A4F7B.50403@oracle.com> Message-ID: <572A5028.8080404@oracle.com> Alan, On 2016-05-04 22:37, Alan Bateman wrote: > Dmitry - did the ToolProvider spi go away too? Probably yes, but I have to check it. -Dmitry > > On 04/05/2016 20:30, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ >> >> We are spitting tmtools (jstack, jmap, jinfo) into two separate sets >> of tools to reduce a cost of SA support. >> >> This is the last part of the split - removal of SA related code from >> jstack, jmap and jinfo. >> >> tmtools should support cooperative (attach api based) way to interact >> with java process only, coredump (non-cooperative access) is supported >> through a separate launcher - jhsdb. >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Wed May 4 19:47:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 May 2016 12:47:59 -0700 Subject: RFR(M): 8155091: Remove SA related functions from tmtools In-Reply-To: <572A5028.8080404@oracle.com> References: <572A4DC9.3050902@oracle.com> <572A4F7B.50403@oracle.com> <572A5028.8080404@oracle.com> Message-ID: > On May 4, 2016, at 12:40 PM, Dmitry Samersoff wrote: > > Alan, > > On 2016-05-04 22:37, Alan Bateman wrote: >> Dmitry - did the ToolProvider spi go away too? > > Probably yes, but I have to check it. I also expect module-info.java for both jdk.jcmd and jdk.hotspot.agent module be updated as well. Mandy > > -Dmitry > >> >> On 04/05/2016 20:30, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review the changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ >>> >>> We are spitting tmtools (jstack, jmap, jinfo) into two separate sets >>> of tools to reduce a cost of SA support. >>> >>> This is the last part of the split - removal of SA related code from >>> jstack, jmap and jinfo. >>> >>> tmtools should support cooperative (attach api based) way to interact >>> with java process only, coredump (non-cooperative access) is supported >>> through a separate launcher - jhsdb. >>> >>> -Dmitry >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed May 4 20:31:15 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 4 May 2016 13:31:15 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: References: Message-ID: <572A5C13.5030204@oracle.com> Hi Alexander, It looks good. Thank you for making the changes! Thanks, Serguei On 5/4/16 05:17, Alexander Kulyakhtin wrote: > Hi Sergey, > > Thank you very much for the review. > > Please, find the updated webrev with your findings corrected at: > http://cr.openjdk.java.net/~akulyakh/8153978_02/index.html > > Best regards, > Alexander > > ----- Original Message ----- > From: serguei.spitsyn at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Cc: aleksey.voytilov at oracle.com > Sent: Tuesday, May 3, 2016 1:06:05 AM GMT +03:00 Iraq > Subject: Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > Hi Alexander, > > > Could you, fix a couple of minor issues? > > test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java > 58 for(Module mod : my.modules()) { > 59 if(!jvmtiModules.contains(mod)) { > > A space is missed after the 'for' and 'if' keywords. > > test/serviceability/jvmti/GetModulesInfo/ModulesInfo.java. > 31 boolean compareExcludingUnnamed(ModulesInfo other) { > > I'd suggest to call it compareNamed. > > Otherwise, the new test looks great. > Thanks a lot for taking care about it! > > Thanks, > Serguei > > > > On 4/29/16 06:12, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review these test-only changes (adding a new test). > > CR:https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the modules info as returned by the JVMTI" > Webrev:http://cr.openjdk.java.net/~akulyakh/8153978_01/ > > The new test verifies that JVMTI returns the correct info about the modules loaded at the application startup. > It also verifies that the returned info is consistent with the same info returned by the Java API. > It then loads a new named module and checks the correctness of the JVMTI info again. > > Due to a tools issuehttps://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. > The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. > > Best regards, > Alexander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 5 01:52:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 May 2016 11:52:58 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <44d10204-1838-b7e4-4994-3b25868c53c4@oracle.com> References: <56FBDE02.2030900@gmail.com> <56FD2738.8050500@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> <44d10204-1838-b7e4-4994-3b25868c53c4@oracle.com> Message-ID: +1 from me. I will sponsor this - currently submitting to JPRT. Thanks, David On 4/05/2016 11:49 PM, Marcus Larsson wrote: > On 05/04/2016 03:43 PM, Yasumasa Suenaga wrote: >> Thanks, Marcus! >> >>> into something like >>> >>> if (!success || values > SIZE_MAX) { >> >>> Also, I think you probably need a static_cast here: >>> >>> 201 _rotate_size = value; >> >> I applied them to new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.07/ > > Looks good! Thanks for fixing this. > > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/04 21:38, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: >>>> Hi David, Marcus, >>>> >>>> Thank you for your comment. >>>> I uploaded new webrev. Could you review it again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ >>> >>> Can you join these two cases: >>> >>> 193 if (!success) { >>> 194 break; >>> 195 } else if (value > SIZE_MAX) { >>> >>> >>> into something like >>> >>> if (!success || values > SIZE_MAX) { >>> >>> so that we properly fail to configure the output and print the error >>> message when atojulong fails as well? >>> >>> >>> Also, I think you probably need a static_cast here: >>> >>> 201 _rotate_size = value; >>> >>> to avoid compiler warnings on 32-bit platforms. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 15:49, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 05/04/2016 03:45 AM, David Holmes wrote: >>>>>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, Marcus, >>>>>>> >>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>> for the >>>>>>>> parse result, then range check, then assign to the actual >>>>>>>> _rotate_size >>>>>>>> etc with a cast. >>>>>>> >>>>>>> Thanks. >>>>>>> However, I guess we will encounter error when we access to > 2GB >>>>>>> size file. >>>>>>> (Sorry, 4GB is incorrect.) >>>>>> >>>>>> That would seem to be a different issue. >>>>>> >>>>>>> I do not investigate for it yet. So I'm not sure whether it is >>>>>>> correct. >>>>>>> In terms of this issue, should I keep range check and use julong >>>>>>> temporary >>>>>>> value for _rotate_size? >>>>>> >>>>>> I would go this route yes. Use the Arguments code to do the >>>>>> parsing; apply the same range check as exists today (which may or >>>>>> may not be sufficient, but that is a different issue), then assign. >>>>> >>>>> I think that would be better too. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/05/04 5:40, David Holmes wrote: >>>>>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>> size_t*) to >>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>> sizeof(size_t) >>>>>>>>>> then that's a problem, no? >>>>>>>>> >>>>>>>>> Thanks, Marcus! >>>>>>>> >>>>>>>> Yes good catch. I would have hoped the compiler would have >>>>>>>> complained >>>>>>>> about that on 32-bit. >>>>>>>> >>>>>>>>> I changed type of _rotate_size and _current_size to julong in new >>>>>>>>> webrev: >>>>>>>> >>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>> for the >>>>>>>> parse result, then range check, then assign to the actual >>>>>>>> _rotate_size >>>>>>>> etc with a cast. That is less disruptive than changing the existing >>>>>>>> types IMHO. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>>>>> >>>>>>>>>>> the question for the UL owners is whether the change in >>>>>>>>>>> semantics is >>>>>>>>>>> appropriate: previously the filesize was interpreted as a >>>>>>>>>>> value in >>>>>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>>>>> >>>>>>>>> Is it no problem? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>>>>> >>>>>>>>>>> I've reviewed the change from a coding perspective - the >>>>>>>>>>> question for >>>>>>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>>>>>> previously the filesize was interpreted as a value in KB, >>>>>>>>>>> whereas >>>>>>>>>>> now, without a suffix, it is just bytes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>> >>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>> size_t*) to >>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>> sizeof(size_t) >>>>>>>>>> then that's a problem, no? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>> that means >>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>> >>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>>>>> >>>>>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>> that means >>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>> >>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>>>>>> that to >>>>>>>>>>>>>> the owners of this code to decide (and I hope they jump in >>>>>>>>>>>>>> soon!) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX >>>>>>>>>>>>>>>>> / K) { >>>>>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>> range >>>>>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ah I hadn't realized this was an external value, I >>>>>>>>>>>>>>>> thought it >>>>>>>>>>>>>>>> was some >>>>>>>>>>>>>>>> internally enforced maximum file size limit. So this is >>>>>>>>>>>>>>>> just an >>>>>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>>>>>> file are >>>>>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>>>>>> modified, >>>>>>>>>>>>>>>> there is nothing, that I could see, that actually >>>>>>>>>>>>>>>> describes the >>>>>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > >>>>>>>>>>>>>>>>> SIZE_MAX / K) { >>>>>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>> surprised none of these "options" for the handling >>>>>>>>>>>>>>>>> the file >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile >>>>>>>>>>>>>>>>> size with >>>>>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>> code - the >>>>>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>>>>> >> configure_rotation. And of course you now need >>>>>>>>>>>>>>>>> to work >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: >>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>> atomull >>>>>>>>>>>>>>>>> calls when >>>>>>>>>>>>>>>>> >> you are executing in Arguments code - lines >>>>>>>>>>>>>>>>> 2643, 2660 >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> 788 // Parses a memory size specification >>>>>>>>>>>>>>>>> string. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> arguments.hpp is included in >>>>>>>>>>>>>>>>> precompiled.hpp . So >>>>>>>>>>>>>>>>> build was >>>>>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review >>>>>>>>>>>>>>>>> again? >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>>>>>>> below: >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>> >>> > From yasuenag at gmail.com Thu May 5 02:18:26 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 5 May 2016 11:18:26 +0900 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: References: <56FBDE02.2030900@gmail.com> <570B6E57.2060707@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> <44d10204-1838-b7e4-4994-3b25868c53c4@oracle.com> Message-ID: <572AAD72.3020200@gmail.com> On 2016/05/05 10:52, David Holmes wrote: > +1 from me. Thanks David! > I will sponsor this - currently submitting to JPRT. Marcus will be a sponsor. Thanks, Yasumasa > Thanks, > David > > On 4/05/2016 11:49 PM, Marcus Larsson wrote: >> On 05/04/2016 03:43 PM, Yasumasa Suenaga wrote: >>> Thanks, Marcus! >>> >>>> into something like >>>> >>>> if (!success || values > SIZE_MAX) { >>> >>>> Also, I think you probably need a static_cast here: >>>> >>>> 201 _rotate_size = value; >>> >>> I applied them to new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.07/ >> >> Looks good! Thanks for fixing this. >> >> Marcus >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 21:38, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: >>>>> Hi David, Marcus, >>>>> >>>>> Thank you for your comment. >>>>> I uploaded new webrev. Could you review it again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ >>>> >>>> Can you join these two cases: >>>> >>>> 193 if (!success) { >>>> 194 break; >>>> 195 } else if (value > SIZE_MAX) { >>>> >>>> >>>> into something like >>>> >>>> if (!success || values > SIZE_MAX) { >>>> >>>> so that we properly fail to configure the output and print the error >>>> message when atojulong fails as well? >>>> >>>> >>>> Also, I think you probably need a static_cast here: >>>> >>>> 201 _rotate_size = value; >>>> >>>> to avoid compiler warnings on 32-bit platforms. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/04 15:49, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 05/04/2016 03:45 AM, David Holmes wrote: >>>>>>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, Marcus, >>>>>>>> >>>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>>> for the >>>>>>>>> parse result, then range check, then assign to the actual >>>>>>>>> _rotate_size >>>>>>>>> etc with a cast. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> However, I guess we will encounter error when we access to > 2GB >>>>>>>> size file. >>>>>>>> (Sorry, 4GB is incorrect.) >>>>>>> >>>>>>> That would seem to be a different issue. >>>>>>> >>>>>>>> I do not investigate for it yet. So I'm not sure whether it is >>>>>>>> correct. >>>>>>>> In terms of this issue, should I keep range check and use julong >>>>>>>> temporary >>>>>>>> value for _rotate_size? >>>>>>> >>>>>>> I would go this route yes. Use the Arguments code to do the >>>>>>> parsing; apply the same range check as exists today (which may or >>>>>>> may not be sufficient, but that is a different issue), then assign. >>>>>> >>>>>> I think that would be better too. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/04 5:40, David Holmes wrote: >>>>>>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>>> size_t*) to >>>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>>> sizeof(size_t) >>>>>>>>>>> then that's a problem, no? >>>>>>>>>> >>>>>>>>>> Thanks, Marcus! >>>>>>>>> >>>>>>>>> Yes good catch. I would have hoped the compiler would have >>>>>>>>> complained >>>>>>>>> about that on 32-bit. >>>>>>>>> >>>>>>>>>> I changed type of _rotate_size and _current_size to julong in new >>>>>>>>>> webrev: >>>>>>>>> >>>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>>> for the >>>>>>>>> parse result, then range check, then assign to the actual >>>>>>>>> _rotate_size >>>>>>>>> etc with a cast. That is less disruptive than changing the existing >>>>>>>>> types IMHO. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>>>>>> >>>>>>>>>>>> the question for the UL owners is whether the change in >>>>>>>>>>>> semantics is >>>>>>>>>>>> appropriate: previously the filesize was interpreted as a >>>>>>>>>>>> value in >>>>>>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>>>>>> >>>>>>>>>> Is it no problem? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>>>>>> >>>>>>>>>>>> I've reviewed the change from a coding perspective - the >>>>>>>>>>>> question for >>>>>>>>>>>> the UL owners is whether the change in semantics is appropriate: >>>>>>>>>>>> previously the filesize was interpreted as a value in KB, >>>>>>>>>>>> whereas >>>>>>>>>>>> now, without a suffix, it is just bytes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>>> size_t*) to >>>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>>> sizeof(size_t) >>>>>>>>>>> then that's a problem, no? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>>> that means >>>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>>> that means >>>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That change in semantics may not be desirable, but I'll leave >>>>>>>>>>>>>>> that to >>>>>>>>>>>>>>> the owners of this code to decide (and I hope they jump in >>>>>>>>>>>>>>> soon!) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX >>>>>>>>>>>>>>>>>> / K) { >>>>>>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>>> range >>>>>>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ah I hadn't realized this was an external value, I >>>>>>>>>>>>>>>>> thought it >>>>>>>>>>>>>>>>> was some >>>>>>>>>>>>>>>>> internally enforced maximum file size limit. So this is >>>>>>>>>>>>>>>>> just an >>>>>>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thus I do not think we do not need to check value range in >>>>>>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>> > surprised none of these "options" for the handling the >>>>>>>>>>>>>>>>>> file are >>>>>>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No I just meant that amongst all that help text you already >>>>>>>>>>>>>>>>> modified, >>>>>>>>>>>>>>>>> there is nothing, that I could see, that actually >>>>>>>>>>>>>>>>> describes the >>>>>>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > >>>>>>>>>>>>>>>>>> SIZE_MAX / K) { >>>>>>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>> surprised none of these "options" for the handling >>>>>>>>>>>>>>>>>> the file >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile >>>>>>>>>>>>>>>>>> size with >>>>>>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Your webrev seems out of date with respect to the >>>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>> code - the >>>>>>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>>>>>> >> configure_rotation. And of course you now need >>>>>>>>>>>>>>>>>> to work >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: >>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>> atomull >>>>>>>>>>>>>>>>>> calls when >>>>>>>>>>>>>>>>>> >> you are executing in Arguments code - lines >>>>>>>>>>>>>>>>>> 2643, 2660 >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> 788 // Parses a memory size specification >>>>>>>>>>>>>>>>>> string. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs renaming - >>>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> arguments.hpp is included in >>>>>>>>>>>>>>>>>> precompiled.hpp . So >>>>>>>>>>>>>>>>>> build was >>>>>>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review >>>>>>>>>>>>>>>>>> again? >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>>>>>>>> below: >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of arguments.hpp in >>>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Thu May 5 07:42:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 May 2016 17:42:42 +1000 Subject: PING: RFR: JDK-8153073: UL: Set filesize option with k/m/g In-Reply-To: <572AAD72.3020200@gmail.com> References: <56FBDE02.2030900@gmail.com> <5714E9E9.40804@gmail.com> <57158689.7020101@oracle.com> <5716378B.7030302@gmail.com> <5716E794.9060905@oracle.com> <57171BDA.9010703@oracle.com> <571748A3.8090508@gmail.com> <57186880.7040901@oracle.com> <57189F3C.8070300@gmail.com> <13534219-f48d-977c-1aa9-1d3b5b1b5b8c@gmail.com> <661fb877-2141-03c7-008a-2383c6bf6a2e@oracle.com> <19153d59-70ae-ea7a-84ff-3ddb52f1abbf@gmail.com> <9402c8c2-6c6f-7d0b-47f3-928c9597f506@oracle.com> <57294018.6060309@gmail.com> <6142c542-f68f-7854-eaad-47e348bef84a@oracle.com> <01a7de55-0a9c-7f0b-2df8-ac4e79173fbe@oracle.com> <65f395f0-99cf-bcd6-e75c-30ac1eaf2582@gmail.com> <44d10204-1838-b7e4-4994-3b25868c53c4@oracle.com> <572AAD72.3020200@gmail.com> Message-ID: <6dc77bb1-b274-b26d-58e8-58f6948f58ac@oracle.com> On 5/05/2016 12:18 PM, Yasumasa Suenaga wrote: > > On 2016/05/05 10:52, David Holmes wrote: >> +1 from me. > > Thanks David! > > >> I will sponsor this - currently submitting to JPRT. > > Marcus will be a sponsor. Sorry too late already done. David > > Thanks, > > Yasumasa > > >> Thanks, >> David >> >> On 4/05/2016 11:49 PM, Marcus Larsson wrote: >>> On 05/04/2016 03:43 PM, Yasumasa Suenaga wrote: >>>> Thanks, Marcus! >>>> >>>>> into something like >>>>> >>>>> if (!success || values > SIZE_MAX) { >>>> >>>>> Also, I think you probably need a static_cast here: >>>>> >>>>> 201 _rotate_size = value; >>>> >>>> I applied them to new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.07/ >>> >>> Looks good! Thanks for fixing this. >>> >>> Marcus >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 21:38, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 05/04/2016 02:29 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, Marcus, >>>>>> >>>>>> Thank you for your comment. >>>>>> I uploaded new webrev. Could you review it again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.06/ >>>>> >>>>> Can you join these two cases: >>>>> >>>>> 193 if (!success) { >>>>> 194 break; >>>>> 195 } else if (value > SIZE_MAX) { >>>>> >>>>> >>>>> into something like >>>>> >>>>> if (!success || values > SIZE_MAX) { >>>>> >>>>> so that we properly fail to configure the output and print the error >>>>> message when atojulong fails as well? >>>>> >>>>> >>>>> Also, I think you probably need a static_cast here: >>>>> >>>>> 201 _rotate_size = value; >>>>> >>>>> to avoid compiler warnings on 32-bit platforms. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/04 15:49, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 05/04/2016 03:45 AM, David Holmes wrote: >>>>>>>> On 4/05/2016 10:19 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, Marcus, >>>>>>>>> >>>>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>>>> for the >>>>>>>>>> parse result, then range check, then assign to the actual >>>>>>>>>> _rotate_size >>>>>>>>>> etc with a cast. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> However, I guess we will encounter error when we access to > 2GB >>>>>>>>> size file. >>>>>>>>> (Sorry, 4GB is incorrect.) >>>>>>>> >>>>>>>> That would seem to be a different issue. >>>>>>>> >>>>>>>>> I do not investigate for it yet. So I'm not sure whether it is >>>>>>>>> correct. >>>>>>>>> In terms of this issue, should I keep range check and use julong >>>>>>>>> temporary >>>>>>>>> value for _rotate_size? >>>>>>>> >>>>>>>> I would go this route yes. Use the Arguments code to do the >>>>>>>> parsing; apply the same range check as exists today (which may or >>>>>>>> may not be sufficient, but that is a different issue), then assign. >>>>>>> >>>>>>> I think that would be better too. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/05/04 5:40, David Holmes wrote: >>>>>>>>>> On 3/05/2016 11:49 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>>>> size_t*) to >>>>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>>>> sizeof(size_t) >>>>>>>>>>>> then that's a problem, no? >>>>>>>>>>> >>>>>>>>>>> Thanks, Marcus! >>>>>>>>>> >>>>>>>>>> Yes good catch. I would have hoped the compiler would have >>>>>>>>>> complained >>>>>>>>>> about that on 32-bit. >>>>>>>>>> >>>>>>>>>>> I changed type of _rotate_size and _current_size to julong in >>>>>>>>>>> new >>>>>>>>>>> webrev: >>>>>>>>>> >>>>>>>>>> I would not have done that but instead used a temporary julong >>>>>>>>>> for the >>>>>>>>>> parse result, then range check, then assign to the actual >>>>>>>>>> _rotate_size >>>>>>>>>> etc with a cast. That is less disruptive than changing the >>>>>>>>>> existing >>>>>>>>>> types IMHO. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.05/ >>>>>>>>>>> >>>>>>>>>>>>> the question for the UL owners is whether the change in >>>>>>>>>>>>> semantics is >>>>>>>>>>>>> appropriate: previously the filesize was interpreted as a >>>>>>>>>>>>> value in >>>>>>>>>>>>> KB, whereas now, without a suffix, it is just bytes. >>>>>>>>>>> >>>>>>>>>>> Is it no problem? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/05/03 21:41, Marcus Larsson wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 05/03/2016 02:25 PM, David Holmes wrote: >>>>>>>>>>>>> Adding in the runtime team as they now own UL. >>>>>>>>>>>>> >>>>>>>>>>>>> I've reviewed the change from a coding perspective - the >>>>>>>>>>>>> question for >>>>>>>>>>>>> the UL owners is whether the change in semantics is >>>>>>>>>>>>> appropriate: >>>>>>>>>>>>> previously the filesize was interpreted as a value in KB, >>>>>>>>>>>>> whereas >>>>>>>>>>>>> now, without a suffix, it is just bytes. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/05/2016 9:44 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> This seems broken to me, we're passing &_rotate_size (a >>>>>>>>>>>> size_t*) to >>>>>>>>>>>> atojulong() which takes a julong*. If sizeof(julong) > >>>>>>>>>>>> sizeof(size_t) >>>>>>>>>>>> then that's a problem, no? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/21 18:37, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>>>> that means >>>>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.04/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Following jtreg tests are passed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - hotspot/test/gc/logging >>>>>>>>>>>>>>> - hotspot/test/runtime/logging >>>>>>>>>>>>>>> - hotspot/test/serviceability/logging >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/21 14:43, David Holmes wrote: >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 20/04/2016 7:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Oh... I understood. >>>>>>>>>>>>>>>>> I've fixed and uploaded new webrev. Could you review >>>>>>>>>>>>>>>>> again? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.03/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So it just registered with me that currently filesize is >>>>>>>>>>>>>>>> interpreted >>>>>>>>>>>>>>>> as a value in KB. With this change it will be in bytes - >>>>>>>>>>>>>>>> that means >>>>>>>>>>>>>>>> tests will need fixing eg: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> hotspot/test/serviceability/logging/TestLogRotation.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That change in semantics may not be desirable, but I'll >>>>>>>>>>>>>>>> leave >>>>>>>>>>>>>>>> that to >>>>>>>>>>>>>>>> the owners of this code to decide (and I hope they jump in >>>>>>>>>>>>>>>> soon!) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I note that in the existing range check: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (value == SIZE_MAX || value > SIZE_MAX / K) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the first clause is redundant. So your change seems okay. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/04/20 15:04, David Holmes wrote: >>>>>>>>>>>>>>>>>> On 20/04/2016 3:25 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > You still removed the size bounds checks: >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>>>> > 191 if (value == SIZE_MAX || value > SIZE_MAX >>>>>>>>>>>>>>>>>>> / K) { >>>>>>>>>>>>>>>>>>> > 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>>>> range >>>>>>>>>>>>>>>>>>> [0, " >>>>>>>>>>>>>>>>>>> > 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>>>> > 194 success = false; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SIZE_MAX is defined as ULONG_MAX in stdint.h [1]. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Ah I hadn't realized this was an external value, I >>>>>>>>>>>>>>>>>> thought it >>>>>>>>>>>>>>>>>> was some >>>>>>>>>>>>>>>>>> internally enforced maximum file size limit. So this is >>>>>>>>>>>>>>>>>> just an >>>>>>>>>>>>>>>>>> overflow check really, and ... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Arguments::atojulong(atomull) checks value range [2]. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ... we already do an overflow check in here, but ... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thus I do not think we do not need to check value >>>>>>>>>>>>>>>>>>> range in >>>>>>>>>>>>>>>>>>> LogFileOutput::parse_options(). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ... on 32-bit size_t and julong are not the same size so >>>>>>>>>>>>>>>>>> we would >>>>>>>>>>>>>>>>>> still need to ensure we don't specify a filesize that is >>>>>>>>>>>>>>>>>> greater >>>>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>>> SIZE_MAX on 32-bit. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>>> > surprised none of these "options" for the handling >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> file are >>>>>>>>>>>>>>>>>>> > explicitly documented. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I do not know how we can documented about it. >>>>>>>>>>>>>>>>>>> (Is it internal process in Oracle?) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No I just meant that amongst all that help text you >>>>>>>>>>>>>>>>>> already >>>>>>>>>>>>>>>>>> modified, >>>>>>>>>>>>>>>>>> there is nothing, that I could see, that actually >>>>>>>>>>>>>>>>>> describes the >>>>>>>>>>>>>>>>>> possible options for filesize. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I can help for it if I can >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/stdint.h;h=442762728b899aa8ec219299692fce5953d796b0;hb=HEAD#l259 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8005261869c9/src/share/vm/runtime/arguments.cpp#l804 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2016/04/20 11:24 "David Holmes" >>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 19/04/2016 11:50 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.02/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> You still removed the size bounds checks: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 190 size_t value = parse_value(value_str); >>>>>>>>>>>>>>>>>>> 191 if (value == SIZE_MAX || value > >>>>>>>>>>>>>>>>>>> SIZE_MAX / K) { >>>>>>>>>>>>>>>>>>> 192 errstream->print_cr("Invalid option: %s must >>>>>>>>>>>>>>>>>>> be in >>>>>>>>>>>>>>>>>>> range [0, " >>>>>>>>>>>>>>>>>>> 193 SIZE_FORMAT "]", >>>>>>>>>>>>>>>>>>> FileSizeOptionKey, >>>>>>>>>>>>>>>>>>> SIZE_MAX / K); >>>>>>>>>>>>>>>>>>> 194 success = false; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs >>>>>>>>>>>>>>>>>>> renaming - >>>>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > I renamed to atojulong() in new webrev. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > I updated help message in new webrev. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, I had missed that example usage buried in >>>>>>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>>>>>> but am >>>>>>>>>>>>>>>>>>> still >>>>>>>>>>>>>>>>>>> surprised none of these "options" for the handling >>>>>>>>>>>>>>>>>>> the file >>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> explicitly documented. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > On 2016/04/19 10:14, David Holmes wrote: >>>>>>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> On 19/04/2016 12:06 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>> PING: >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> I've sent review request for JDK-8153073. >>>>>>>>>>>>>>>>>>> >>> Could you review it? >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> If this patch is merged, user can set logfile >>>>>>>>>>>>>>>>>>> size with >>>>>>>>>>>>>>>>>>> k/m/g. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Your webrev seems out of date with respect to >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>>>>> code - the >>>>>>>>>>>>>>>>>>> >> logfile size processing is done in >>>>>>>>>>>>>>>>>>> LogFileOutput::parse_options not >>>>>>>>>>>>>>>>>>> >> configure_rotation. And of course you now need >>>>>>>>>>>>>>>>>>> to work >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> jdk9/hs not >>>>>>>>>>>>>>>>>>> >> hs-rt. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> That aside: >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> src/share/vm/runtime/arguments.cpp >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> I don't think you need to add the Arguments:: >>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>> atomull >>>>>>>>>>>>>>>>>>> calls when >>>>>>>>>>>>>>>>>>> >> you are executing in Arguments code - lines >>>>>>>>>>>>>>>>>>> 2643, 2660 >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> This comment could be updated to delete "memory" >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> 788 // Parses a memory size specification >>>>>>>>>>>>>>>>>>> string. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Which makes me wonder if atomull needs >>>>>>>>>>>>>>>>>>> renaming - >>>>>>>>>>>>>>>>>>> does the >>>>>>>>>>>>>>>>>>> "m" mean >>>>>>>>>>>>>>>>>>> >> memory? atojulong would seem more appropriate >>>>>>>>>>>>>>>>>>> regardless. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> src/share/vm/logging/logFileOutput.cpp >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> You removed the size checking logic. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Not directly related to your change but I was >>>>>>>>>>>>>>>>>>> surprised >>>>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>>>> >> various log file options don't seem to be >>>>>>>>>>>>>>>>>>> documented >>>>>>>>>>>>>>>>>>> anywhere >>>>>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>> >> -Xlog:help output. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> Please review it. >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>> >>> On 2016/04/11 18:28, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>> PING: Could you review it? >>>>>>>>>>>>>>>>>>> >>>> We need more reviewer. >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> >>>>>>>>>>>>>>>>>>> >>>> On 2016/03/31 22:33, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>> CC'ed to serviceability-dev. >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> Could you review it? >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>> >>>>> On 2016/03/31 18:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>> Hi Marcus, >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of >>>>>>>>>>>>>>>>>>> arguments.hpp in >>>>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> arguments.hpp is included in >>>>>>>>>>>>>>>>>>> precompiled.hpp . So >>>>>>>>>>>>>>>>>>> build was >>>>>>>>>>>>>>>>>>> succeeded. >>>>>>>>>>>>>>>>>>> >>>>>> However, it should be included in >>>>>>>>>>>>>>>>>>> logFileOutput.cpp . >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> I uploaded a new webrev. Could you review >>>>>>>>>>>>>>>>>>> again? >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> >>>>>> On 2016/03/31 16:48, Marcus Larsson wrote: >>>>>>>>>>>>>>>>>>> >>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> On 03/30/2016 04:09 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> This request review is related to [1]. >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> I want to set filesize option with k/m/g as >>>>>>>>>>>>>>>>>>> below: >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> Memory size option (e.g. -Xmx) can be set with >>>>>>>>>>>>>>>>>>> k/m/g . >>>>>>>>>>>>>>>>>>> >>>>>>>> I think we can use option parser in >>>>>>>>>>>>>>>>>>> arguments.cpp . >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> You're missing an include of >>>>>>>>>>>>>>>>>>> arguments.hpp in >>>>>>>>>>>>>>>>>>> logFileOutput.cpp. >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> Apart from that, this looks good to me. >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>> Marcus >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> [1] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>> >>> From dmitry.samersoff at oracle.com Thu May 5 09:20:46 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 5 May 2016 12:20:46 +0300 Subject: RFR(M): 8155091: Remove SA related functions from tmtools In-Reply-To: References: <572A4DC9.3050902@oracle.com> <572A4F7B.50403@oracle.com> <572A5028.8080404@oracle.com> Message-ID: <572B106E.30904@oracle.com> Alan, Mandy, Yes, ToolProvider spi go away but I would prefer to do it (and modules-info.java update) as a separate step to simplify review process. -Dmitry On 2016-05-04 22:47, Mandy Chung wrote: > >> On May 4, 2016, at 12:40 PM, Dmitry Samersoff wrote: >> >> Alan, >> >> On 2016-05-04 22:37, Alan Bateman wrote: >>> Dmitry - did the ToolProvider spi go away too? >> >> Probably yes, but I have to check it. > > I also expect module-info.java for both jdk.jcmd and jdk.hotspot.agent module be updated as well. > > Mandy > >> >> -Dmitry >> >>> >>> On 04/05/2016 20:30, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ >>>> >>>> We are spitting tmtools (jstack, jmap, jinfo) into two separate sets >>>> of tools to reduce a cost of SA support. >>>> >>>> This is the last part of the split - removal of SA related code from >>>> jstack, jmap and jinfo. >>>> >>>> tmtools should support cooperative (attach api based) way to interact >>>> with java process only, coredump (non-cooperative access) is supported >>>> through a separate launcher - jhsdb. >>>> >>>> -Dmitry >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu May 5 09:32:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 10:32:28 +0100 Subject: RFR(M): 8155091: Remove SA related functions from tmtools In-Reply-To: <572B106E.30904@oracle.com> References: <572A4DC9.3050902@oracle.com> <572A4F7B.50403@oracle.com> <572A5028.8080404@oracle.com> <572B106E.30904@oracle.com> Message-ID: <572B132C.1000302@oracle.com> On 05/05/2016 10:20, Dmitry Samersoff wrote: > Alan, Mandy, > > Yes, ToolProvider spi go away but I would prefer to do it (and > modules-info.java update) as a separate step to simplify review process. > > -Dmitry > I think it would be much easier to review this if it was a complete fix. Splitting it up in several pieces makes it more complicated in my view. -Alan From alexander.kulyakhtin at oracle.com Thu May 5 11:25:27 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 5 May 2016 04:25:27 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: Sergey, Thank you very much for the review. I will be pushing the fix as soon as jtreg 4.2 is out, since 4.2 has the fix for CODETOOLS-7901662, required for this test. Best regards, Alexander From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com Cc: serviceability-dev at openjdk.java.net, aleksey.voytilov at oracle.com Sent: Wednesday, May 4, 2016 11:31:07 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, It looks good. Thank you for making the changes! Thanks, Serguei On 5/4/16 05:17, Alexander Kulyakhtin wrote: Hi Sergey, Thank you very much for the review. Please, find the updated webrev with your findings corrected at: http://cr.openjdk.java.net/~akulyakh/8153978_02/index.html Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Cc: aleksey.voytilov at oracle.com Sent: Tuesday, May 3, 2016 1:06:05 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, Could you, fix a couple of minor issues? test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java 58 for(Module mod : my.modules()) { 59 if(!jvmtiModules.contains(mod)) { A space is missed after the 'for' and 'if' keywords. test/serviceability/jvmti/GetModulesInfo/ModulesInfo.java. 31 boolean compareExcludingUnnamed(ModulesInfo other) { I'd suggest to call it compareNamed. Otherwise, the new test looks great. Thanks a lot for taking care about it! Thanks, Serguei On 4/29/16 06:12, Alexander Kulyakhtin wrote: Hi, Could you, please, review these test-only changes (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the modules info as returned by the JVMTI" Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/ The new test verifies that JVMTI returns the correct info about the modules loaded at the application startup. It also verifies that the returned info is consistent with the same info returned by the Java API. It then loads a new named module and checks the correctness of the JVMTI info again. Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the test can only be pushed in when the updated jtreg is released. The test passes fine with the nightly jtreg build, containing the CODETOOLS-7901662 fix. Best regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Thu May 5 12:32:27 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 5 May 2016 21:32:27 +0900 Subject: RFR: JDK-8156133: FindCrashesAction in HSDB does not work except Solaris platform Message-ID: <637e9c54-eeca-a985-c5fe-84d2a9a4b5e9@gmail.com> Hi all, HSDB can find crash thread from core image. However, it works on Solaris only. JavaThreadsPanel#fireShowThreadCrashes() detects as crashed thread from JavaThreads which has signal handler frame. Signal handler frame is different by platform. Thus it is hard to implement Frame#isSignalHandlerFrameDbg() for each platforms. As one of solution, I propose to add pointer of crashed JavaThread to VMStructs. Originally, this feature seems to work for crashing with dumping hs_err log. If so, this proposal does not change behavior. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8156133/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From dmitry.samersoff at oracle.com Thu May 5 12:51:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 5 May 2016 15:51:40 +0300 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <572A4DC9.3050902@oracle.com> References: <572A4DC9.3050902@oracle.com> Message-ID: <572B41DC.904@oracle.com> Please, see updated webrev. http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ Removed ToolProvider and update modules-info files. -Dmitry On 2016-05-04 22:30, Dmitry Samersoff wrote: > Everybody, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.03/ > > We are spitting tmtools (jstack, jmap, jinfo) into two separate sets > of tools to reduce a cost of SA support. > > This is the last part of the split - removal of SA related code from > jstack, jmap and jinfo. > > tmtools should support cooperative (attach api based) way to interact > with java process only, coredump (non-cooperative access) is supported > through a separate launcher - jhsdb. > > -Dmitry > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu May 5 13:30:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 14:30:10 +0100 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <572B41DC.904@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> Message-ID: <572B4AE2.80701@oracle.com> On 05/05/2016 13:51, Dmitry Samersoff wrote: > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ > > Removed ToolProvider and update modules-info files. > > -Dmitry > Can `requires jdk.jcmd` be dropped from jdk.hotspot.agent's module declaration? shouldWarnSA/warnSA is fatal (VM exits) so maybe better names are needed for these methods. "Coredump access". I guess this should "Cannot connect to core dump or remote debug server" to be clearer. The rest looks okay to me. -Alan From gerard.ziemski at oracle.com Thu May 5 16:18:01 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 5 May 2016 11:18:01 -0500 Subject: Fwd: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> Message-ID: <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> I?m including serviceability mailing list. bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ cheers > Begin forwarded message: > > From: Yasumasa Suenaga > Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd > Date: May 4, 2016 at 9:34:15 AM CDT > To: "hotspot-runtime-dev at openjdk.java.net" > Cc: Gerard Ziemski > > Hi all, > > We still need a second Reviewer. > Could you review? > > > Thanks, > > Yasumasa > > > On 2016/05/04 9:32, Yasumasa Suenaga wrote: >> Hi Gerard, >> >>> Reviewed and I will sponsor it. >> >> Thanks! >> >>> Just one question: there is no existing JDK issue covering this yet, is there? Can you file one please if none exists yet? >> >> I do not change in jdk repos. >> My change affects jinfo, however jtreg test for jinfo passed. >> >> I ran jtreg with two directories: >> >> - hotspot/test/serviceability/dcmd/vm >> - jdk/test/sun/tools/jinfo >> >> They work fine. >> (JInfoRunningProcessFlagTest is failed. But it is listed in ProblemList.) >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/04 3:18, Gerard Ziemski wrote: >>> hi Yasumasa, >>> >>> Thank you for the fix, I like it - the very first time I tried using jcmd to set a boolean value I tried using ?true?, so this will make jcmd easier to use. >>> >>> Reviewed and I will sponsor it. >>> >>> Just one question: there is no existing JDK issue covering this yet, is there? Can you file one please if none exists yet? >>> >>> >>> >>> cheers >>> >>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> We can change a part of -XX option via VM.set_flag jcmd. >>>> This jcmd requires 1 or 0 as boolean value. >>>> However, we can set 0 or not (NOT 1). >>>> >>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>> So I think it is useful if VM.set_flag accept boolean value in true/false. >>>> >>>> I uploaded a webrev for this issue. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>> >>>> I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>> From dmitry.samersoff at oracle.com Thu May 5 17:56:21 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 5 May 2016 20:56:21 +0300 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <572B4AE2.80701@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <572B4AE2.80701@oracle.com> Message-ID: <572B8945.6070205@oracle.com> Alan, Webrev updated in-place (press shift-reload). -Dmitry On 2016-05-05 16:30, Alan Bateman wrote: > > On 05/05/2016 13:51, Dmitry Samersoff wrote: >> Please, see updated webrev. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ >> >> Removed ToolProvider and update modules-info files. >> >> -Dmitry >> > Can `requires jdk.jcmd` be dropped from jdk.hotspot.agent's module > declaration? > > shouldWarnSA/warnSA is fatal (VM exits) so maybe better names are needed > for these methods. > > "Coredump access". I guess this should "Cannot connect to core dump or > remote debug server" to be clearer. > > The rest looks okay to me. > > -Alan > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu May 5 17:59:01 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 5 May 2016 20:59:01 +0300 Subject: RFR: JDK-8156133: FindCrashesAction in HSDB does not work except Solaris platform In-Reply-To: <637e9c54-eeca-a985-c5fe-84d2a9a4b5e9@gmail.com> References: <637e9c54-eeca-a985-c5fe-84d2a9a4b5e9@gmail.com> Message-ID: <572B89E5.90502@oracle.com> Yasumasa, The fix looks good for me. I'll sponsor the push. -Dmitry On 2016-05-05 15:32, Yasumasa Suenaga wrote: > Hi all, > > HSDB can find crash thread from core image. > However, it works on Solaris only. > > JavaThreadsPanel#fireShowThreadCrashes() detects as crashed thread > from JavaThreads which has signal handler frame. > Signal handler frame is different by platform. Thus it is hard to > implement Frame#isSignalHandlerFrameDbg() for each platforms. > > As one of solution, I propose to add pointer of crashed JavaThread > to VMStructs. > Originally, this feature seems to work for crashing with dumping > hs_err log. If so, this proposal does not change behavior. > > I uploaded a webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8156133/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Thu May 5 19:37:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 12:37:58 -0700 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <572B41DC.904@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> Message-ID: > On May 5, 2016, at 5:51 AM, Dmitry Samersoff wrote: > > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ToolProvider.java This is not used. Looks like it?s a copy of From mandy.chung at oracle.com Thu May 5 19:48:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 12:48:41 -0700 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <572B41DC.904@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> Message-ID: <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> > On May 5, 2016, at 5:51 AM, Dmitry Samersoff wrote: > > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ToolProvider.java I suggest to remove this as jdk.hotspot.agent is no longer a provider. You could keep the getName and run methods and just remove @Override annotation. I only skimmed on the jdk change. test/sun/tools/jinfo/BasicJInfoTest.java It has @bug 6260070 (an old bug). Is it renamed from an existing test? OR just cut-n-paste error. 35 * @modules java.management Is this still needed? test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java and other jhsdb tests should have @modules jdk.hotspot.agent Mandy From dmitry.samersoff at oracle.com Thu May 5 19:51:58 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 5 May 2016 22:51:58 +0300 Subject: RFR(M): v.04, 8155091: Remove SA related functions from tmtools In-Reply-To: <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> Message-ID: <572BA45E.1090905@oracle.com> Mandy, OK. Will change it. Thank you for review! -Dmitry On 2016-05-05 22:48, Mandy Chung wrote: > >> On May 5, 2016, at 5:51 AM, Dmitry Samersoff wrote: >> >> Please, see updated webrev. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ToolProvider.java > I suggest to remove this as jdk.hotspot.agent is no longer a provider. You could keep the getName and run methods and just remove @Override annotation. > > I only skimmed on the jdk change. > > test/sun/tools/jinfo/BasicJInfoTest.java > It has @bug 6260070 (an old bug). Is it renamed from an existing test? OR just cut-n-paste error. > > 35 * @modules java.management > > Is this still needed? > > test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java and other jhsdb tests > should have @modules jdk.hotspot.agent > > Mandy > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Fri May 6 05:20:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 15:20:39 +1000 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> Message-ID: Hi Robbin, Please see comments far below regarding mapping ... On 4/05/2016 5:25 AM, Robbin Ehn wrote: > Hi all, > > Please review this. > > This changeset moves redefine classes tracing to UL. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 > Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ src/share/vm/prims/jvmtiRedefineClasses.cpp I wonder whether the RC timers can be better integrated as was done with other use of timers with logging? A scope-based Timer class would fix the problem of conditionally starting timers, but unconditionally stopping them. > Passes testsuits > jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist > with: > -Xlog:redefine+class*=trace > (a few test won't run with extra options) > > -XX:TraceRedefineClasses=xyz turns on (aliased with) > "-Xlog:redefine+class*=info" and emits a warning. > (xyz is ignored) > > Thanks! > > /Robbin > > Example of useage: > -Xlog:redefine+class+constantpool*=debug > -Xlog:redefine+class+load=info > -Xlog:redefine+class*=debug,redefine+class+iklass*=trace > > Here is an example from a test: > > [20.279s][debug][redefine,class,update,vtables ] vtable method > update: getOptions(()Ljava/util/Properties;), updated default = false > [20.279s][debug][redefine,class,subclass ] updated count in > subclass=nsk.share.jvmti.ArgumentHandler to 197 > [20.279s][info ][redefine,class,load ] redefined > name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) > [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, > obsolete_cnt=0 > [20.285s][trace][redefine,class,iklass,add ] adding previous > version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 > [20.285s][trace][redefine,class,iklass,add ] scratch class not > added; no methods are running > [20.285s][info ][redefine,class,update ] adjust: > name=nsk.share.jvmti.ArgumentHandler > [20.285s][debug][redefine,class,update,constantpool] cpc entry update: > getAgentOptionsString(()Ljava/lang/String;) > [20.285s][info ][redefine,class,update ] adjust: > name=nsk.share.jvmti.ArgumentHandler > [20.285s][debug][redefine,class,update,constantpool] cpc entry update: > (([Ljava/lang/String;)V) > [20.285s][info ][redefine,class,load ] redefined > name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) > [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, > obsolete_cnt=0 > [20.291s][trace][redefine,class,iklass,add ] adding previous > version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 > [20.291s][trace][redefine,class,iklass,add ] scratch class not > added; no methods are running > [20.291s][info ][redefine,class,update ] adjust: > name=nsk.share.jvmti.JVMTITest > [20.291s][debug][redefine,class,update,constantpool] cpc entry update: > commonInit(([Ljava/lang/String;)[Ljava/lang/String;) > [20.291s][info ][redefine,class,load ] redefined > name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) > [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, > obsolete_cnt=0 > [20.297s][trace][redefine,class,iklass,add ] adding previous > version ref for nsk.share.TestBug, EMCP_cnt=3 > > Mapping: Very unclear how you selected info/debug/trace for each of these. Given they use different tag sets they could really all be "info" for their set. > RC_TRACE_MESG = "redefine, class, update" - info > > 0x00000001 = "redefine, class, load" - info > 0x00000001 = "redefine, class, load" - debug > > 0x00000002 = "redefine, class, load, exceptions" - info > 0x00000004 = "redefine, class, timer" - info > 0x00000008 = "redefine, class, subclass" - debug > > 0x00000100 = "redefine, class, obsolete, mark" - trace > 0x00000200 = "redefine, class, iklass, purge" - trace > 0x00000400 = "redefine, class, iklass, add" - trace > 0x00000800 = "redefine, class, breakpoint" - debug > > 0x00001000->0x00002000 = "redefine, class, obsolete" - trace > 0x00001000 = "redefine, class, obsolete" - trace > 0x00002000 = REMOVED I'm a little unclear about how the old ranges were supposed to work, but you have effectively removed them as far as I can see. A range of 1000->2000 would print out when "redefine, class, obsolete" was specified in conjunction with any, or all, or the preceding conditions - but now it will print only on that one condition. You also removed the debugging hooks related to this ie in sharedRuntime.cpp: - if (RC_TRACE_ENABLED(0x00002000)) { - // this option is provided to debug calls to obsolete methods - guarantee(false, "faulting at call to an obsolete method."); - } Thanks, David > 0x00004000 = "redefine, class, obsolete, metadata" - trace > 0x00004000 = "redefine, class, dump" - trace > > 0x00008000 = "redefine, class, normalize" - trace > > 0x00010000 = "redefine, class, constantpool" - info > 0x00020000 = "redefine, class, constantpool" - debug > 0x00040000 = "redefine, class, constantpool" - trace > 0x00080000 = "redefine, class, constantpool" - trace > > 0x00100000-0x00400000 = "redefine, class, update" - info > 0x00100000 = "redefine, class, update, vtables" - debug > 0x00200000 = "redefine, class, update, itables" - debug > 0x00400000 = "redefine, class, update, constantpool" - debug > > 0x00800000 = "redefine, class, methodcomparator" - debug > > 0x01000000 = "redefine, class, nmethod" - debug > 0x02000000 = "redefine, class, annotation" - debug > 0x04000000 = "redefine, class, stackmap" - debug > 0x08000000 = "redefine, class, oopmap" - debug > From robbin.ehn at oracle.com Fri May 6 07:12:44 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 6 May 2016 09:12:44 +0200 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> Message-ID: Hi David, thanks for taking the time looking at this! On 05/06/2016 07:20 AM, David Holmes wrote: > Hi Robbin, > > Please see comments far below regarding mapping ... > > On 4/05/2016 5:25 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review this. >> >> This changeset moves redefine classes tracing to UL. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 >> Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ > > src/share/vm/prims/jvmtiRedefineClasses.cpp > > I wonder whether the RC timers can be better integrated as was done with > other use of timers with logging? A scope-based Timer class would fix > the problem of conditionally starting timers, but unconditionally > stopping them. Since I saw no harm in calling elapsedTimer.stop() so I did it this way. Let me know you you want me to do scoped instead. (one of the scopes are really bid) > >> Passes testsuits >> jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist >> >> with: >> -Xlog:redefine+class*=trace >> (a few test won't run with extra options) >> >> -XX:TraceRedefineClasses=xyz turns on (aliased with) >> "-Xlog:redefine+class*=info" and emits a warning. >> (xyz is ignored) >> >> Thanks! >> >> /Robbin >> >> Example of useage: >> -Xlog:redefine+class+constantpool*=debug >> -Xlog:redefine+class+load=info >> -Xlog:redefine+class*=debug,redefine+class+iklass*=trace >> >> Here is an example from a test: >> >> [20.279s][debug][redefine,class,update,vtables ] vtable method >> update: getOptions(()Ljava/util/Properties;), updated default = false >> [20.279s][debug][redefine,class,subclass ] updated count in >> subclass=nsk.share.jvmti.ArgumentHandler to 197 >> [20.279s][info ][redefine,class,load ] redefined >> name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) >> [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, >> obsolete_cnt=0 >> [20.285s][trace][redefine,class,iklass,add ] adding previous >> version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 >> [20.285s][trace][redefine,class,iklass,add ] scratch class not >> added; no methods are running >> [20.285s][info ][redefine,class,update ] adjust: >> name=nsk.share.jvmti.ArgumentHandler >> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >> getAgentOptionsString(()Ljava/lang/String;) >> [20.285s][info ][redefine,class,update ] adjust: >> name=nsk.share.jvmti.ArgumentHandler >> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >> (([Ljava/lang/String;)V) >> [20.285s][info ][redefine,class,load ] redefined >> name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) >> [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >> obsolete_cnt=0 >> [20.291s][trace][redefine,class,iklass,add ] adding previous >> version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 >> [20.291s][trace][redefine,class,iklass,add ] scratch class not >> added; no methods are running >> [20.291s][info ][redefine,class,update ] adjust: >> name=nsk.share.jvmti.JVMTITest >> [20.291s][debug][redefine,class,update,constantpool] cpc entry update: >> commonInit(([Ljava/lang/String;)[Ljava/lang/String;) >> [20.291s][info ][redefine,class,load ] redefined >> name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) >> [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >> obsolete_cnt=0 >> [20.297s][trace][redefine,class,iklass,add ] adding previous >> version ref for nsk.share.TestBug, EMCP_cnt=3 >> >> Mapping: > > Very unclear how you selected info/debug/trace for each of these. Given I have select them after verbosity (looking at distribution after tests runs) and granularity. But sure it is a bit arbitrary. > they use different tag sets they could really all be "info" for their set. They use different level due for the use-case: Enable info for all tagset containing the two tags redefine+class -Xlog:redefine+class*=info Also enable debug for constantpool -Xlog:redefine+class*=info,redefine+class+constantpool=debug Also enable trace for all updates -Xlog:redefine+class*=info,redefine+class+constantpool=debug,redefine+class+update*=trace > >> RC_TRACE_MESG = "redefine, class, update" - info >> >> 0x00000001 = "redefine, class, load" - info >> 0x00000001 = "redefine, class, load" - debug >> >> 0x00000002 = "redefine, class, load, exceptions" - info >> 0x00000004 = "redefine, class, timer" - info >> 0x00000008 = "redefine, class, subclass" - debug >> >> 0x00000100 = "redefine, class, obsolete, mark" - trace >> 0x00000200 = "redefine, class, iklass, purge" - trace >> 0x00000400 = "redefine, class, iklass, add" - trace >> 0x00000800 = "redefine, class, breakpoint" - debug >> >> 0x00001000->0x00002000 = "redefine, class, obsolete" - trace >> 0x00001000 = "redefine, class, obsolete" - trace >> 0x00002000 = REMOVED > > I'm a little unclear about how the old ranges were supposed to work, but > you have effectively removed them as far as I can see. A range of > 1000->2000 would print out when "redefine, class, obsolete" was > specified in conjunction with any, or all, or the preceding conditions - > but now it will print only on that one condition. > > You also removed the debugging hooks related to this ie in > sharedRuntime.cpp: > > - if (RC_TRACE_ENABLED(0x00002000)) { > - // this option is provided to debug calls to obsolete methods > - guarantee(false, "faulting at call to an obsolete method."); > - } > Yes 0x00002000 was removed, because we can't have "class*=trace" enabling a guarantee. In the old code if either of those two bits were set it evaluated true. (regardless off other bits) Since I removed one bit, this is a boolean and was translated to: is "redefine, class, obsolete" enabled or not. Thanks! /Robbin > > Thanks, > David > >> 0x00004000 = "redefine, class, obsolete, metadata" - trace >> 0x00004000 = "redefine, class, dump" - trace >> >> 0x00008000 = "redefine, class, normalize" - trace >> >> 0x00010000 = "redefine, class, constantpool" - info >> 0x00020000 = "redefine, class, constantpool" - debug >> 0x00040000 = "redefine, class, constantpool" - trace >> 0x00080000 = "redefine, class, constantpool" - trace >> >> 0x00100000-0x00400000 = "redefine, class, update" - info >> 0x00100000 = "redefine, class, update, vtables" - debug >> 0x00200000 = "redefine, class, update, itables" - debug >> 0x00400000 = "redefine, class, update, constantpool" - debug >> >> 0x00800000 = "redefine, class, methodcomparator" - debug >> >> 0x01000000 = "redefine, class, nmethod" - debug >> 0x02000000 = "redefine, class, annotation" - debug >> 0x04000000 = "redefine, class, stackmap" - debug >> 0x08000000 = "redefine, class, oopmap" - debug >> From serguei.spitsyn at oracle.com Fri May 6 07:18:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 6 May 2016 00:18:35 -0700 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a Message-ID: <572C454B.3080302@oracle.com> Please, review a simple fix in the java.lang.instrument.InstrumentationImpl transform() method. This is the patch: diff -r d2f46fdfc3ca src/java.base/share/classes/module-info.java --- a/src/java.base/share/classes/module-info.java Thu May 05 11:44:01 2016 -0700 +++ b/src/java.base/share/classes/module-info.java Fri May 06 00:11:23 2016 -0700 @@ -145,6 +145,8 @@ jdk.scripting.nashorn; exports jdk.internal.org.objectweb.asm.signature to jdk.scripting.nashorn; + exports jdk.internal.loader to + java.instrument; exports jdk.internal.math to java.desktop; exports jdk.internal.module to diff -r d2f46fdfc3ca src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java --- a/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java Thu May 05 11:44:01 2016 -0700 +++ b/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java Fri May 06 00:11:23 2016 -0700 @@ -41,6 +41,8 @@ import java.util.Objects; import java.util.jar.JarFile; +import jdk.internal.loader.BootLoader; + /* * Copyright 2003 Wily Technology, Inc. */ @@ -436,7 +438,8 @@ if (classBeingRedefined != null) { module = classBeingRedefined.getModule(); } else { - module = loader.getUnnamedModule(); + module = (loader == null) ? jdk.internal.loader.BootLoader.getUnnamedModule() + : loader.getUnnamedModule(); } } if (mgr == null) { Summary: InstrumentationImpl.transform has this: if (module == null) { if (classBeingRedefined != null) { module = classBeingRedefined.getModule(); } else { module = loader.getUnnamedModule(); } } but if loader is null (-Xbootclasspath/a case) then this throws NullPointerException. If loader is null then we need to use jdk.internal.loader.BootLoader.getUnnamedModule(). Testing: In progress: run the JTreg :jdk_instrument tests. Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri May 6 07:23:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 08:23:44 +0100 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a In-Reply-To: <572C454B.3080302@oracle.com> References: <572C454B.3080302@oracle.com> Message-ID: <572C4680.6020403@oracle.com> This looks okay to me except I don't see a test. I think we will need test coverage for instrumenting classes in the unnamed module of the boot loader. Also can you push this to jdk9/dev? We have a number of people on jigsaw-dev reporting this issue and would be good to get it fixed in jdk-9+118. -Alan On 06/05/2016 08:18, serguei.spitsyn at oracle.com wrote: > Please, review a simple fix in the > java.lang.instrument.InstrumentationImpl transform() method. > > This is the patch: > > diff -r d2f46fdfc3ca src/java.base/share/classes/module-info.java > --- a/src/java.base/share/classes/module-info.java Thu May 05 > 11:44:01 2016 -0700 > +++ b/src/java.base/share/classes/module-info.java Fri May 06 > 00:11:23 2016 -0700 > @@ -145,6 +145,8 @@ > jdk.scripting.nashorn; > exports jdk.internal.org.objectweb.asm.signature to > jdk.scripting.nashorn; > + exports jdk.internal.loader to > + java.instrument; > exports jdk.internal.math to > java.desktop; > exports jdk.internal.module to > > > diff -r d2f46fdfc3ca > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java > --- > a/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java > Thu May 05 11:44:01 2016 -0700 > +++ > b/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java > Fri May 06 00:11:23 2016 -0700 > @@ -41,6 +41,8 @@ > import java.util.Objects; > import java.util.jar.JarFile; > > +import jdk.internal.loader.BootLoader; > + > /* > * Copyright 2003 Wily Technology, Inc. > */ > @@ -436,7 +438,8 @@ > if (classBeingRedefined != null) { > module = classBeingRedefined.getModule(); > } else { > - module = loader.getUnnamedModule(); > + module = (loader == null) ? > jdk.internal.loader.BootLoader.getUnnamedModule() > + : loader.getUnnamedModule(); > } > } > if (mgr == null) { > > > Summary: > > InstrumentationImpl.transform has this: > if (module == null) { > if (classBeingRedefined != null) { > module = classBeingRedefined.getModule(); > } else { > module = loader.getUnnamedModule(); > } > } > > but if loader is null (-Xbootclasspath/a case) then this throws > NullPointerException. > If loader is null then we need to use > jdk.internal.loader.BootLoader.getUnnamedModule(). > > > Testing: > In progress: run the JTreg :jdk_instrument tests. > > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 6 07:29:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 6 May 2016 00:29:10 -0700 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a In-Reply-To: <572C4680.6020403@oracle.com> References: <572C454B.3080302@oracle.com> <572C4680.6020403@oracle.com> Message-ID: <572C47C6.4080602@oracle.com> On 5/6/16 00:23, Alan Bateman wrote: > > This looks okay to me except I don't see a test. I think we will need > test coverage for instrumenting classes in the unnamed module of the > boot loader. Ok, I'll check if some of the jdk_instrument tests can be modified to add this coverage. > > Also can you push this to jdk9/dev? We have a number of people on > jigsaw-dev reporting this issue and would be good to get it fixed in > jdk-9+118. Sure, I'll rebase the fix to the jdk9/dev. Thanks, Serguei > > -Alan > > > > On 06/05/2016 08:18, serguei.spitsyn at oracle.com wrote: >> Please, review a simple fix in the >> java.lang.instrument.InstrumentationImpl transform() method. >> >> This is the patch: >> >> diff -r d2f46fdfc3ca src/java.base/share/classes/module-info.java >> --- a/src/java.base/share/classes/module-info.java Thu May 05 >> 11:44:01 2016 -0700 >> +++ b/src/java.base/share/classes/module-info.java Fri May 06 >> 00:11:23 2016 -0700 >> @@ -145,6 +145,8 @@ >> jdk.scripting.nashorn; >> exports jdk.internal.org.objectweb.asm.signature to >> jdk.scripting.nashorn; >> + exports jdk.internal.loader to >> + java.instrument; >> exports jdk.internal.math to >> java.desktop; >> exports jdk.internal.module to >> >> >> diff -r d2f46fdfc3ca >> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >> --- >> a/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >> Thu May 05 11:44:01 2016 -0700 >> +++ >> b/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >> Fri May 06 00:11:23 2016 -0700 >> @@ -41,6 +41,8 @@ >> import java.util.Objects; >> import java.util.jar.JarFile; >> >> +import jdk.internal.loader.BootLoader; >> + >> /* >> * Copyright 2003 Wily Technology, Inc. >> */ >> @@ -436,7 +438,8 @@ >> if (classBeingRedefined != null) { >> module = classBeingRedefined.getModule(); >> } else { >> - module = loader.getUnnamedModule(); >> + module = (loader == null) ? >> jdk.internal.loader.BootLoader.getUnnamedModule() >> + : loader.getUnnamedModule(); >> } >> } >> if (mgr == null) { >> >> >> Summary: >> >> InstrumentationImpl.transform has this: >> if (module == null) { >> if (classBeingRedefined != null) { >> module = classBeingRedefined.getModule(); >> } else { >> module = loader.getUnnamedModule(); >> } >> } >> >> but if loader is null (-Xbootclasspath/a case) then this throws >> NullPointerException. >> If loader is null then we need to use >> jdk.internal.loader.BootLoader.getUnnamedModule(). >> >> >> Testing: >> In progress: run the JTreg :jdk_instrument tests. >> >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Fri May 6 10:23:14 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 6 May 2016 11:23:14 +0100 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <736d4731-1763-434a-99d2-376fbe01443d@default> References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> Message-ID: <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> Thanks Cheleswer, looks good to me too, have been over the macros as much as I can! Thanks Kevin On 03/05/2016 07:34, Cheleswer Sahu wrote: > Hi Gerard, > > >> -----Original Message----- >> From: Gerard Ziemski >> Sent: Monday, May 02, 2016 9:07 PM >> To: Cheleswer Sahu >> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- >> dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> hi Cheleswer, >> >> >> #1 Shouldn?t the following files be modified as well? : >> >> open: >> >> src/cpu/sparc/vm/globals_sparc.hpp >> src/cpu/x86/vm/globals_x86.hpp >> src/cpu/zero/vm/globals_zero.hpp >> >> closed: >> >> cpu/arm/vm/globals_arm.hpp > I have implemented "diagnostic_pd" using "product_pd" as a reference implementation. "product_pd" is not implemented for " ARCH_FLAGS ", therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" type. > >> share/vm/runtime/globals_ext.hpp >> share/vm/runtime/os_ext.hpp > These 2 files are under closed repository, so I have initiated a separate internal review request for those changes. > >> >> #2 Bunch of header files need to be updated with 2016 for Copyright: >> >> /* >> - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. >> * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. >> */ >> >> > I agree, I will update the copyright headers. > >> #3 What tests have you run? Did you do: >> >> a) JPRT hotspot >> b) RBT hs-nightly-runtime >> > I have run JPRT hostspot tests for this. It shows no error. > >> Please email me if you need help with those. >> >> >> #4 Just heads up that I will be shortly asking for review of my fix >> (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches many >> of the same file, so one of us will have a tricky merge >> > Thanks for informing about this. > > > Regards, > Cheleswer > >> cheers >> >>> On May 2, 2016, at 4:51 AM, Cheleswer Sahu >> wrote: >>> Hi, >>> >>> >>> >>> Please review the code changes for >> https://bugs.openjdk.java.net/browse/JDK-8150900. >>> >>> >>> Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ >>> >>> >>> >>> Enhancement Brief: A new variant of flag "diagnostic_pd" is implemented. >> All flags which are diagnostic in nature and platform dependent can be placed >>> under this variant. These flags can be enable using "- >> XX:+UnlockDiagnosticVMOptions". >>> At present I have placed 4 flags under "diagnostic_pd" >>> >>> 1. 1. InitArrayShortSize >>> >>> 2. 2. ImplicitNullChecks >>> >>> 3. 3. InlineFrequencyCount >>> >>> 4. 4. PostLoopMultiversioning >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer From yasuenag at gmail.com Fri May 6 11:42:32 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 6 May 2016 20:42:32 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <57177463.8060003@oracle.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> <57177463.8060003@oracle.com> Message-ID: PING: Have you ever reviewed it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ I've sent review request to parse core image with JSnap. If you have unclear point about this change, please tell me. Thanks, Yasumasa On 2016/04/20 21:21, Dmitry Samersoff wrote: > Yasumasa, > > I need some more time to check what is happening with performance > counters and what side effect this fix can have. > > Sorry about it. > > -Dmitry > > > On 2016-04-20 15:14, Yasumasa Suenaga wrote: >> PING: Could you review it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >> >> This changes is based on jdk9/hs-rt. >> But I confirmed this patch works fine on jdk9/hs . >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/13 22:22, Yasumasa Suenaga wrote: >>> Hi Dmitry, >>> >>> Thank you for your comment. >>> I uploaded new webrev. Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>>> Yasumasa, >>>> >>>> Yes. It's better. >>>> >>>> Please place all _saved_* declarations together and add a comment >>>> explaining what is the purpose of this variables. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Could you review and sponsor it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>> >>>>> If it is not accepted, I think that we can add new field to PerfMemory >>>>> for using in JSnap: >>>>> ----------------------- >>>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>>> 2016 +0000 >>>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>>> 2016 +0900 >>>>> @@ -45,11 +45,16 @@ >>>>> UINT_CHARS + 1; >>>>> >>>>> char* PerfMemory::_start = NULL; >>>>> +char* PerfMemory::_saved_start = NULL; >>>>> char* PerfMemory::_end = NULL; >>>>> +char* PerfMemory::_saved_end = NULL; >>>>> char* PerfMemory::_top = NULL; >>>>> +char* PerfMemory::_saved_top = NULL; >>>>> size_t PerfMemory::_capacity = 0; >>>>> +size_t PerfMemory::_saved_capacity = 0; >>>>> jint PerfMemory::_initialized = false; >>>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>>> >>>>> void perfMemory_init() { >>>>> >>>>> @@ -103,6 +108,8 @@ >>>>> >>>>> // allocate PerfData memory region >>>>> create_memory_region(capacity); >>>>> + _saved_start = _start; >>>>> + _saved_capacity = _capacity; >>>>> >>>>> if (_start == NULL) { >>>>> >>>>> @@ -132,8 +139,11 @@ >>>>> } >>>>> >>>>> _prologue = (PerfDataPrologue *)_start; >>>>> + _saved_prologue = _prologue; >>>>> _end = _start + _capacity; >>>>> + _saved_end = _end; >>>>> _top = _start + sizeof(PerfDataPrologue); >>>>> + _saved_top = _top; >>>>> } >>>>> >>>>> assert(_prologue != NULL, "prologue pointer must be initialized"); >>>>> ----------------------- >>>>> >>>>> If it is better, I will upload a webrev. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> Thanks for your comment. >>>>>> >>>>>> I uploaded a new webrev. Could you review again? >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>> >>>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>>> Yasumasa, >>>>>>> >>>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>>> message >>>>>>> instead of NPE. >>>>>> >>>>>> I added null check and set message to PerfMemory.java . >>>>>> >>>>>> >>>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>>> the >>>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>>> part of >>>>>>> the fix is not dangerous. >>>>>> >>>>>> I added new flag (_destroyed) in PerfMemory class. >>>>>> This flag set true at PerfMemory::destroy(). >>>>>> >>>>>> _start, _end, and more field which I removed from destroy() are >>>>>> private member of >>>>>> PerfMemory. I implemented that the getter functions of them check >>>>>> _destroyed flag, >>>>>> and returns same value before this change. >>>>>> >>>>>> So I think this change does not affect other place. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review it? >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review it? >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>>> >: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>>> images, I >>>>>>>>> encountered NPE: >>>>>>>>> ------------- >>>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>>> at >>>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>>> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>>> at >>>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>>> at >>>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>>> ------------- >>>>>>>>> >>>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>>> JSnap. >>>>>>>>> Thus NPE is occurred. >>>>>>>>> >>>>>>>>> I uploaded webrev for this issue. >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>>> >>>>>>>>> I cannot access JPRT. >>>>>>>>> So I need a Sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>> >>>>>>> >>>> >>>> > > From dmitry.samersoff at oracle.com Fri May 6 12:06:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 6 May 2016 15:06:18 +0300 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name In-Reply-To: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> References: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> Message-ID: <572C88BA.50807@oracle.com> Yasumasa, The changes looks good. I'll sponsor the push. 1. I would prefer to check arguments explicitly for better readability: if (!requestHeapDump && dumpfile != null) { throw IAE("Unexpected argument dumpfile"); } 2. Please update jdk/test/sun/tools/jhsdb/BasicLauncherTest.java -Dmitry On 2016-05-04 17:47, Yasumasa Suenaga wrote: > Hi all, > > This review request relates to [1]. > > We cannot change heapdump name (heap.bin) when we genarate heapdump via > jhsdb. > > When we use jmap, we can change heapdump name through file option. > I want to set it like a jmap. > > I uploaded webrev for this enhancement. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri May 6 12:22:25 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 6 May 2016 15:22:25 +0300 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> <57177463.8060003@oracle.com> Message-ID: <572C8C81.9010903@oracle.com> Yasumasa, I understand the problem, but I'm concerned of storing pointers to invalid memory region just for coredump. Sorry! The solution might be in another areas, e.g. print value of performance counters to hs_err.log on crash. -Dmitry On 2016-05-06 14:42, Yasumasa Suenaga wrote: > PING: Have you ever reviewed it? > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ > > I've sent review request to parse core image with JSnap. > If you have unclear point about this change, please tell me. > > > Thanks, > > Yasumasa > > > On 2016/04/20 21:21, Dmitry Samersoff wrote: >> Yasumasa, >> >> I need some more time to check what is happening with performance >> counters and what side effect this fix can have. >> >> Sorry about it. >> >> -Dmitry >> >> >> On 2016-04-20 15:14, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>> >>> This changes is based on jdk9/hs-rt. >>> But I confirmed this patch works fine on jdk9/hs . >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/13 22:22, Yasumasa Suenaga wrote: >>>> Hi Dmitry, >>>> >>>> Thank you for your comment. >>>> I uploaded new webrev. Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>>>> Yasumasa, >>>>> >>>>> Yes. It's better. >>>>> >>>>> Please place all _saved_* declarations together and add a comment >>>>> explaining what is the purpose of this variables. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Could you review and sponsor it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>> >>>>>> If it is not accepted, I think that we can add new field to >>>>>> PerfMemory >>>>>> for using in JSnap: >>>>>> ----------------------- >>>>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>>>> 2016 +0000 >>>>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>>>> 2016 +0900 >>>>>> @@ -45,11 +45,16 @@ >>>>>> UINT_CHARS + 1; >>>>>> >>>>>> char* PerfMemory::_start = NULL; >>>>>> +char* PerfMemory::_saved_start = NULL; >>>>>> char* PerfMemory::_end = NULL; >>>>>> +char* PerfMemory::_saved_end = NULL; >>>>>> char* PerfMemory::_top = NULL; >>>>>> +char* PerfMemory::_saved_top = NULL; >>>>>> size_t PerfMemory::_capacity = 0; >>>>>> +size_t PerfMemory::_saved_capacity = 0; >>>>>> jint PerfMemory::_initialized = false; >>>>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>>>> >>>>>> void perfMemory_init() { >>>>>> >>>>>> @@ -103,6 +108,8 @@ >>>>>> >>>>>> // allocate PerfData memory region >>>>>> create_memory_region(capacity); >>>>>> + _saved_start = _start; >>>>>> + _saved_capacity = _capacity; >>>>>> >>>>>> if (_start == NULL) { >>>>>> >>>>>> @@ -132,8 +139,11 @@ >>>>>> } >>>>>> >>>>>> _prologue = (PerfDataPrologue *)_start; >>>>>> + _saved_prologue = _prologue; >>>>>> _end = _start + _capacity; >>>>>> + _saved_end = _end; >>>>>> _top = _start + sizeof(PerfDataPrologue); >>>>>> + _saved_top = _top; >>>>>> } >>>>>> >>>>>> assert(_prologue != NULL, "prologue pointer must be >>>>>> initialized"); >>>>>> ----------------------- >>>>>> >>>>>> If it is better, I will upload a webrev. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Thanks for your comment. >>>>>>> >>>>>>> I uploaded a new webrev. Could you review again? >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>> >>>>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>>>> Yasumasa, >>>>>>>> >>>>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>>>> message >>>>>>>> instead of NPE. >>>>>>> >>>>>>> I added null check and set message to PerfMemory.java . >>>>>>> >>>>>>> >>>>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>>>> the >>>>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>>>> part of >>>>>>>> the fix is not dangerous. >>>>>>> >>>>>>> I added new flag (_destroyed) in PerfMemory class. >>>>>>> This flag set true at PerfMemory::destroy(). >>>>>>> >>>>>>> _start, _end, and more field which I removed from destroy() are >>>>>>> private member of >>>>>>> PerfMemory. I implemented that the getter functions of them check >>>>>>> _destroyed flag, >>>>>>> and returns same value before this change. >>>>>>> >>>>>>> So I think this change does not affect other place. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review it? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review it? >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>>>> >: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>>>> images, I >>>>>>>>>> encountered NPE: >>>>>>>>>> ------------- >>>>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>>>> at >>>>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>>>> at >>>>>>>>>> sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>>>> at >>>>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>>>> at >>>>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>>>> ------------- >>>>>>>>>> >>>>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>>>> JSnap. >>>>>>>>>> Thus NPE is occurred. >>>>>>>>>> >>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>> Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>>>> >>>>>>>>>> I cannot access JPRT. >>>>>>>>>> So I need a Sponsor. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Fri May 6 12:24:37 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 6 May 2016 21:24:37 +0900 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name In-Reply-To: <572C88BA.50807@oracle.com> References: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> <572C88BA.50807@oracle.com> Message-ID: <7102856c-9c39-6d42-7383-3cc57cbd3cc9@gmail.com> Hi Dmitry, Thank you for reviewing! On 2016/05/06 21:06, Dmitry Samersoff wrote: > Yasumasa, > > The changes looks good. I'll sponsor the push. Thanks! > 1. I would prefer to check arguments explicitly for better readability: > > if (!requestHeapDump && dumpfile != null) { > throw IAE("Unexpected argument dumpfile"); > } I'll fix it. > 2. Please update > > jdk/test/sun/tools/jhsdb/BasicLauncherTest.java BasicLauncherTest launches each SA tools with --pid argument only. Should we add test for generating heapdump in it? Thanks, Yasumasa > -Dmitry > > On 2016-05-04 17:47, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request relates to [1]. >> >> We cannot change heapdump name (heap.bin) when we genarate heapdump via >> jhsdb. >> >> When we use jmap, we can change heapdump name through file option. >> I want to set it like a jmap. >> >> I uploaded webrev for this enhancement. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ >> >> I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html >> > > From yasuenag at gmail.com Fri May 6 12:42:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 6 May 2016 21:42:24 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <572C8C81.9010903@oracle.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> <57177463.8060003@oracle.com> <572C8C81.9010903@oracle.com> Message-ID: <2d5c92ad-6891-1c7c-0c7c-eb68c79b6cac@gmail.com> Hi Dmitry, On 2016/05/06 21:22, Dmitry Samersoff wrote: > Yasumasa, > > I understand the problem, but I'm concerned of storing pointers to > invalid memory region just for coredump. Sorry! I do not think that it is NOT invalid memory in webrev.02 . PerfMemory is mmap'ed, and it is not unmap'ed. In addition, webrev.02 adds several pointers to store addresses which are related to PerfMemory. It is not disruptive against current memory management which is related to PerfMemory. Coredump will include all virtual memory and thread contexts. If pointers ( _saved_* in webrev.02) are invalid, it is not affect JVM behavior, but JSnap will fail. (This pointer is referred from JSnap only.) > The solution might be in another areas, e.g. print value of performance > counters to hs_err.log on crash. If so, we have to use native debugger. For Java developers and troubleshooters, I want to support this feature with JDK tool. Thanks, Yasumasa > -Dmitry > > > On 2016-05-06 14:42, Yasumasa Suenaga wrote: >> PING: Have you ever reviewed it? >> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >> >> I've sent review request to parse core image with JSnap. >> If you have unclear point about this change, please tell me. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/20 21:21, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> I need some more time to check what is happening with performance >>> counters and what side effect this fix can have. >>> >>> Sorry about it. >>> >>> -Dmitry >>> >>> >>> On 2016-04-20 15:14, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>> >>>> This changes is based on jdk9/hs-rt. >>>> But I confirmed this patch works fine on jdk9/hs . >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/13 22:22, Yasumasa Suenaga wrote: >>>>> Hi Dmitry, >>>>> >>>>> Thank you for your comment. >>>>> I uploaded new webrev. Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>>>>> Yasumasa, >>>>>> >>>>>> Yes. It's better. >>>>>> >>>>>> Please place all _saved_* declarations together and add a comment >>>>>> explaining what is the purpose of this variables. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Could you review and sponsor it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>> >>>>>>> If it is not accepted, I think that we can add new field to >>>>>>> PerfMemory >>>>>>> for using in JSnap: >>>>>>> ----------------------- >>>>>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>>>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>>>>> 2016 +0000 >>>>>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>>>>> 2016 +0900 >>>>>>> @@ -45,11 +45,16 @@ >>>>>>> UINT_CHARS + 1; >>>>>>> >>>>>>> char* PerfMemory::_start = NULL; >>>>>>> +char* PerfMemory::_saved_start = NULL; >>>>>>> char* PerfMemory::_end = NULL; >>>>>>> +char* PerfMemory::_saved_end = NULL; >>>>>>> char* PerfMemory::_top = NULL; >>>>>>> +char* PerfMemory::_saved_top = NULL; >>>>>>> size_t PerfMemory::_capacity = 0; >>>>>>> +size_t PerfMemory::_saved_capacity = 0; >>>>>>> jint PerfMemory::_initialized = false; >>>>>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>>>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>>>>> >>>>>>> void perfMemory_init() { >>>>>>> >>>>>>> @@ -103,6 +108,8 @@ >>>>>>> >>>>>>> // allocate PerfData memory region >>>>>>> create_memory_region(capacity); >>>>>>> + _saved_start = _start; >>>>>>> + _saved_capacity = _capacity; >>>>>>> >>>>>>> if (_start == NULL) { >>>>>>> >>>>>>> @@ -132,8 +139,11 @@ >>>>>>> } >>>>>>> >>>>>>> _prologue = (PerfDataPrologue *)_start; >>>>>>> + _saved_prologue = _prologue; >>>>>>> _end = _start + _capacity; >>>>>>> + _saved_end = _end; >>>>>>> _top = _start + sizeof(PerfDataPrologue); >>>>>>> + _saved_top = _top; >>>>>>> } >>>>>>> >>>>>>> assert(_prologue != NULL, "prologue pointer must be >>>>>>> initialized"); >>>>>>> ----------------------- >>>>>>> >>>>>>> If it is better, I will upload a webrev. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> Thanks for your comment. >>>>>>>> >>>>>>>> I uploaded a new webrev. Could you review again? >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>>> >>>>>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>>>>> Yasumasa, >>>>>>>>> >>>>>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>>>>> message >>>>>>>>> instead of NPE. >>>>>>>> >>>>>>>> I added null check and set message to PerfMemory.java . >>>>>>>> >>>>>>>> >>>>>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>>>>> the >>>>>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>>>>> part of >>>>>>>>> the fix is not dangerous. >>>>>>>> >>>>>>>> I added new flag (_destroyed) in PerfMemory class. >>>>>>>> This flag set true at PerfMemory::destroy(). >>>>>>>> >>>>>>>> _start, _end, and more field which I removed from destroy() are >>>>>>>> private member of >>>>>>>> PerfMemory. I implemented that the getter functions of them check >>>>>>>> _destroyed flag, >>>>>>>> and returns same value before this change. >>>>>>>> >>>>>>>> So I think this change does not affect other place. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review it? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>>>>> PING: Could you review it? >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>>>>> images, I >>>>>>>>>>> encountered NPE: >>>>>>>>>>> ------------- >>>>>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>>>>> at >>>>>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>>>>> at >>>>>>>>>>> sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>>>>> at >>>>>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>>>>> at >>>>>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>>>>> ------------- >>>>>>>>>>> >>>>>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>>>>> JSnap. >>>>>>>>>>> Thus NPE is occurred. >>>>>>>>>>> >>>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>>> Could you review it? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> I cannot access JPRT. >>>>>>>>>>> So I need a Sponsor. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>> >>> > > From dmitry.samersoff at oracle.com Fri May 6 12:46:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 6 May 2016 15:46:08 +0300 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name In-Reply-To: <7102856c-9c39-6d42-7383-3cc57cbd3cc9@gmail.com> References: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> <572C88BA.50807@oracle.com> <7102856c-9c39-6d42-7383-3cc57cbd3cc9@gmail.com> Message-ID: <572C9210.7000404@oracle.com> Yasumasa, > BasicLauncherTest launches each SA tools with --pid argument only. > Should we add test for generating heapdump in it? Yes. Please make sure that LingeredApp is launched with small heap value (-Xmx256M) at ll. 103 and add something like launch("", "jmap", "--binaryheap", "--dumpfile="); -Dmitry On 2016-05-06 15:24, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thank you for reviewing! > > On 2016/05/06 21:06, Dmitry Samersoff wrote: >> Yasumasa, >> >> The changes looks good. I'll sponsor the push. > > Thanks! > > >> 1. I would prefer to check arguments explicitly for better readability: >> >> if (!requestHeapDump && dumpfile != null) { >> throw IAE("Unexpected argument dumpfile"); >> } > > I'll fix it. > > >> 2. Please update >> >> jdk/test/sun/tools/jhsdb/BasicLauncherTest.java > > BasicLauncherTest launches each SA tools with --pid argument only. > Should we add test for generating heapdump in it? > > > Thanks, > > Yasumasa > > >> -Dmitry >> >> On 2016-05-04 17:47, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request relates to [1]. >>> >>> We cannot change heapdump name (heap.bin) when we genarate heapdump via >>> jhsdb. >>> >>> When we use jmap, we can change heapdump name through file option. >>> I want to set it like a jmap. >>> >>> I uploaded webrev for this enhancement. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ >>> >>> I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html >>> >>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri May 6 13:18:59 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 6 May 2016 16:18:59 +0300 Subject: RFR(M): v.05, 8155091: Remove SA related functions from tmtools In-Reply-To: <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> Message-ID: <572C99C3.70206@oracle.com> Everybody, Please, see updated webrev. http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ Removed ToolProvider interface. run(String ... args) function removed or renamed to runWithArgs. Fixed two more tests, missed on previous iteration. -Dmitry On 2016-05-05 22:48, Mandy Chung wrote: > >> On May 5, 2016, at 5:51 AM, Dmitry Samersoff wrote: >> >> Please, see updated webrev. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ToolProvider.java > I suggest to remove this as jdk.hotspot.agent is no longer a provider. You could keep the getName and run methods and just remove @Override annotation. > > I only skimmed on the jdk change. > > test/sun/tools/jinfo/BasicJInfoTest.java > It has @bug 6260070 (an old bug). Is it renamed from an existing test? OR just cut-n-paste error. > > 35 * @modules java.management > > Is this still needed? > > test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java and other jhsdb tests > should have @modules jdk.hotspot.agent > > Mandy > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Fri May 6 13:39:26 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 6 May 2016 22:39:26 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <2d5c92ad-6891-1c7c-0c7c-eb68c79b6cac@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> <57177463.8060003@oracle.com> <572C8C81.9010903@oracle.com> <2d5c92ad-6891-1c7c-0c7c-eb68c79b6cac@gmail.com> Message-ID: <1c38c514-88b6-5252-f3ca-21852bd86559@gmail.com> Dmitry, >> The solution might be in another areas, e.g. print value of performance >> counters to hs_err.log on crash. > > If so, we have to use native debugger. > For Java developers and troubleshooters, I want to support this feature > with JDK tool. If we encounter native stack overflow error, we cannot get hs_err log. I posted a bug report for this issue as JDK-7109520, but it was rejected. In all crash case, we might collect core image. If I collect it, I want to check performance counter in it. Thus I want to merge this patch to JDK 9. Is it difficult? Thanks, Yasumasa On 2016/05/06 21:42, Yasumasa Suenaga wrote: > Hi Dmitry, > > On 2016/05/06 21:22, Dmitry Samersoff wrote: >> Yasumasa, >> >> I understand the problem, but I'm concerned of storing pointers to >> invalid memory region just for coredump. Sorry! > > I do not think that it is NOT invalid memory in webrev.02 . > PerfMemory is mmap'ed, and it is not unmap'ed. > > In addition, webrev.02 adds several pointers to store addresses which are > related to PerfMemory. > It is not disruptive against current memory management which is related to > PerfMemory. > > Coredump will include all virtual memory and thread contexts. > If pointers ( _saved_* in webrev.02) are invalid, it is not affect JVM behavior, > but JSnap will fail. > (This pointer is referred from JSnap only.) > > >> The solution might be in another areas, e.g. print value of performance >> counters to hs_err.log on crash. > > If so, we have to use native debugger. > For Java developers and troubleshooters, I want to support this feature > with JDK tool. > > > Thanks, > > Yasumasa > > >> -Dmitry >> >> >> On 2016-05-06 14:42, Yasumasa Suenaga wrote: >>> PING: Have you ever reviewed it? >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>> >>> I've sent review request to parse core image with JSnap. >>> If you have unclear point about this change, please tell me. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/20 21:21, Dmitry Samersoff wrote: >>>> Yasumasa, >>>> >>>> I need some more time to check what is happening with performance >>>> counters and what side effect this fix can have. >>>> >>>> Sorry about it. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-04-20 15:14, Yasumasa Suenaga wrote: >>>>> PING: Could you review it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>>> >>>>> This changes is based on jdk9/hs-rt. >>>>> But I confirmed this patch works fine on jdk9/hs . >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/13 22:22, Yasumasa Suenaga wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> Thank you for your comment. >>>>>> I uploaded new webrev. Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>>>>>> Yasumasa, >>>>>>> >>>>>>> Yes. It's better. >>>>>>> >>>>>>> Please place all _saved_* declarations together and add a comment >>>>>>> explaining what is the purpose of this variables. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could you review and sponsor it? >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>>> >>>>>>>> If it is not accepted, I think that we can add new field to >>>>>>>> PerfMemory >>>>>>>> for using in JSnap: >>>>>>>> ----------------------- >>>>>>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>>>>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>>>>>> 2016 +0000 >>>>>>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>>>>>> 2016 +0900 >>>>>>>> @@ -45,11 +45,16 @@ >>>>>>>> UINT_CHARS + 1; >>>>>>>> >>>>>>>> char* PerfMemory::_start = NULL; >>>>>>>> +char* PerfMemory::_saved_start = NULL; >>>>>>>> char* PerfMemory::_end = NULL; >>>>>>>> +char* PerfMemory::_saved_end = NULL; >>>>>>>> char* PerfMemory::_top = NULL; >>>>>>>> +char* PerfMemory::_saved_top = NULL; >>>>>>>> size_t PerfMemory::_capacity = 0; >>>>>>>> +size_t PerfMemory::_saved_capacity = 0; >>>>>>>> jint PerfMemory::_initialized = false; >>>>>>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>>>>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>>>>>> >>>>>>>> void perfMemory_init() { >>>>>>>> >>>>>>>> @@ -103,6 +108,8 @@ >>>>>>>> >>>>>>>> // allocate PerfData memory region >>>>>>>> create_memory_region(capacity); >>>>>>>> + _saved_start = _start; >>>>>>>> + _saved_capacity = _capacity; >>>>>>>> >>>>>>>> if (_start == NULL) { >>>>>>>> >>>>>>>> @@ -132,8 +139,11 @@ >>>>>>>> } >>>>>>>> >>>>>>>> _prologue = (PerfDataPrologue *)_start; >>>>>>>> + _saved_prologue = _prologue; >>>>>>>> _end = _start + _capacity; >>>>>>>> + _saved_end = _end; >>>>>>>> _top = _start + sizeof(PerfDataPrologue); >>>>>>>> + _saved_top = _top; >>>>>>>> } >>>>>>>> >>>>>>>> assert(_prologue != NULL, "prologue pointer must be >>>>>>>> initialized"); >>>>>>>> ----------------------- >>>>>>>> >>>>>>>> If it is better, I will upload a webrev. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> Thanks for your comment. >>>>>>>>> >>>>>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>>>> >>>>>>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>>>>>> Yasumasa, >>>>>>>>>> >>>>>>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>>>>>> message >>>>>>>>>> instead of NPE. >>>>>>>>> >>>>>>>>> I added null check and set message to PerfMemory.java . >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>>>>>> the >>>>>>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>>>>>> part of >>>>>>>>>> the fix is not dangerous. >>>>>>>>> >>>>>>>>> I added new flag (_destroyed) in PerfMemory class. >>>>>>>>> This flag set true at PerfMemory::destroy(). >>>>>>>>> >>>>>>>>> _start, _end, and more field which I removed from destroy() are >>>>>>>>> private member of >>>>>>>>> PerfMemory. I implemented that the getter functions of them check >>>>>>>>> _destroyed flag, >>>>>>>>> and returns same value before this change. >>>>>>>>> >>>>>>>>> So I think this change does not affect other place. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>>>>>> PING: Could you review it? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>>>>>> images, I >>>>>>>>>>>> encountered NPE: >>>>>>>>>>>> ------------- >>>>>>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>>>>>> at >>>>>>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>>>>>> at >>>>>>>>>>>> sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>>>>>> at >>>>>>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>>>>>> at >>>>>>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>>>>>> ------------- >>>>>>>>>>>> >>>>>>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>>>>>> JSnap. >>>>>>>>>>>> Thus NPE is occurred. >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>>>> Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> I cannot access JPRT. >>>>>>>>>>>> So I need a Sponsor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>> >>>> >> >> From david.holmes at oracle.com Fri May 6 13:58:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 23:58:01 +1000 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> Message-ID: <5a649768-a418-157a-eec5-234bb6cd14dc@oracle.com> On 6/05/2016 5:12 PM, Robbin Ehn wrote: > Hi David, thanks for taking the time looking at this! > > On 05/06/2016 07:20 AM, David Holmes wrote: >> Hi Robbin, >> >> Please see comments far below regarding mapping ... >> >> On 4/05/2016 5:25 AM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review this. >>> >>> This changeset moves redefine classes tracing to UL. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 >>> Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> >> I wonder whether the RC timers can be better integrated as was done with >> other use of timers with logging? A scope-based Timer class would fix >> the problem of conditionally starting timers, but unconditionally >> stopping them. > > Since I saw no harm in calling elapsedTimer.stop() so I did it this way. > > Let me know you you want me to do scoped instead. (one of the scopes are > really bid) You'd need to look at the other UL connected timers. I can't recall them off the top of my head. :) >> >>> Passes testsuits >>> jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist >>> >>> >>> with: >>> -Xlog:redefine+class*=trace >>> (a few test won't run with extra options) >>> >>> -XX:TraceRedefineClasses=xyz turns on (aliased with) >>> "-Xlog:redefine+class*=info" and emits a warning. >>> (xyz is ignored) >>> >>> Thanks! >>> >>> /Robbin >>> >>> Example of useage: >>> -Xlog:redefine+class+constantpool*=debug >>> -Xlog:redefine+class+load=info >>> -Xlog:redefine+class*=debug,redefine+class+iklass*=trace >>> >>> Here is an example from a test: >>> >>> [20.279s][debug][redefine,class,update,vtables ] vtable method >>> update: getOptions(()Ljava/util/Properties;), updated default = false >>> [20.279s][debug][redefine,class,subclass ] updated count in >>> subclass=nsk.share.jvmti.ArgumentHandler to 197 >>> [20.279s][info ][redefine,class,load ] redefined >>> name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) >>> [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, >>> obsolete_cnt=0 >>> [20.285s][trace][redefine,class,iklass,add ] adding previous >>> version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 >>> [20.285s][trace][redefine,class,iklass,add ] scratch class not >>> added; no methods are running >>> [20.285s][info ][redefine,class,update ] adjust: >>> name=nsk.share.jvmti.ArgumentHandler >>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>> getAgentOptionsString(()Ljava/lang/String;) >>> [20.285s][info ][redefine,class,update ] adjust: >>> name=nsk.share.jvmti.ArgumentHandler >>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>> (([Ljava/lang/String;)V) >>> [20.285s][info ][redefine,class,load ] redefined >>> name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) >>> [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>> obsolete_cnt=0 >>> [20.291s][trace][redefine,class,iklass,add ] adding previous >>> version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 >>> [20.291s][trace][redefine,class,iklass,add ] scratch class not >>> added; no methods are running >>> [20.291s][info ][redefine,class,update ] adjust: >>> name=nsk.share.jvmti.JVMTITest >>> [20.291s][debug][redefine,class,update,constantpool] cpc entry update: >>> commonInit(([Ljava/lang/String;)[Ljava/lang/String;) >>> [20.291s][info ][redefine,class,load ] redefined >>> name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) >>> [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>> obsolete_cnt=0 >>> [20.297s][trace][redefine,class,iklass,add ] adding previous >>> version ref for nsk.share.TestBug, EMCP_cnt=3 >>> >>> Mapping: >> >> Very unclear how you selected info/debug/trace for each of these. Given > > I have select them after verbosity (looking at distribution after tests > runs) and granularity. But sure it is a bit arbitrary. > >> they use different tag sets they could really all be "info" for their >> set. > > They use different level due for the use-case: > > Enable info for all tagset containing the two tags redefine+class > -Xlog:redefine+class*=info > > Also enable debug for constantpool > -Xlog:redefine+class*=info,redefine+class+constantpool=debug > > Also enable trace for all updates > -Xlog:redefine+class*=info,redefine+class+constantpool=debug,redefine+class+update*=trace That seems somewhat of a self-justifying definition. Where did those usecases come from? You seem to have decided that redefine+class+constantpool is less important than other redefine+class+XXX, and you've decided to use a wildcard which means you need a way to disable redefine+class+constantpool and so you drop it to debug instead of info. Many of our decisions seem to be driven by the perceived desire to use wildcards in a specific way. :( > >> >>> RC_TRACE_MESG = "redefine, class, update" - info >>> >>> 0x00000001 = "redefine, class, load" - info >>> 0x00000001 = "redefine, class, load" - debug >>> >>> 0x00000002 = "redefine, class, load, exceptions" - info >>> 0x00000004 = "redefine, class, timer" - info >>> 0x00000008 = "redefine, class, subclass" - debug >>> >>> 0x00000100 = "redefine, class, obsolete, mark" - trace >>> 0x00000200 = "redefine, class, iklass, purge" - trace >>> 0x00000400 = "redefine, class, iklass, add" - trace >>> 0x00000800 = "redefine, class, breakpoint" - debug >>> >>> 0x00001000->0x00002000 = "redefine, class, obsolete" - trace >>> 0x00001000 = "redefine, class, obsolete" - trace >>> 0x00002000 = REMOVED >> >> I'm a little unclear about how the old ranges were supposed to work, but >> you have effectively removed them as far as I can see. A range of >> 1000->2000 would print out when "redefine, class, obsolete" was >> specified in conjunction with any, or all, or the preceding conditions - >> but now it will print only on that one condition. >> >> You also removed the debugging hooks related to this ie in >> sharedRuntime.cpp: >> >> - if (RC_TRACE_ENABLED(0x00002000)) { >> - // this option is provided to debug calls to obsolete methods >> - guarantee(false, "faulting at call to an obsolete method."); >> - } >> > > Yes 0x00002000 was removed, because we can't have "class*=trace" > enabling a guarantee. Perhaps not but that functionality for debugging has still been lost. > In the old code if either of those two bits were set it evaluated true. > (regardless off other bits) Not sure I follow that statement. > Since I removed one bit, this is a boolean and was translated to: > is "redefine, class, obsolete" enabled or not. No it (the TRACE_RANGE) isn't a boolean it is 0x00001000 to 0x00001FFF. The ranges provided a way of combining tracing levels in a simple way that is very cumbersome with UL tagging. Essentially a TRACE_RANGE(from, to, "xxx") would have to be written as: if (log_is_enabled(A, info) || log_is_enabled(B, info) || ... { log("xxx"); } for all A, B, C covered by the range. Cheers, David > Thanks! > > /Robbin > >> >> Thanks, >> David >> >>> 0x00004000 = "redefine, class, obsolete, metadata" - trace >>> 0x00004000 = "redefine, class, dump" - trace >>> >>> 0x00008000 = "redefine, class, normalize" - trace >>> >>> 0x00010000 = "redefine, class, constantpool" - info >>> 0x00020000 = "redefine, class, constantpool" - debug >>> 0x00040000 = "redefine, class, constantpool" - trace >>> 0x00080000 = "redefine, class, constantpool" - trace >>> >>> 0x00100000-0x00400000 = "redefine, class, update" - info >>> 0x00100000 = "redefine, class, update, vtables" - debug >>> 0x00200000 = "redefine, class, update, itables" - debug >>> 0x00400000 = "redefine, class, update, constantpool" - debug >>> >>> 0x00800000 = "redefine, class, methodcomparator" - debug >>> >>> 0x01000000 = "redefine, class, nmethod" - debug >>> 0x02000000 = "redefine, class, annotation" - debug >>> 0x04000000 = "redefine, class, stackmap" - debug >>> 0x08000000 = "redefine, class, oopmap" - debug >>> From yasuenag at gmail.com Fri May 6 14:41:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 6 May 2016 23:41:22 +0900 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name In-Reply-To: <572C9210.7000404@oracle.com> References: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> <572C88BA.50807@oracle.com> <7102856c-9c39-6d42-7383-3cc57cbd3cc9@gmail.com> <572C9210.7000404@oracle.com> Message-ID: <8f152a3a-748b-4087-9116-12aa39e1ba24@gmail.com> Hi Dmitry, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.01/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.01/jdk/ BasicLauncherTest works fine. Thanks, Yasumasa On 2016/05/06 21:46, Dmitry Samersoff wrote: > Yasumasa, > >> BasicLauncherTest launches each SA tools with --pid argument only. >> Should we add test for generating heapdump in it? > > Yes. > > Please make sure that LingeredApp is launched with small heap value > (-Xmx256M) at ll. 103 > > and add something like > > launch("", "jmap", "--binaryheap", > "--dumpfile="); > > -Dmitry > > On 2016-05-06 15:24, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> Thank you for reviewing! >> >> On 2016/05/06 21:06, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> The changes looks good. I'll sponsor the push. >> >> Thanks! >> >> >>> 1. I would prefer to check arguments explicitly for better readability: >>> >>> if (!requestHeapDump && dumpfile != null) { >>> throw IAE("Unexpected argument dumpfile"); >>> } >> >> I'll fix it. >> >> >>> 2. Please update >>> >>> jdk/test/sun/tools/jhsdb/BasicLauncherTest.java >> >> BasicLauncherTest launches each SA tools with --pid argument only. >> Should we add test for generating heapdump in it? >> >> >> Thanks, >> >> Yasumasa >> >> >>> -Dmitry >>> >>> On 2016-05-04 17:47, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request relates to [1]. >>>> >>>> We cannot change heapdump name (heap.bin) when we genarate heapdump via >>>> jhsdb. >>>> >>>> When we use jmap, we can change heapdump name through file option. >>>> I want to set it like a jmap. >>>> >>>> I uploaded webrev for this enhancement. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ >>>> >>>> I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html >>>> >>>> >>> >>> > > From dmitry.samersoff at oracle.com Fri May 6 15:36:44 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 6 May 2016 18:36:44 +0300 Subject: RFR: JDK-8156033: jhsdb jmap cannot set heapdump name In-Reply-To: <8f152a3a-748b-4087-9116-12aa39e1ba24@gmail.com> References: <443bf416-1891-d031-5184-52a2d9a09890@gmail.com> <572C88BA.50807@oracle.com> <7102856c-9c39-6d42-7383-3cc57cbd3cc9@gmail.com> <572C9210.7000404@oracle.com> <8f152a3a-748b-4087-9116-12aa39e1ba24@gmail.com> Message-ID: <572CBA0C.70509@oracle.com> Yasumasa, Looks good for me. Code below is not necessary - this test is not intended to deal with possible dump format error, just check that file with correct name is created. Please remove it (no need to re-review). BasicLauncherTest.java: 151 try { 152 HprofParser.parse(dump); 153 } catch (Exception e) { 154 e.printStackTrace(); 155 fail("Could not parse dump file " + dump.getAbsolutePath()); 156 } -Dmitry On 2016-05-06 17:41, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thank you for your comment. > I uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.01/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.01/jdk/ > > BasicLauncherTest works fine. > > > Thanks, > > Yasumasa > > > On 2016/05/06 21:46, Dmitry Samersoff wrote: >> Yasumasa, >> >>> BasicLauncherTest launches each SA tools with --pid argument only. >>> Should we add test for generating heapdump in it? >> >> Yes. >> >> Please make sure that LingeredApp is launched with small heap value >> (-Xmx256M) at ll. 103 >> >> and add something like >> >> launch("", "jmap", "--binaryheap", >> "--dumpfile="); >> >> -Dmitry >> >> On 2016-05-06 15:24, Yasumasa Suenaga wrote: >>> Hi Dmitry, >>> >>> Thank you for reviewing! >>> >>> On 2016/05/06 21:06, Dmitry Samersoff wrote: >>>> Yasumasa, >>>> >>>> The changes looks good. I'll sponsor the push. >>> >>> Thanks! >>> >>> >>>> 1. I would prefer to check arguments explicitly for better readability: >>>> >>>> if (!requestHeapDump && dumpfile != null) { >>>> throw IAE("Unexpected argument dumpfile"); >>>> } >>> >>> I'll fix it. >>> >>> >>>> 2. Please update >>>> >>>> jdk/test/sun/tools/jhsdb/BasicLauncherTest.java >>> >>> BasicLauncherTest launches each SA tools with --pid argument only. >>> Should we add test for generating heapdump in it? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> -Dmitry >>>> >>>> On 2016-05-04 17:47, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> We cannot change heapdump name (heap.bin) when we genarate heapdump >>>>> via >>>>> jhsdb. >>>>> >>>>> When we use jmap, we can change heapdump name through file option. >>>>> I want to set it like a jmap. >>>>> >>>>> I uploaded webrev for this enhancement. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8156033/webrev.00/ >>>>> >>>>> I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019510.html >>>>> >>>>> >>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From robbin.ehn at oracle.com Fri May 6 16:28:39 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 6 May 2016 18:28:39 +0200 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: <5a649768-a418-157a-eec5-234bb6cd14dc@oracle.com> References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> <5a649768-a418-157a-eec5-234bb6cd14dc@oracle.com> Message-ID: Hi David, On 05/06/2016 03:58 PM, David Holmes wrote: > On 6/05/2016 5:12 PM, Robbin Ehn wrote: >> Hi David, thanks for taking the time looking at this! >> >> On 05/06/2016 07:20 AM, David Holmes wrote: >>> Hi Robbin, >>> >>> Please see comments far below regarding mapping ... >>> >>> On 4/05/2016 5:25 AM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review this. >>>> >>>> This changeset moves redefine classes tracing to UL. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 >>>> Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> >>> I wonder whether the RC timers can be better integrated as was done with >>> other use of timers with logging? A scope-based Timer class would fix >>> the problem of conditionally starting timers, but unconditionally >>> stopping them. >> >> Since I saw no harm in calling elapsedTimer.stop() so I did it this way. >> >> Let me know you you want me to do scoped instead. (one of the scopes are >> really bid) > > You'd need to look at the other UL connected timers. I can't recall them > off the top of my head. :) > UL TraceTimer log directly when it go out of scope, here we don't. We summarize the 3 timers in 2 log lines. So it's just matter of scoped, and as I said one scope is 220 lines, so I prefer the way it is, if you don't mind? (or are you suggesting enhancements to TraceTime?) >>> >>>> Passes testsuits >>>> jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist >>>> >>>> >>>> >>>> with: >>>> -Xlog:redefine+class*=trace >>>> (a few test won't run with extra options) >>>> >>>> -XX:TraceRedefineClasses=xyz turns on (aliased with) >>>> "-Xlog:redefine+class*=info" and emits a warning. >>>> (xyz is ignored) >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>>> Example of useage: >>>> -Xlog:redefine+class+constantpool*=debug >>>> -Xlog:redefine+class+load=info >>>> -Xlog:redefine+class*=debug,redefine+class+iklass*=trace >>>> >>>> Here is an example from a test: >>>> >>>> [20.279s][debug][redefine,class,update,vtables ] vtable method >>>> update: getOptions(()Ljava/util/Properties;), updated default = false >>>> [20.279s][debug][redefine,class,subclass ] updated count in >>>> subclass=nsk.share.jvmti.ArgumentHandler to 197 >>>> [20.279s][info ][redefine,class,load ] redefined >>>> name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) >>>> [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, >>>> obsolete_cnt=0 >>>> [20.285s][trace][redefine,class,iklass,add ] adding previous >>>> version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 >>>> [20.285s][trace][redefine,class,iklass,add ] scratch class not >>>> added; no methods are running >>>> [20.285s][info ][redefine,class,update ] adjust: >>>> name=nsk.share.jvmti.ArgumentHandler >>>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>>> getAgentOptionsString(()Ljava/lang/String;) >>>> [20.285s][info ][redefine,class,update ] adjust: >>>> name=nsk.share.jvmti.ArgumentHandler >>>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>>> (([Ljava/lang/String;)V) >>>> [20.285s][info ][redefine,class,load ] redefined >>>> name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) >>>> [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>>> obsolete_cnt=0 >>>> [20.291s][trace][redefine,class,iklass,add ] adding previous >>>> version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 >>>> [20.291s][trace][redefine,class,iklass,add ] scratch class not >>>> added; no methods are running >>>> [20.291s][info ][redefine,class,update ] adjust: >>>> name=nsk.share.jvmti.JVMTITest >>>> [20.291s][debug][redefine,class,update,constantpool] cpc entry update: >>>> commonInit(([Ljava/lang/String;)[Ljava/lang/String;) >>>> [20.291s][info ][redefine,class,load ] redefined >>>> name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) >>>> [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>>> obsolete_cnt=0 >>>> [20.297s][trace][redefine,class,iklass,add ] adding previous >>>> version ref for nsk.share.TestBug, EMCP_cnt=3 >>>> >>>> Mapping: >>> >>> Very unclear how you selected info/debug/trace for each of these. Given >> >> I have select them after verbosity (looking at distribution after tests >> runs) and granularity. But sure it is a bit arbitrary. >> >>> they use different tag sets they could really all be "info" for their >>> set. >> >> They use different level due for the use-case: >> >> Enable info for all tagset containing the two tags redefine+class >> -Xlog:redefine+class*=info >> >> Also enable debug for constantpool >> -Xlog:redefine+class*=info,redefine+class+constantpool=debug >> >> Also enable trace for all updates >> -Xlog:redefine+class*=info,redefine+class+constantpool=debug,redefine+class+update*=trace >> > > That seems somewhat of a self-justifying definition. Where did those > usecases come from? You seem to have decided that > redefine+class+constantpool is less important than other > redefine+class+XXX, and you've decided to use a wildcard which means you > need a way to disable redefine+class+constantpool and so you drop it to > debug instead of info. This was just a random example. If constantpool was on info I would of course not enable redefine+class*=info but instead use redefine+class+XXX,redefine+class+YYY,redefine+class+ZZZ, until happy! 0x00010000-0x00080000 looked to me it would make more sense to put them in same tag-set but with different level. But we can of course have them on same level but different tag. > > Many of our decisions seem to be driven by the perceived desire to use > wildcards in a specific way. :( No, just that certain logs have more in common than others, e.g. is about constantpool. And enabling all logs with that information seemed like a valid use-case. (which happens to enable us to use wildcards for a few scenarios) > >> >>> >>>> RC_TRACE_MESG = "redefine, class, update" - info >>>> >>>> 0x00000001 = "redefine, class, load" - info >>>> 0x00000001 = "redefine, class, load" - debug >>>> >>>> 0x00000002 = "redefine, class, load, exceptions" - info >>>> 0x00000004 = "redefine, class, timer" - info >>>> 0x00000008 = "redefine, class, subclass" - debug >>>> >>>> 0x00000100 = "redefine, class, obsolete, mark" - trace >>>> 0x00000200 = "redefine, class, iklass, purge" - trace >>>> 0x00000400 = "redefine, class, iklass, add" - trace >>>> 0x00000800 = "redefine, class, breakpoint" - debug >>>> >>>> 0x00001000->0x00002000 = "redefine, class, obsolete" - trace >>>> 0x00001000 = "redefine, class, obsolete" - trace >>>> 0x00002000 = REMOVED >>> >>> I'm a little unclear about how the old ranges were supposed to work, but >>> you have effectively removed them as far as I can see. A range of >>> 1000->2000 would print out when "redefine, class, obsolete" was >>> specified in conjunction with any, or all, or the preceding conditions - >>> but now it will print only on that one condition. >>> >>> You also removed the debugging hooks related to this ie in >>> sharedRuntime.cpp: >>> >>> - if (RC_TRACE_ENABLED(0x00002000)) { >>> - // this option is provided to debug calls to obsolete methods >>> - guarantee(false, "faulting at call to an obsolete method."); >>> - } >>> >> >> Yes 0x00002000 was removed, because we can't have "class*=trace" >> enabling a guarantee. > > Perhaps not but that functionality for debugging has still been lost. As I said, intentionally. > >> In the old code if either of those two bits were set it evaluated true. >> (regardless off other bits) > > Not sure I follow that statement. > >> Since I removed one bit, this is a boolean and was translated to: >> is "redefine, class, obsolete" enabled or not. > > No it (the TRACE_RANGE) isn't a boolean it is 0x00001000 to 0x00001FFF. > The ranges provided a way of combining tracing levels in a simple way > that is very cumbersome with UL tagging. Essentially a TRACE_RANGE(from, > to, "xxx") would have to be written as: > > if (log_is_enabled(A, info) || > log_is_enabled(B, info) || > ... { > log("xxx"); > } > > for all A, B, C covered by the range. That might have been the original intention. It evaluate to true as long as any bit between low and high are set. E.g. in above 0x01001000 also is in range. ((bits & ((high << 1) - 1)) masks away high bits and & ~(low - 1)) masks away low bits This is also logical when reading the code, e.g. why should "impl details: OopMapCache updates" stop "detect calls to obsolete methods" ? So RC_TRACE_TIME(somevalue, 0x00001000, 0x00001000) is the same as somevalue&0x00001000, correct? But never the less, yes there are some drawbacks using UL. My hope and intention was that we could live with it. Thanks! /Robbin > > Cheers, > David > >> Thanks! >> >> /Robbin >> >>> >>> Thanks, >>> David >>> >>>> 0x00004000 = "redefine, class, obsolete, metadata" - trace >>>> 0x00004000 = "redefine, class, dump" - trace >>>> >>>> 0x00008000 = "redefine, class, normalize" - trace >>>> >>>> 0x00010000 = "redefine, class, constantpool" - info >>>> 0x00020000 = "redefine, class, constantpool" - debug >>>> 0x00040000 = "redefine, class, constantpool" - trace >>>> 0x00080000 = "redefine, class, constantpool" - trace >>>> >>>> 0x00100000-0x00400000 = "redefine, class, update" - info >>>> 0x00100000 = "redefine, class, update, vtables" - debug >>>> 0x00200000 = "redefine, class, update, itables" - debug >>>> 0x00400000 = "redefine, class, update, constantpool" - debug >>>> >>>> 0x00800000 = "redefine, class, methodcomparator" - debug >>>> >>>> 0x01000000 = "redefine, class, nmethod" - debug >>>> 0x02000000 = "redefine, class, annotation" - debug >>>> 0x04000000 = "redefine, class, stackmap" - debug >>>> 0x08000000 = "redefine, class, oopmap" - debug >>>> From kirill.zhaldybin at oracle.com Fri May 6 17:16:34 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 6 May 2016 20:16:34 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong Message-ID: <572CD172.7030700@oracle.com> Dear all, Could you please review this small fix for 8156226? A case when a method exists but parameters' signature is wrong now causes new ReflectionException(new IllegalArgumentException()) thrown instead of new ReflectionException(new NoSuchMethodException()). WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.00/ CR: https://bugs.openjdk.java.net/browse/JDK-8156226 Thank you. Regards, Kirill From serguei.spitsyn at oracle.com Fri May 6 17:17:02 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 6 May 2016 10:17:02 -0700 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a In-Reply-To: <572C47C6.4080602@oracle.com> References: <572C454B.3080302@oracle.com> <572C4680.6020403@oracle.com> <572C47C6.4080602@oracle.com> Message-ID: <572CD18E.8080800@oracle.com> Alan, This is a webrev that includes the jtreg test: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8156147-Jigsaw-agents.jdk0/ Thanks, Serguei On 5/6/16 00:29, serguei.spitsyn at oracle.com wrote: > On 5/6/16 00:23, Alan Bateman wrote: >> >> This looks okay to me except I don't see a test. I think we will need >> test coverage for instrumenting classes in the unnamed module of the >> boot loader. > > Ok, I'll check if some of the jdk_instrument tests can be modified to > add this coverage. > > >> >> Also can you push this to jdk9/dev? We have a number of people on >> jigsaw-dev reporting this issue and would be good to get it fixed in >> jdk-9+118. > > Sure, I'll rebase the fix to the jdk9/dev. > > > Thanks, > Serguei > > >> >> -Alan >> >> >> >> On 06/05/2016 08:18, serguei.spitsyn at oracle.com wrote: >>> Please, review a simple fix in the >>> java.lang.instrument.InstrumentationImpl transform() method. >>> >>> This is the patch: >>> >>> diff -r d2f46fdfc3ca src/java.base/share/classes/module-info.java >>> --- a/src/java.base/share/classes/module-info.java Thu May 05 >>> 11:44:01 2016 -0700 >>> +++ b/src/java.base/share/classes/module-info.java Fri May 06 >>> 00:11:23 2016 -0700 >>> @@ -145,6 +145,8 @@ >>> jdk.scripting.nashorn; >>> exports jdk.internal.org.objectweb.asm.signature to >>> jdk.scripting.nashorn; >>> + exports jdk.internal.loader to >>> + java.instrument; >>> exports jdk.internal.math to >>> java.desktop; >>> exports jdk.internal.module to >>> >>> >>> diff -r d2f46fdfc3ca >>> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >>> --- >>> a/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >>> Thu May 05 11:44:01 2016 -0700 >>> +++ >>> b/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java >>> Fri May 06 00:11:23 2016 -0700 >>> @@ -41,6 +41,8 @@ >>> import java.util.Objects; >>> import java.util.jar.JarFile; >>> >>> +import jdk.internal.loader.BootLoader; >>> + >>> /* >>> * Copyright 2003 Wily Technology, Inc. >>> */ >>> @@ -436,7 +438,8 @@ >>> if (classBeingRedefined != null) { >>> module = classBeingRedefined.getModule(); >>> } else { >>> - module = loader.getUnnamedModule(); >>> + module = (loader == null) ? >>> jdk.internal.loader.BootLoader.getUnnamedModule() >>> + : loader.getUnnamedModule(); >>> } >>> } >>> if (mgr == null) { >>> >>> >>> Summary: >>> >>> InstrumentationImpl.transform has this: >>> if (module == null) { >>> if (classBeingRedefined != null) { >>> module = classBeingRedefined.getModule(); >>> } else { >>> module = loader.getUnnamedModule(); >>> } >>> } >>> >>> but if loader is null (-Xbootclasspath/a case) then this throws >>> NullPointerException. >>> If loader is null then we need to use >>> jdk.internal.loader.BootLoader.getUnnamedModule(). >>> >>> >>> Testing: >>> In progress: run the JTreg :jdk_instrument tests. >>> >>> >>> Thanks, >>> Serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Fri May 6 17:24:47 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 6 May 2016 10:24:47 -0700 (PDT) Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong Message-ID: <945c461a-5c5f-4789-ac9e-93c34a7ba014@default> Hi Kirill, (I'm not a reviewer) Is there a specification of what shall be thrown, or the justification of the changes done? One can think that the currently thrown NoSuchMethodException is correct since?methods, which differ in signature only, are still different methods. Best regards, Alexander ----- Original Message ----- From: kirill.zhaldybin at oracle.com To: serviceability-dev at openjdk.java.net Sent: Friday, May 6, 2016 8:11:08 PM GMT +03:00 Iraq Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong Dear all, Could you please review this small fix for 8156226? A case when a method exists but parameters' signature is wrong now causes new ReflectionException(new IllegalArgumentException()) thrown instead of new ReflectionException(new NoSuchMethodException()). WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.00/ CR: https://bugs.openjdk.java.net/browse/JDK-8156226 Thank you. Regards, Kirill From kirill.zhaldybin at oracle.com Fri May 6 17:39:06 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 6 May 2016 20:39:06 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <945c461a-5c5f-4789-ac9e-93c34a7ba014@default> References: <945c461a-5c5f-4789-ac9e-93c34a7ba014@default> Message-ID: <572CD6BA.9030606@oracle.com> Alexander, Thank you for reviewing the fix. On 06.05.2016 20:24, Alexander Kulyakhtin wrote: > Is there a specification of what shall be thrown, or the justification of the changes done? > One can think that the currently thrown NoSuchMethodException is correct since?methods, which differ in signature only, are still different methods. I spent some time trying to figure out why I got NoSuchMethodException for "help" despite such method actually existed. If you think that to throw NoSuchMethodException is better for wrong signature I could just change error message in this case. Could you please let me know your opinion? Thank you. Regards, Kirill > > Best regards, > Alexander > > > ----- Original Message ----- > From: kirill.zhaldybin at oracle.com > To: serviceability-dev at openjdk.java.net > Sent: Friday, May 6, 2016 8:11:08 PM GMT +03:00 Iraq > Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong > > Dear all, > > Could you please review this small fix for 8156226? > > A case when a method exists but parameters' signature is wrong now > causes new ReflectionException(new IllegalArgumentException()) thrown > instead of new ReflectionException(new NoSuchMethodException()). > > WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.00/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8156226 > > Thank you. > > Regards, Kirill > From Alan.Bateman at oracle.com Fri May 6 19:23:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 20:23:46 +0100 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a In-Reply-To: <572CD18E.8080800@oracle.com> References: <572C454B.3080302@oracle.com> <572C4680.6020403@oracle.com> <572C47C6.4080602@oracle.com> <572CD18E.8080800@oracle.com> Message-ID: <572CEF42.80201@oracle.com> On 06/05/2016 18:17, serguei.spitsyn at oracle.com wrote: > Alan, > > This is a webrev that includes the jtreg test: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8156147-Jigsaw-agents.jdk0/ Thanks for adding a test, I think this looks okay although maybe in the future then the shell test could be replaced (I realize it is common in this area). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 6 19:28:14 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 6 May 2016 12:28:14 -0700 Subject: RFR (XS): 8156147 NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a In-Reply-To: <572CEF42.80201@oracle.com> References: <572C454B.3080302@oracle.com> <572C4680.6020403@oracle.com> <572C47C6.4080602@oracle.com> <572CD18E.8080800@oracle.com> <572CEF42.80201@oracle.com> Message-ID: <572CF04E.3040806@oracle.com> On 5/6/16 12:23, Alan Bateman wrote: > > > On 06/05/2016 18:17, serguei.spitsyn at oracle.com wrote: >> Alan, >> >> This is a webrev that includes the jtreg test: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8156147-Jigsaw-agents.jdk0/ > Thanks for adding a test, I think this looks okay although maybe in > the future then the shell test could be replaced (I realize it is > common in this area). Yes, we need to replace the shell scripts some day. Thanks, Alan! Serguei > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sun May 8 07:59:19 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 8 May 2016 00:59:19 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57287B9C.8060907@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> <1462178693.5579.18.camel@redhat.com> <57287B9C.8060907@oracle.com> Message-ID: <572EF1D7.4030504@oracle.com> Hi Severin, I filed two new bugs to cover the discovered issues: 8156498: more places in the invoke.c that need protection with the invokerLock 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java Will try to push your two fixes today or tomorrow. I know, you've just got a committer status. But I'm not sure you are comfortable to push the fixes yourself at this time. Thanks, Serguei On 5/3/16 03:21, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > Please, find my comments below. > > > On 5/2/16 01:44, Severin Gehwolf wrote: >> On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote: >>> On 4/29/16 01:56, Severin Gehwolf wrote: >>>> Hi Serguei, >>>> >>>> On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: >>>>> Hi Severin, >>>>> >>>>> The fix looks good in general. >>>>> I'm testing both fixes together at the moment. >>>> That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. >>>> >>>>> A couple of questions... >>>>> >>>>> It seems, there are more places where an invokerLock critical >>>>> section is missed. >>>> Right. >>>> >>>>> The following functions: >>>>> - invoker_enableInvokeRequests >>>> This should be fixed with the patch for JDK-8154529 >>>> >>>>> - invokeConstructor >>>>> - invokeStatic >>>>> - invokeNonvirtual >>>>> - invokeVirtual >>>>> - saveGlobalRef >>>> Correct. The intent would be to fix the callsites of saveGlobalRef. If >>>> we fix invoke* then saveGlobalRef should not be an issue. I didn't >>>> want >>>> to include this in this fix since it's pretty hairy and would like to >>>> fix this in incremental steps. >>>> >>>>> The first function is easy to fix. >>>>> The last 5 functions are called from the invoker_doInvoke() that >>>>> we already had a problem with. >>>>> I'm puzzled with the question: How to synchronize and avoid >>>>> deadlocks at the same time? >>>> I'm not sure yet. Perhaps locking only while saveGlobalRef is being >>>> called in invoke* functions will help. >>>> >>>>> I'm inclined to let your fix go (if the testing is Ok) and file >>>>> one more bug on the remaining sync issues. >>>> Please keep me in the loop about your test results. >>> Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are >>> all passed. >>> >>> I also ran the 4 previously failed tests in big loops of 1000 runs: >>> com/sun/jdi/InvokeTest.java >>> com/sun/jdi/InvokeHangTest.java >>> com/sun/jdi/InterfaceMethodsTest.java >>> com/sun/jdi/OomDebugTest.java (new test introduced in the webrev) >> I suggest to run InvokeTest, InvokeHangTest and InterfaceMethodsTest in >> a loop. Those never failed for me in such a scenario. >> >>> The OomDebugTest.java failed with a timeout (most likely, a deadlock). >>> Please, find the OomDebugTest.jtr file in attachments. >> Correct. This is what I was seeing. See the last comment of the bug: >> https://bugs.openjdk.java.net/browse/JDK-8153711 > > Need to check if it is the same as I'm seeing. > >> >> It has the jstack output of the hung OomDebugTestTarg JVM. I'm not >> convinced this is the same failure we were seeing in JDK-4858370 since >> the stack suggests it's doing a GC upon a newInstance of a primitive >> array. It also does not seem like the same issue as the deadlocks >> exposed by locking during an invoke, because it was reproducible fairly >> consistently with InvokeHangTest. > > Agreed. > > >> >> It looks to me like a new issue. Probably one which was there before, >> but is only exposed by the new test. The new test stress-tests the GC >> with a debugger attached. Of course, this is going to be hard to prove >> since it would just run out of memory prior the patch. > > Thanks. > Your analysis seems to be reasonable. > I tend to agree with it but need more time to convince myself. > > >> Thoughts? > > Let me double check the above. > If the analysis is correct then I'd suggest to file new bug and push > your fix as is. > > > Thanks, > Serguei > > >> >> Cheers, >> Severin >> >> >> >>> Thanks, >>> Serguei >>> >>> >>> >>>> Thanks for your help! >>>> >>>> Cheers, >>>> Severin >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/28/16 02:00, Severin Gehwolf wrote: >>>>>> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Severin, >>>>>>>> >>>>>>>> I postpone a push for this fix. >>>>>>>> >>>>>>>> There are two nsk.jdi test failures (they look like deadlocks): >>>>>>>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT) >>>>>>>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>>>>>>> >>>>>>>> and one jtreg sun/com/jdi failure (it looks like a deadlock too): >>>>>>>> com/sun/jdi/InvokeHangTes.java >>>>>>>> >>>>>>>> >>>>>>>> I'll double check if these failures are regressions caused by >>>>>>>> your fix >>>>>>>> or not. >>>>>>> I confirm, the failures above are new regressions introduced by >>>>>>> the fix. >>>>>>> The tests fail consistently with the fix and do not fail without >>>>>>> the fix. >>>>>> OK this was caused by the locking done in invoker_doInvoke(). >>>>>> Note that >>>>>> holding either of them invoker lock or event handler lock causes >>>>>> this. >>>>>> >>>>>> Here is a new webrev with those hunks removed. It's sufficient to >>>>>> grab >>>>>> the locks again in invoke_completeInvokeRequest() when clearing the >>>>>> global references in order to not get those failures we've seen when >>>>>> the fix for JDK-4858370 was in place. >>>>>> >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ >>>>>> >>>>>> Testing done: >>>>>> - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and >>>>>> sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. >>>>>> - regular com/sun/jdi test set: no regressions >>>>>> >>>>>> Note that there are some rare cases where OomDebugTest times out >>>>>> which >>>>>> seems to be caused by the GC, though. See the bug for details. Since >>>>>> this problem is rare, it's still worthwhile having that test >>>>>> included. >>>>>> If it turns out a problem in practice we could consider disabling >>>>>> the >>>>>> test. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Cheers, >>>>>> Severin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sun May 8 10:58:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 8 May 2016 03:58:44 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <572EF1D7.4030504@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> <1462178693.5579.18.camel@redhat.com> <57287B9C.8060907@oracle.com> <572EF1D7.4030504@oracle.com> Message-ID: <572F1BE4.8010207@oracle.com> Severin, The JPRT job failed: 2016-05-08-100525.sspitsyn.8153711 with a NullPointerException. The log link is (you can also find the most relevant fragment of the log in the bug report): http://scaaa637.us.oracle.com//archive/2016/05/2016-05-08-100525.sspitsyn.8153711//logs/solaris_x64_5.11-fastdebug-c2-jdk_svc_sanity.log Please, find the email notification in the attachment. Thanks, Serguei On 5/8/16 00:59, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > I filed two new bugs to cover the discovered issues: > 8156498: more places in the invoke.c that need protection with the > invokerLock > 8156500: deadlock provoked by new stress test > com/sun/jdi/OomDebugTest.java > > > Will try to push your two fixes today or tomorrow. > I know, you've just got a committer status. > But I'm not sure you are comfortable to push the fixes yourself at > this time. > > Thanks, > Serguei > > > > On 5/3/16 03:21, serguei.spitsyn at oracle.com wrote: >> Hi Severin, >> >> Please, find my comments below. >> >> >> On 5/2/16 01:44, Severin Gehwolf wrote: >>> On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote: >>>> On 4/29/16 01:56, Severin Gehwolf wrote: >>>>> Hi Serguei, >>>>> >>>>> On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Severin, >>>>>> >>>>>> The fix looks good in general. >>>>>> I'm testing both fixes together at the moment. >>>>> That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. >>>>> >>>>>> A couple of questions... >>>>>> >>>>>> It seems, there are more places where an invokerLock critical >>>>>> section is missed. >>>>> Right. >>>>> >>>>>> The following functions: >>>>>> - invoker_enableInvokeRequests >>>>> This should be fixed with the patch for JDK-8154529 >>>>> >>>>>> - invokeConstructor >>>>>> - invokeStatic >>>>>> - invokeNonvirtual >>>>>> - invokeVirtual >>>>>> - saveGlobalRef >>>>> Correct. The intent would be to fix the callsites of >>>>> saveGlobalRef. If >>>>> we fix invoke* then saveGlobalRef should not be an issue. I didn't >>>>> want >>>>> to include this in this fix since it's pretty hairy and would like to >>>>> fix this in incremental steps. >>>>> >>>>>> The first function is easy to fix. >>>>>> The last 5 functions are called from the invoker_doInvoke() that >>>>>> we already had a problem with. >>>>>> I'm puzzled with the question: How to synchronize and avoid >>>>>> deadlocks at the same time? >>>>> I'm not sure yet. Perhaps locking only while saveGlobalRef is being >>>>> called in invoke* functions will help. >>>>> >>>>>> I'm inclined to let your fix go (if the testing is Ok) and file >>>>>> one more bug on the remaining sync issues. >>>>> Please keep me in the loop about your test results. >>>> Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are >>>> all passed. >>>> >>>> I also ran the 4 previously failed tests in big loops of 1000 runs: >>>> com/sun/jdi/InvokeTest.java >>>> com/sun/jdi/InvokeHangTest.java >>>> com/sun/jdi/InterfaceMethodsTest.java >>>> com/sun/jdi/OomDebugTest.java (new test introduced in the >>>> webrev) >>> I suggest to run InvokeTest, InvokeHangTest and InterfaceMethodsTest in >>> a loop. Those never failed for me in such a scenario. >>> >>>> The OomDebugTest.java failed with a timeout (most likely, a deadlock). >>>> Please, find the OomDebugTest.jtr file in attachments. >>> Correct. This is what I was seeing. See the last comment of the bug: >>> https://bugs.openjdk.java.net/browse/JDK-8153711 >> >> Need to check if it is the same as I'm seeing. >> >>> >>> It has the jstack output of the hung OomDebugTestTarg JVM. I'm not >>> convinced this is the same failure we were seeing in JDK-4858370 since >>> the stack suggests it's doing a GC upon a newInstance of a primitive >>> array. It also does not seem like the same issue as the deadlocks >>> exposed by locking during an invoke, because it was reproducible fairly >>> consistently with InvokeHangTest. >> >> Agreed. >> >> >>> >>> It looks to me like a new issue. Probably one which was there before, >>> but is only exposed by the new test. The new test stress-tests the GC >>> with a debugger attached. Of course, this is going to be hard to prove >>> since it would just run out of memory prior the patch. >> >> Thanks. >> Your analysis seems to be reasonable. >> I tend to agree with it but need more time to convince myself. >> >> >>> Thoughts? >> >> Let me double check the above. >> If the analysis is correct then I'd suggest to file new bug and push >> your fix as is. >> >> >> Thanks, >> Serguei >> >> >>> >>> Cheers, >>> Severin >>> >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>>> Thanks for your help! >>>>> >>>>> Cheers, >>>>> Severin >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 4/28/16 02:00, Severin Gehwolf wrote: >>>>>>> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>>>> Hi Severin, >>>>>>>>> >>>>>>>>> I postpone a push for this fix. >>>>>>>>> >>>>>>>>> There are two nsk.jdi test failures (they look like deadlocks): >>>>>>>>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 >>>>>>>>> FAIL(TIMEOUT) >>>>>>>>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>>>>>>>> >>>>>>>>> and one jtreg sun/com/jdi failure (it looks like a deadlock too): >>>>>>>>> com/sun/jdi/InvokeHangTes.java >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll double check if these failures are regressions caused by >>>>>>>>> your fix >>>>>>>>> or not. >>>>>>>> I confirm, the failures above are new regressions introduced by >>>>>>>> the fix. >>>>>>>> The tests fail consistently with the fix and do not fail >>>>>>>> without the fix. >>>>>>> OK this was caused by the locking done in invoker_doInvoke(). >>>>>>> Note that >>>>>>> holding either of them invoker lock or event handler lock causes >>>>>>> this. >>>>>>> >>>>>>> Here is a new webrev with those hunks removed. It's sufficient >>>>>>> to grab >>>>>>> the locks again in invoke_completeInvokeRequest() when clearing the >>>>>>> global references in order to not get those failures we've seen >>>>>>> when >>>>>>> the fix for JDK-4858370 was in place. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ >>>>>>> >>>>>>> Testing done: >>>>>>> - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and >>>>>>> sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. >>>>>>> - regular com/sun/jdi test set: no regressions >>>>>>> >>>>>>> Note that there are some rare cases where OomDebugTest times out >>>>>>> which >>>>>>> seems to be caused by the GC, though. See the bug for details. >>>>>>> Since >>>>>>> this problem is rare, it's still worthwhile having that test >>>>>>> included. >>>>>>> If it turns out a problem in practice we could consider >>>>>>> disabling the >>>>>>> test. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Cheers, >>>>>>> Severin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: jprt_admin_ww_grp at oracle.com Subject: JPRT: [west] job notification - FAILED with job 2016-05-08-100525.sspitsyn.8153711 Date: Sun, 8 May 2016 10:33:29 GMT Size: 83229 URL: From Alan.Bateman at oracle.com Sun May 8 14:48:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 May 2016 15:48:22 +0100 Subject: RFR(M): v.05, 8155091: Remove SA related functions from tmtools In-Reply-To: <572C99C3.70206@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> <572C99C3.70206@oracle.com> Message-ID: <572F51B6.4030903@oracle.com> On 06/05/2016 14:18, Dmitry Samersoff wrote: > Everybody, > > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Removed ToolProvider interface. run(String ... args) function removed or > renamed to runWithArgs. > > Fixed two more tests, missed on previous iteration. > Updated webrev looks good. Minor nit in checkForUnsupportedOptions is that a space are crept into a few of the `if` statements, e.g. "if (! s.matches("[0-9]+"))" and "if (! s.startsWith("-"))" -Alan From david.holmes at oracle.com Mon May 9 00:08:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 May 2016 10:08:22 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <572CD6BA.9030606@oracle.com> References: <945c461a-5c5f-4789-ac9e-93c34a7ba014@default> <572CD6BA.9030606@oracle.com> Message-ID: <22a00aa4-36e6-ca13-daf6-99eb0fddb435@oracle.com> Hi Kirill, On 7/05/2016 3:39 AM, Kirill Zhaldybin wrote: > Alexander, > > Thank you for reviewing the fix. > > On 06.05.2016 20:24, Alexander Kulyakhtin wrote: >> Is there a specification of what shall be thrown, or the justification >> of the changes done? >> One can think that the currently thrown NoSuchMethodException is >> correct since?methods, which differ in signature only, are still >> different methods. > I spent some time trying to figure out why I got NoSuchMethodException > for "help" despite such method actually existed. > > If you think that to throw NoSuchMethodException is better for wrong > signature I could just change error message in this case. The code doesn't really seem to be checking any detail of the "signature" as such, simply that the passed in "signature" array has a non-null zeroeth element of type String[]. Passing something else seems like a bad call to me and so IllegalArgumentException would be appropriate I think. But the logic of that entire block is suspect to me as it does not handle the case where isEmpty() is true, but we pass in non-null params and signature anyway. Aside: I'm not even convinced that NoSuchMethodException is appropriate for the case where "actionname" doesn't exist. But that is a different issue. Thanks, David > Could you please let me know your opinion? > > Thank you. > > Regards, Kirill > >> >> Best regards, >> Alexander >> >> >> ----- Original Message ----- >> From: kirill.zhaldybin at oracle.com >> To: serviceability-dev at openjdk.java.net >> Sent: Friday, May 6, 2016 8:11:08 PM GMT +03:00 Iraq >> Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws >> NoSuchMethodException even if the method actually exists but >> parameters are wrong >> >> Dear all, >> >> Could you please review this small fix for 8156226? >> >> A case when a method exists but parameters' signature is wrong now >> causes new ReflectionException(new IllegalArgumentException()) thrown >> instead of new ReflectionException(new NoSuchMethodException()). >> >> WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.00/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8156226 >> >> Thank you. >> >> Regards, Kirill >> > From serguei.spitsyn at oracle.com Mon May 9 00:25:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 8 May 2016 17:25:47 -0700 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <572F1BE4.8010207@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> <1462178693.5579.18.camel@redhat.com> <57287B9C.8060907@oracle.com> <572EF1D7.4030504@oracle.com> <572F1BE4.8010207@oracle.com> Message-ID: <572FD90B.9090907@oracle.com> On 5/8/16 03:58, serguei.spitsyn at oracle.com wrote: > Severin, > > The JPRT job failed: 2016-05-08-100525.sspitsyn.8153711 with a > NullPointerException. > The log link is (you can also find the most relevant fragment of the > log in the bug report): > http://scaaa637.us.oracle.com//archive/2016/05/2016-05-08-100525.sspitsyn.8153711//logs/solaris_x64_5.11-fastdebug-c2-jdk_svc_sanity.log Sorry for providing the link that is not accessible for you. But, please, find a fragment of the failure log in my bug report comment. Thanks, Serguei > > Please, find the email notification in the attachment. > > Thanks, > Serguei > > > On 5/8/16 00:59, serguei.spitsyn at oracle.com wrote: >> Hi Severin, >> >> I filed two new bugs to cover the discovered issues: >> 8156498: more places in the invoke.c that need protection with the >> invokerLock >> 8156500: deadlock provoked by new stress test >> com/sun/jdi/OomDebugTest.java >> >> >> Will try to push your two fixes today or tomorrow. >> I know, you've just got a committer status. >> But I'm not sure you are comfortable to push the fixes yourself at >> this time. >> >> Thanks, >> Serguei >> >> >> >> On 5/3/16 03:21, serguei.spitsyn at oracle.com wrote: >>> Hi Severin, >>> >>> Please, find my comments below. >>> >>> >>> On 5/2/16 01:44, Severin Gehwolf wrote: >>>> On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote: >>>>> On 4/29/16 01:56, Severin Gehwolf wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> The fix looks good in general. >>>>>>> I'm testing both fixes together at the moment. >>>>>> That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too. >>>>>> >>>>>>> A couple of questions... >>>>>>> >>>>>>> It seems, there are more places where an invokerLock critical >>>>>>> section is missed. >>>>>> Right. >>>>>> >>>>>>> The following functions: >>>>>>> - invoker_enableInvokeRequests >>>>>> This should be fixed with the patch for JDK-8154529 >>>>>> >>>>>>> - invokeConstructor >>>>>>> - invokeStatic >>>>>>> - invokeNonvirtual >>>>>>> - invokeVirtual >>>>>>> - saveGlobalRef >>>>>> Correct. The intent would be to fix the callsites of >>>>>> saveGlobalRef. If >>>>>> we fix invoke* then saveGlobalRef should not be an issue. I >>>>>> didn't want >>>>>> to include this in this fix since it's pretty hairy and would >>>>>> like to >>>>>> fix this in incremental steps. >>>>>> >>>>>>> The first function is easy to fix. >>>>>>> The last 5 functions are called from the invoker_doInvoke() that >>>>>>> we already had a problem with. >>>>>>> I'm puzzled with the question: How to synchronize and avoid >>>>>>> deadlocks at the same time? >>>>>> I'm not sure yet. Perhaps locking only while saveGlobalRef is being >>>>>> called in invoke* functions will help. >>>>>> >>>>>>> I'm inclined to let your fix go (if the testing is Ok) and file >>>>>>> one more bug on the remaining sync issues. >>>>>> Please keep me in the loop about your test results. >>>>> Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are >>>>> all passed. >>>>> >>>>> I also ran the 4 previously failed tests in big loops of 1000 runs: >>>>> com/sun/jdi/InvokeTest.java >>>>> com/sun/jdi/InvokeHangTest.java >>>>> com/sun/jdi/InterfaceMethodsTest.java >>>>> com/sun/jdi/OomDebugTest.java (new test introduced in the >>>>> webrev) >>>> I suggest to run InvokeTest, InvokeHangTest and >>>> InterfaceMethodsTest in >>>> a loop. Those never failed for me in such a scenario. >>>> >>>>> The OomDebugTest.java failed with a timeout (most likely, a >>>>> deadlock). >>>>> Please, find the OomDebugTest.jtr file in attachments. >>>> Correct. This is what I was seeing. See the last comment of the bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8153711 >>> >>> Need to check if it is the same as I'm seeing. >>> >>>> >>>> It has the jstack output of the hung OomDebugTestTarg JVM. I'm not >>>> convinced this is the same failure we were seeing in JDK-4858370 since >>>> the stack suggests it's doing a GC upon a newInstance of a primitive >>>> array. It also does not seem like the same issue as the deadlocks >>>> exposed by locking during an invoke, because it was reproducible >>>> fairly >>>> consistently with InvokeHangTest. >>> >>> Agreed. >>> >>> >>>> >>>> It looks to me like a new issue. Probably one which was there before, >>>> but is only exposed by the new test. The new test stress-tests the GC >>>> with a debugger attached. Of course, this is going to be hard to prove >>>> since it would just run out of memory prior the patch. >>> >>> Thanks. >>> Your analysis seems to be reasonable. >>> I tend to agree with it but need more time to convince myself. >>> >>> >>>> Thoughts? >>> >>> Let me double check the above. >>> If the analysis is correct then I'd suggest to file new bug and push >>> your fix as is. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Cheers, >>>> Severin >>>> >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>>> Thanks for your help! >>>>>> >>>>>> Cheers, >>>>>> Severin >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 4/28/16 02:00, Severin Gehwolf wrote: >>>>>>>> On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com >>>>>>>> wrote: >>>>>>>>>> Hi Severin, >>>>>>>>>> >>>>>>>>>> I postpone a push for this fix. >>>>>>>>>> >>>>>>>>>> There are two nsk.jdi test failures (they look like deadlocks): >>>>>>>>>> nsk/jdi/ObjectReference/invokeMethod/invokemethod012 >>>>>>>>>> FAIL(TIMEOUT) >>>>>>>>>> nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT) >>>>>>>>>> >>>>>>>>>> and one jtreg sun/com/jdi failure (it looks like a deadlock >>>>>>>>>> too): >>>>>>>>>> com/sun/jdi/InvokeHangTes.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll double check if these failures are regressions caused by >>>>>>>>>> your fix >>>>>>>>>> or not. >>>>>>>>> I confirm, the failures above are new regressions introduced >>>>>>>>> by the fix. >>>>>>>>> The tests fail consistently with the fix and do not fail >>>>>>>>> without the fix. >>>>>>>> OK this was caused by the locking done in invoker_doInvoke(). >>>>>>>> Note that >>>>>>>> holding either of them invoker lock or event handler lock >>>>>>>> causes this. >>>>>>>> >>>>>>>> Here is a new webrev with those hunks removed. It's sufficient >>>>>>>> to grab >>>>>>>> the locks again in invoke_completeInvokeRequest() when clearing >>>>>>>> the >>>>>>>> global references in order to not get those failures we've seen >>>>>>>> when >>>>>>>> the fix for JDK-4858370 was in place. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/ >>>>>>>> >>>>>>>> >>>>>>>> Testing done: >>>>>>>> - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java >>>>>>>> and >>>>>>>> sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs. >>>>>>>> - regular com/sun/jdi test set: no regressions >>>>>>>> >>>>>>>> Note that there are some rare cases where OomDebugTest times >>>>>>>> out which >>>>>>>> seems to be caused by the GC, though. See the bug for details. >>>>>>>> Since >>>>>>>> this problem is rare, it's still worthwhile having that test >>>>>>>> included. >>>>>>>> If it turns out a problem in practice we could consider >>>>>>>> disabling the >>>>>>>> test. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Severin >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon May 9 00:34:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 May 2016 10:34:14 +1000 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> <5a649768-a418-157a-eec5-234bb6cd14dc@oracle.com> Message-ID: <81b81513-3f06-a009-fc38-b556c536ed71@oracle.com> On 7/05/2016 2:28 AM, Robbin Ehn wrote: > Hi David, > > On 05/06/2016 03:58 PM, David Holmes wrote: >> On 6/05/2016 5:12 PM, Robbin Ehn wrote: >>> Hi David, thanks for taking the time looking at this! >>> >>> On 05/06/2016 07:20 AM, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> Please see comments far below regarding mapping ... >>>> >>>> On 4/05/2016 5:25 AM, Robbin Ehn wrote: >>>>> Hi all, >>>>> >>>>> Please review this. >>>>> >>>>> This changeset moves redefine classes tracing to UL. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 >>>>> Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> >>>> I wonder whether the RC timers can be better integrated as was done >>>> with >>>> other use of timers with logging? A scope-based Timer class would fix >>>> the problem of conditionally starting timers, but unconditionally >>>> stopping them. >>> >>> Since I saw no harm in calling elapsedTimer.stop() so I did it this way. >>> >>> Let me know you you want me to do scoped instead. (one of the scopes are >>> really bid) >> >> You'd need to look at the other UL connected timers. I can't recall them >> off the top of my head. :) >> > > UL TraceTimer log directly when it go out of scope, here we don't. > We summarize the 3 timers in 2 log lines. > > So it's just matter of scoped, and as I said one scope is 220 lines, so > I prefer the way it is, if you don't mind? > > (or are you suggesting enhancements to TraceTime?) I was just suggesting to look at how timers already interact with UL and whether that could work here. If simple enhancements to TraceTime were needed to achieve that, that is okay. If they turn out to be completely incompatible then so be it. > >>>> >>>>> Passes testsuits >>>>> jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist >>>>> >>>>> >>>>> >>>>> >>>>> with: >>>>> -Xlog:redefine+class*=trace >>>>> (a few test won't run with extra options) >>>>> >>>>> -XX:TraceRedefineClasses=xyz turns on (aliased with) >>>>> "-Xlog:redefine+class*=info" and emits a warning. >>>>> (xyz is ignored) >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >>>>> >>>>> Example of useage: >>>>> -Xlog:redefine+class+constantpool*=debug >>>>> -Xlog:redefine+class+load=info >>>>> -Xlog:redefine+class*=debug,redefine+class+iklass*=trace >>>>> >>>>> Here is an example from a test: >>>>> >>>>> [20.279s][debug][redefine,class,update,vtables ] vtable method >>>>> update: getOptions(()Ljava/util/Properties;), updated default = false >>>>> [20.279s][debug][redefine,class,subclass ] updated count in >>>>> subclass=nsk.share.jvmti.ArgumentHandler to 197 >>>>> [20.279s][info ][redefine,class,load ] redefined >>>>> name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) >>>>> [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, >>>>> obsolete_cnt=0 >>>>> [20.285s][trace][redefine,class,iklass,add ] adding previous >>>>> version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 >>>>> [20.285s][trace][redefine,class,iklass,add ] scratch class not >>>>> added; no methods are running >>>>> [20.285s][info ][redefine,class,update ] adjust: >>>>> name=nsk.share.jvmti.ArgumentHandler >>>>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>>>> getAgentOptionsString(()Ljava/lang/String;) >>>>> [20.285s][info ][redefine,class,update ] adjust: >>>>> name=nsk.share.jvmti.ArgumentHandler >>>>> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: >>>>> (([Ljava/lang/String;)V) >>>>> [20.285s][info ][redefine,class,load ] redefined >>>>> name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) >>>>> [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>>>> obsolete_cnt=0 >>>>> [20.291s][trace][redefine,class,iklass,add ] adding previous >>>>> version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 >>>>> [20.291s][trace][redefine,class,iklass,add ] scratch class not >>>>> added; no methods are running >>>>> [20.291s][info ][redefine,class,update ] adjust: >>>>> name=nsk.share.jvmti.JVMTITest >>>>> [20.291s][debug][redefine,class,update,constantpool] cpc entry update: >>>>> commonInit(([Ljava/lang/String;)[Ljava/lang/String;) >>>>> [20.291s][info ][redefine,class,load ] redefined >>>>> name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) >>>>> [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, >>>>> obsolete_cnt=0 >>>>> [20.297s][trace][redefine,class,iklass,add ] adding previous >>>>> version ref for nsk.share.TestBug, EMCP_cnt=3 >>>>> >>>>> Mapping: >>>> >>>> Very unclear how you selected info/debug/trace for each of these. Given >>> >>> I have select them after verbosity (looking at distribution after tests >>> runs) and granularity. But sure it is a bit arbitrary. >>> >>>> they use different tag sets they could really all be "info" for their >>>> set. >>> >>> They use different level due for the use-case: >>> >>> Enable info for all tagset containing the two tags redefine+class >>> -Xlog:redefine+class*=info >>> >>> Also enable debug for constantpool >>> -Xlog:redefine+class*=info,redefine+class+constantpool=debug >>> >>> Also enable trace for all updates >>> -Xlog:redefine+class*=info,redefine+class+constantpool=debug,redefine+class+update*=trace >>> >>> >> >> That seems somewhat of a self-justifying definition. Where did those >> usecases come from? You seem to have decided that >> redefine+class+constantpool is less important than other >> redefine+class+XXX, and you've decided to use a wildcard which means you >> need a way to disable redefine+class+constantpool and so you drop it to >> debug instead of info. > > This was just a random example. > If constantpool was on info I would of course not enable > redefine+class*=info but instead use > redefine+class+XXX,redefine+class+YYY,redefine+class+ZZZ, until happy! > > 0x00010000-0x00080000 looked to me it would make more sense to put them > in same tag-set but with different level. But we can of course have them > on same level but different tag. > >> >> Many of our decisions seem to be driven by the perceived desire to use >> wildcards in a specific way. :( > > No, just that certain logs have more in common than others, e.g. is > about constantpool. And enabling all logs with that information seemed > like a valid use-case. > (which happens to enable us to use wildcards for a few scenarios) > >> >>> >>>> >>>>> RC_TRACE_MESG = "redefine, class, update" - info >>>>> >>>>> 0x00000001 = "redefine, class, load" - info >>>>> 0x00000001 = "redefine, class, load" - debug >>>>> >>>>> 0x00000002 = "redefine, class, load, exceptions" - info >>>>> 0x00000004 = "redefine, class, timer" - info >>>>> 0x00000008 = "redefine, class, subclass" - debug >>>>> >>>>> 0x00000100 = "redefine, class, obsolete, mark" - trace >>>>> 0x00000200 = "redefine, class, iklass, purge" - trace >>>>> 0x00000400 = "redefine, class, iklass, add" - trace >>>>> 0x00000800 = "redefine, class, breakpoint" - debug >>>>> >>>>> 0x00001000->0x00002000 = "redefine, class, obsolete" - trace >>>>> 0x00001000 = "redefine, class, obsolete" - trace >>>>> 0x00002000 = REMOVED >>>> >>>> I'm a little unclear about how the old ranges were supposed to work, >>>> but >>>> you have effectively removed them as far as I can see. A range of >>>> 1000->2000 would print out when "redefine, class, obsolete" was >>>> specified in conjunction with any, or all, or the preceding >>>> conditions - >>>> but now it will print only on that one condition. >>>> >>>> You also removed the debugging hooks related to this ie in >>>> sharedRuntime.cpp: >>>> >>>> - if (RC_TRACE_ENABLED(0x00002000)) { >>>> - // this option is provided to debug calls to obsolete methods >>>> - guarantee(false, "faulting at call to an obsolete method."); >>>> - } >>>> >>> >>> Yes 0x00002000 was removed, because we can't have "class*=trace" >>> enabling a guarantee. >> >> Perhaps not but that functionality for debugging has still been lost. > > As I said, intentionally. That isn't a justification. But if Coleen is okay with losing it so be it. >> >>> In the old code if either of those two bits were set it evaluated true. >>> (regardless off other bits) >> >> Not sure I follow that statement. >> >>> Since I removed one bit, this is a boolean and was translated to: >>> is "redefine, class, obsolete" enabled or not. >> >> No it (the TRACE_RANGE) isn't a boolean it is 0x00001000 to 0x00001FFF. >> The ranges provided a way of combining tracing levels in a simple way >> that is very cumbersome with UL tagging. Essentially a TRACE_RANGE(from, >> to, "xxx") would have to be written as: >> >> if (log_is_enabled(A, info) || >> log_is_enabled(B, info) || >> ... { >> log("xxx"); >> } >> >> for all A, B, C covered by the range. > > That might have been the original intention. > It evaluate to true as long as any bit between low and high are set. > E.g. in above 0x01001000 also is in range. Yes - exactly. Not sure where we are getting crossed-lines here. There are a number of 'levels' for RC tracing defined as powers-of-2 that can be comined in a bit-mask. The range-trace macro allows you print out info if ANY of them are set. So previously we had a line that would be printed under numerous tracing conditions, and now it is only printed under a single UL condition. > > ((bits & ((high << 1) - 1)) masks away high bits > and & ~(low - 1)) masks away low bits > > > This is also logical when reading the code, e.g. why should > "impl details: OopMapCache updates" stop > "detect calls to obsolete methods" ? > > So RC_TRACE_TIME(somevalue, 0x00001000, 0x00001000) is the same as > somevalue&0x00001000, correct? > > But never the less, yes there are some drawbacks using UL. > My hope and intention was that we could live with it. I don't understand the motivation here. AFAIK noone ever said we must convert every single use of tty->print_cr into use of the UL framework instead. The RC_TRACE stuff does not seem like a good match for UL, so why not simply leave it as-is instead of putting in a subset of it that works with UL ? Thanks, David ----- > Thanks! > > /Robbin > >> >> Cheers, >> David >> >>> Thanks! >>> >>> /Robbin >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> 0x00004000 = "redefine, class, obsolete, metadata" - trace >>>>> 0x00004000 = "redefine, class, dump" - trace >>>>> >>>>> 0x00008000 = "redefine, class, normalize" - trace >>>>> >>>>> 0x00010000 = "redefine, class, constantpool" - info >>>>> 0x00020000 = "redefine, class, constantpool" - debug >>>>> 0x00040000 = "redefine, class, constantpool" - trace >>>>> 0x00080000 = "redefine, class, constantpool" - trace >>>>> >>>>> 0x00100000-0x00400000 = "redefine, class, update" - info >>>>> 0x00100000 = "redefine, class, update, vtables" - debug >>>>> 0x00200000 = "redefine, class, update, itables" - debug >>>>> 0x00400000 = "redefine, class, update, constantpool" - debug >>>>> >>>>> 0x00800000 = "redefine, class, methodcomparator" - debug >>>>> >>>>> 0x01000000 = "redefine, class, nmethod" - debug >>>>> 0x02000000 = "redefine, class, annotation" - debug >>>>> 0x04000000 = "redefine, class, stackmap" - debug >>>>> 0x08000000 = "redefine, class, oopmap" - debug >>>>> From staffan.larsen at oracle.com Mon May 9 06:08:52 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 May 2016 08:08:52 +0200 Subject: RFR(M): v.05, 8155091: Remove SA related functions from tmtools In-Reply-To: <572C99C3.70206@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> <572C99C3.70206@oracle.com> Message-ID: <4568D847-AEBE-4C37-9E74-99952554A001@oracle.com> Looks good! Thanks, /Staffan > On 6 maj 2016, at 15:18, Dmitry Samersoff wrote: > > Everybody, > > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Removed ToolProvider interface. run(String ... args) function removed or > renamed to runWithArgs. > > Fixed two more tests, missed on previous iteration. > > -Dmitry > > > On 2016-05-05 22:48, Mandy Chung wrote: >> >>> On May 5, 2016, at 5:51 AM, Dmitry Samersoff wrote: >>> >>> Please, see updated webrev. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.04/ >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/ToolProvider.java >> I suggest to remove this as jdk.hotspot.agent is no longer a provider. You could keep the getName and run methods and just remove @Override annotation. >> >> I only skimmed on the jdk change. >> >> test/sun/tools/jinfo/BasicJInfoTest.java >> It has @bug 6260070 (an old bug). Is it renamed from an existing test? OR just cut-n-paste error. >> >> 35 * @modules java.management >> >> Is this still needed? >> >> test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java and other jhsdb tests >> should have @modules jdk.hotspot.agent >> >> Mandy >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sgehwolf at redhat.com Mon May 9 07:21:34 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 09 May 2016 09:21:34 +0200 Subject: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <572FD90B.9090907@oracle.com> References: <1460739233.4653.25.camel@redhat.com> <57113A16.2010909@oracle.com> <57115485.6090305@oracle.com> <5715ED4E.3080501@oracle.com> <1461057408.4555.6.camel@redhat.com> <5715F8D0.6030200@oracle.com> <5716E437.9030405@oracle.com> <5716EA4D.2030401@oracle.com> <1461834056.25448.18.camel@redhat.com> <57231C8A.3050406@oracle.com> <1461920166.3712.19.camel@redhat.com> <5723B714.7000503@oracle.com> <1462178693.5579.18.camel@redhat.com> <57287B9C.8060907@oracle.com> <572EF1D7.4030504@oracle.com> <572F1BE4.8010207@oracle.com> <572FD90B.9090907@oracle.com> Message-ID: <1462778494.8107.1.camel@redhat.com> Serguei, On Sun, 2016-05-08 at 17:25 -0700, serguei.spitsyn at oracle.com wrote: > On 5/8/16 03:58, serguei.spitsyn at oracle.com wrote: > > Severin, > > > > The JPRT job failed: 2016-05-08-100525.sspitsyn.8153711 with a NullPointerException. > > The log link is (you can also find the most relevant fragment of the log in the bug report): > > ? http://scaaa637.us.oracle.com//archive/2016/05/2016-05-08-100525.sspitsyn.8153711//logs/solaris_x64_5.11-fastdebug-c2-jdk_svc_sanity.log > ? > Sorry for providing the link that is not accessible for you. > But, please, find a fragment of the failure log in my bug report comment.? Thanks for your help. Time for me to find a Solaris box and try to reproduce. Cheers, Severin > > Thanks, > Serguei > > > > > Please, find the email notification in the attachment. > > > > Thanks, > > Serguei > > > > > > On 5/8/16 00:59, serguei.spitsyn at oracle.com wrote: > > > Hi Severin, > > > > > > I filed two new bugs to cover the discovered issues: > > > ? ? ?8156498: more places in the invoke.c that need protection with the invokerLock > > > ???? 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java > > > > > > > > > Will try to push your two fixes today or tomorrow. > > > I know, you've just got a committer status. > > > But I'm not sure you are comfortable to push the fixes yourself at this time. > > > > > > Thanks, > > > Serguei > > > > > > > > > > > > On 5/3/16 03:21, serguei.spitsyn at oracle.com wrote: > > > > Hi Severin,? > > > > > > > > Please, find my comments below.? > > > > > > > > > > > > On 5/2/16 01:44, Severin Gehwolf wrote:? > > > > > On Fri, 2016-04-29 at 12:33 -0700, serguei.spitsyn at oracle.com wrote:? > > > > > > On 4/29/16 01:56, Severin Gehwolf wrote:? > > > > > > > Hi Serguei,? > > > > > > > > > > > > > > On Fri, 2016-04-29 at 01:34 -0700, serguei.spitsyn at oracle.com wrote:? > > > > > > > > Hi Severin,? > > > > > > > > > > > > > > > > The fix looks good in general.? > > > > > > > > I'm testing both fixes together at the moment.? > > > > > > > ?That is JDK-8154529 and JDK-8153711? Yes, that's what I've done too.? > > > > > > > > A couple of questions...? > > > > > > > > > > > > > > > > It seems, there are more places where an invokerLock critical section is missed.? > > > > > > > ?Right.? > > > > > > > > The following functions:? > > > > > > > > ?? - invoker_enableInvokeRequests? > > > > > > > ?This should be fixed with the patch for JDK-8154529? > > > > > > > > ?? - invokeConstructor? > > > > > > > > ?? - invokeStatic? > > > > > > > > ?? - invokeNonvirtual? > > > > > > > > ?? - invokeVirtual? > > > > > > > > ?? - saveGlobalRef? > > > > > > > ?Correct. The intent would be to fix the callsites of saveGlobalRef. If? > > > > > > > we fix invoke* then saveGlobalRef should not be an issue. I didn't want? > > > > > > > to include this in this fix since it's pretty hairy and would like to? > > > > > > > fix this in incremental steps.? > > > > > > > > > > > > > > > The first function is easy to fix.? > > > > > > > > The last 5 functions are called from the invoker_doInvoke() that we already had a problem with.? > > > > > > > > I'm puzzled with the question: How to synchronize and avoid deadlocks at the same time?? > > > > > > > ?I'm not sure yet. Perhaps locking only while saveGlobalRef is being? > > > > > > > called in invoke* functions will help.? > > > > > > > > > > > > > > > I'm inclined to let your fix go (if the testing is Ok) and file one more bug on the remaining sync issues.? > > > > > > > ?Please keep me in the loop about your test results.? > > > > > > ?? Both the JTreg com/sun/jdi and the co-located nsk.jdi tests are all passed.? > > > > > > I also ran the 4 previously failed tests in big loops of 1000 runs:? > > > > > > ???? com/sun/jdi/InvokeTest.java? > > > > > > ???? com/sun/jdi/InvokeHangTest.java? > > > > > > ???? com/sun/jdi/InterfaceMethodsTest.java? > > > > > > ???? com/sun/jdi/OomDebugTest.java? (new test introduced in the webrev)? > > > > > ?I suggest to run InvokeTest, InvokeHangTest and InterfaceMethodsTest in? > > > > > a loop. Those never failed for me in such a scenario.? > > > > > > > > > > > The OomDebugTest.java failed with a timeout (most likely, a deadlock).? > > > > > > Please, find the OomDebugTest.jtr file in attachments.? > > > > > ?Correct. This is what I was seeing. See the last comment of the bug:? > > > > > https://bugs.openjdk.java.net/browse/JDK-8153711? > > > > ? > > > > Need to check if it is the same as I'm seeing.? > > > > > > > > > > > > > > It has the jstack output of the hung OomDebugTestTarg JVM. I'm not? > > > > > convinced this is the same failure we were seeing in JDK-4858370 since? > > > > > the stack suggests it's doing a GC upon a newInstance of a primitive? > > > > > array. It also does not seem like the same issue as the deadlocks? > > > > > exposed by locking during an invoke, because it was reproducible fairly? > > > > > consistently with InvokeHangTest.? > > > > ? > > > > Agreed.? > > > > > > > > > > > > > > > > > > It looks to me like a new issue. Probably one which was there before,? > > > > > but is only exposed by the new test. The new test stress-tests the GC? > > > > > with a debugger attached. Of course, this is going to be hard to prove? > > > > > since it would just run out of memory prior the patch.? > > > > ? > > > > Thanks.? > > > > Your analysis seems to be reasonable.? > > > > I tend to agree with it but need more time to convince myself.? > > > > > > > > > > > > > ? Thoughts?? > > > > ? > > > > Let me double check the above.? > > > > If the analysis is correct then I'd suggest to file new bug and push your fix as is.? > > > > > > > > > > > > Thanks,? > > > > Serguei? > > > > > > > > > > > > > > > > > > Cheers,? > > > > > Severin? > > > > > > > > > > > > > > > > > > > > > Thanks,? > > > > > > Serguei? > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your help!? > > > > > > > > > > > > > > Cheers,? > > > > > > > Severin? > > > > > > > > > > > > > > > Thanks,? > > > > > > > > Serguei? > > > > > > > > > > > > > > > > > > > > > > > > On 4/28/16 02:00, Severin Gehwolf wrote:? > > > > > > > > > On Tue, 2016-04-19 at 19:32 -0700, serguei.spitsyn at oracle.com wrote:? > > > > > > > > > > > Hi Severin,? > > > > > > > > > > > > > > > > > > > > > > I postpone a push for this fix.? > > > > > > > > > > > > > > > > > > > > > > There are two nsk.jdi test failures (they look like deadlocks):? > > > > > > > > > > > ?? nsk/jdi/ObjectReference/invokeMethod/invokemethod012 FAIL(TIMEOUT)? > > > > > > > > > > > ?? nsk/jdi/Scenarios/invokeMethod/popframes001 FAIL(TIMEOUT)? > > > > > > > > > > > > > > > > > > > > > > and one jtreg sun/com/jdi failure (it looks like a deadlock too):? > > > > > > > > > > > ?? com/sun/jdi/InvokeHangTes.java? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll double check if these failures are regressions caused by your fix? > > > > > > > > > > > or not.? > > > > > > > > > > ?I confirm, the failures above are new regressions introduced by the fix.? > > > > > > > > > > The tests fail consistently with the fix and do not fail without the fix.? > > > > > > > > > ?OK this was caused by the locking done in invoker_doInvoke(). Note that? > > > > > > > > > holding either of them invoker lock or event handler lock causes this.? > > > > > > > > > > > > > > > > > > Here is a new webrev with those hunks removed. It's sufficient to grab? > > > > > > > > > the locks again in invoke_completeInvokeRequest() when clearing the? > > > > > > > > > global references in order to not get those failures we've seen when? > > > > > > > > > the fix for JDK-4858370 was in place.? > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153711/webrev.02/? > > > > > > > > > > > > > > > > > > Testing done:? > > > > > > > > > ? - com/sun/jdi/InvokeTest.java com/sun/jdi/InvokeHangTest.java and? > > > > > > > > > ??? sun/jdi/InterfaceMethodsTest.java does not fail in 1500 runs.? > > > > > > > > > ? - regular com/sun/jdi test set: no regressions? > > > > > > > > > > > > > > > > > > Note that there are some rare cases where OomDebugTest times out which? > > > > > > > > > seems to be caused by the GC, though. See the bug for details. Since? > > > > > > > > > this problem is rare, it's still worthwhile having that test included.? > > > > > > > > > If it turns out a problem in practice we could consider disabling the? > > > > > > > > > test.? > > > > > > > > > > > > > > > > > > Thoughts?? > > > > > > > > > > > > > > > > > > Cheers,? > > > > > > > > > Severin? > > > > > > > > ?? > > > > > > ?? > > > > ? > > > ? > > ? > ? From robbin.ehn at oracle.com Mon May 9 11:25:46 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 9 May 2016 13:25:46 +0200 Subject: RFR: 8153535: Convert TraceRedefineClasses to Unified Logging In-Reply-To: <4468948b-4c47-c5d3-9d65-3987632087da@oracle.com> References: <23a2328b-c878-cda7-48e5-8f16f74d80e9@oracle.com> <4468948b-4c47-c5d3-9d65-3987632087da@oracle.com> Message-ID: Hi Coleen, Thanks! I chatted with David, I'll push as is. /Robbin On 05/07/2016 12:51 AM, Coleen Phillimore wrote: > > Hi Robbin, > > I think this looks really good and will fit nicely with the logging that I use with class redefinition (wish I had it already!) > > http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/src/share/vm/runtime/sharedRuntime.cpp.udiff.html > > I think this is a nice solution to the problem of having tracing formerly trigger a guarantee. If one needs a guarantee to debug how old methods get invoked, we can put it > in the source code where the log_trace is and recompile. I think this is fine. > > Thanks, > Coleen > > On 5/3/16 3:25 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review this. >> >> This changeset moves redefine classes tracing to UL. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153535 >> Webrev: http://cr.openjdk.java.net/~rehn/8153535/rev_01/webrev/ >> >> Passes testsuits jdk/test/:jdk_jdi,hotspot/test/:hotspot_all,nsk.jvmti.testlist,nsk.jdi.testlist with: >> -Xlog:redefine+class*=trace >> (a few test won't run with extra options) >> >> -XX:TraceRedefineClasses=xyz turns on (aliased with) "-Xlog:redefine+class*=info" and emits a warning. >> (xyz is ignored) >> >> Thanks! >> >> /Robbin >> >> Example of useage: >> -Xlog:redefine+class+constantpool*=debug >> -Xlog:redefine+class+load=info >> -Xlog:redefine+class*=debug,redefine+class+iklass*=trace >> >> Here is an example from a test: >> >> [20.279s][debug][redefine,class,update,vtables ] vtable method update: getOptions(()Ljava/util/Properties;), updated default = false >> [20.279s][debug][redefine,class,subclass ] updated count in subclass=nsk.share.jvmti.ArgumentHandler to 197 >> [20.279s][info ][redefine,class,load ] redefined name=nsk.share.ArgumentParser, count=99 (avail_mem=6311580K) >> [20.285s][trace][redefine,class,obsolete,mark ] EMCP_cnt=8, obsolete_cnt=0 >> [20.285s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.jvmti.ArgumentHandler, EMCP_cnt=8 >> [20.285s][trace][redefine,class,iklass,add ] scratch class not added; no methods are running >> [20.285s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.ArgumentHandler >> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: getAgentOptionsString(()Ljava/lang/String;) >> [20.285s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.ArgumentHandler >> [20.285s][debug][redefine,class,update,constantpool] cpc entry update: (([Ljava/lang/String;)V) >> [20.285s][info ][redefine,class,load ] redefined name=nsk.share.jvmti.ArgumentHandler, count=198 (avail_mem=6311580K) >> [20.291s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, obsolete_cnt=0 >> [20.291s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.jvmti.JVMTITest, EMCP_cnt=3 >> [20.291s][trace][redefine,class,iklass,add ] scratch class not added; no methods are running >> [20.291s][info ][redefine,class,update ] adjust: name=nsk.share.jvmti.JVMTITest >> [20.291s][debug][redefine,class,update,constantpool] cpc entry update: commonInit(([Ljava/lang/String;)[Ljava/lang/String;) >> [20.291s][info ][redefine,class,load ] redefined name=nsk.share.jvmti.JVMTITest, count=99 (avail_mem=6311580K) >> [20.297s][trace][redefine,class,obsolete,mark ] EMCP_cnt=3, obsolete_cnt=0 >> [20.297s][trace][redefine,class,iklass,add ] adding previous version ref for nsk.share.TestBug, EMCP_cnt=3 >> >> Mapping: >> >> RC_TRACE_MESG = "redefine, class, update" - info >> >> 0x00000001 = "redefine, class, load" - info >> 0x00000001 = "redefine, class, load" - debug >> >> 0x00000002 = "redefine, class, load, exceptions" - info >> 0x00000004 = "redefine, class, timer" - info >> 0x00000008 = "redefine, class, subclass" - debug >> >> 0x00000100 = "redefine, class, obsolete, mark" - trace >> 0x00000200 = "redefine, class, iklass, purge" - trace >> 0x00000400 = "redefine, class, iklass, add" - trace >> 0x00000800 = "redefine, class, breakpoint" - debug >> >> 0x00001000->0x00002000 = "redefine, class, obsolete" - trace >> 0x00001000 = "redefine, class, obsolete" - trace >> 0x00002000 = REMOVED >> >> 0x00004000 = "redefine, class, obsolete, metadata" - trace >> 0x00004000 = "redefine, class, dump" - trace >> >> 0x00008000 = "redefine, class, normalize" - trace >> >> 0x00010000 = "redefine, class, constantpool" - info >> 0x00020000 = "redefine, class, constantpool" - debug >> 0x00040000 = "redefine, class, constantpool" - trace >> 0x00080000 = "redefine, class, constantpool" - trace >> >> 0x00100000-0x00400000 = "redefine, class, update" - info >> 0x00100000 = "redefine, class, update, vtables" - debug >> 0x00200000 = "redefine, class, update, itables" - debug >> 0x00400000 = "redefine, class, update, constantpool" - debug >> >> 0x00800000 = "redefine, class, methodcomparator" - debug >> >> 0x01000000 = "redefine, class, nmethod" - debug >> 0x02000000 = "redefine, class, annotation" - debug >> 0x04000000 = "redefine, class, stackmap" - debug >> 0x08000000 = "redefine, class, oopmap" - debug >> > From robbin.ehn at oracle.com Mon May 9 14:10:10 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 9 May 2016 16:10:10 +0200 Subject: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack Message-ID: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> Hi all, Please review this enhancement for jinfo, jstack and jmap. It is based on top of "8155091: Remove SA related functions from tmtools" http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019609.html Version 5 which is reviewed but not yet pushed: http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154985 Webrev: http://cr.openjdk.java.net/~rehn/8154985/webrev/ Passes jdk/test/sun/tools/ (or 1 test fails locally, but that tests also fails in vanilla) And manual testing. Thanks! /Robbin From staffan.larsen at oracle.com Mon May 9 14:23:00 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 May 2016 16:23:00 +0200 Subject: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack In-Reply-To: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> References: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 9 maj 2016, at 16:10, Robbin Ehn wrote: > > Hi all, > > Please review this enhancement for jinfo, jstack and jmap. > > It is based on top of "8155091: Remove SA related functions from tmtools" > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019609.html > Version 5 which is reviewed but not yet pushed: > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154985 > Webrev: http://cr.openjdk.java.net/~rehn/8154985/webrev/ > > Passes jdk/test/sun/tools/ > (or 1 test fails locally, but that tests also fails in vanilla) > And manual testing. > > Thanks! > > /Robbin From robbin.ehn at oracle.com Mon May 9 14:28:53 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 9 May 2016 16:28:53 +0200 Subject: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack In-Reply-To: References: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> Message-ID: <3c7f7196-1333-7448-9292-6af6f6721695@oracle.com> Thanks Staffan! /Robbin On 05/09/2016 04:23 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 9 maj 2016, at 16:10, Robbin Ehn wrote: >> >> Hi all, >> >> Please review this enhancement for jinfo, jstack and jmap. >> >> It is based on top of "8155091: Remove SA related functions from tmtools" >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019609.html >> Version 5 which is reviewed but not yet pushed: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154985 >> Webrev: http://cr.openjdk.java.net/~rehn/8154985/webrev/ >> >> Passes jdk/test/sun/tools/ >> (or 1 test fails locally, but that tests also fails in vanilla) >> And manual testing. >> >> Thanks! >> >> /Robbin > From mandy.chung at oracle.com Mon May 9 15:05:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 May 2016 08:05:14 -0700 Subject: RFR(M): v.05, 8155091: Remove SA related functions from tmtools In-Reply-To: <572C99C3.70206@oracle.com> References: <572A4DC9.3050902@oracle.com> <572B41DC.904@oracle.com> <7A2B2171-5E60-4259-A603-B17EB8997481@oracle.com> <572C99C3.70206@oracle.com> Message-ID: <3571C919-7269-4469-A702-200F66AF1FF4@oracle.com> > On May 6, 2016, at 6:18 AM, Dmitry Samersoff wrote: > > Everybody, > > Please, see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Removed ToolProvider interface. run(String ... args) function removed or > renamed to runWithArgs. +1 Mandy From kirill.zhaldybin at oracle.com Mon May 9 18:34:18 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldbybin) Date: Mon, 9 May 2016 21:34:18 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <22a00aa4-36e6-ca13-daf6-99eb0fddb435@oracle.com> References: <945c461a-5c5f-4789-ac9e-93c34a7ba014@default> <572CD6BA.9030606@oracle.com> <22a00aa4-36e6-ca13-daf6-99eb0fddb435@oracle.com> Message-ID: <5730D82A.1000708@oracle.com> David, Thank you for reviewing the fix! On 05/09/2016 03:08 AM, David Holmes wrote: > Hi Kirill, > > On 7/05/2016 3:39 AM, Kirill Zhaldybin wrote: >> Alexander, >> >> Thank you for reviewing the fix. >> >> On 06.05.2016 20:24, Alexander Kulyakhtin wrote: >>> Is there a specification of what shall be thrown, or the justification >>> of the changes done? >>> One can think that the currently thrown NoSuchMethodException is >>> correct since?methods, which differ in signature only, are still >>> different methods. >> I spent some time trying to figure out why I got NoSuchMethodException >> for "help" despite such method actually existed. >> >> If you think that to throw NoSuchMethodException is better for wrong >> signature I could just change error message in this case. > > The code doesn't really seem to be checking any detail of the > "signature" as such, simply that the passed in "signature" array has a > non-null zeroeth element of type String[]. Passing something else > seems like a bad call to me and so IllegalArgumentException would be > appropriate I think. > > But the logic of that entire block is suspect to me as it does not > handle the case where isEmpty() is true, but we pass in non-null > params and signature anyway. I tried to make this fix as small and low-risk as possible - as far as the repo closes on Wednesday The change does not affect "command execution" - it only throws different exceptions. Thank you. Regards, Kirill > > Aside: I'm not even convinced that NoSuchMethodException is > appropriate for the case where "actionname" doesn't exist. But that is > a different issue. > > Thanks, > David > > >> Could you please let me know your opinion? >> >> Thank you. >> >> Regards, Kirill >> >>> >>> Best regards, >>> Alexander >>> >>> >>> ----- Original Message ----- >>> From: kirill.zhaldybin at oracle.com >>> To: serviceability-dev at openjdk.java.net >>> Sent: Friday, May 6, 2016 8:11:08 PM GMT +03:00 Iraq >>> Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws >>> NoSuchMethodException even if the method actually exists but >>> parameters are wrong >>> >>> Dear all, >>> >>> Could you please review this small fix for 8156226? >>> >>> A case when a method exists but parameters' signature is wrong now >>> causes new ReflectionException(new IllegalArgumentException()) thrown >>> instead of new ReflectionException(new NoSuchMethodException()). >>> >>> WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.00/ >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8156226 >>> >>> Thank you. >>> >>> Regards, Kirill >>> >> From dmitry.samersoff at oracle.com Mon May 9 20:18:16 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 9 May 2016 23:18:16 +0300 Subject: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack In-Reply-To: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> References: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> Message-ID: <5730F088.4020907@oracle.com> Robbin, Looks good for me. Did you test the situation when more than one pid returned ? -Dmitry On 2016-05-09 17:10, Robbin Ehn wrote: > Hi all, > > Please review this enhancement for jinfo, jstack and jmap. > > It is based on top of "8155091: Remove SA related functions from tmtools" > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019609.html > > Version 5 which is reviewed but not yet pushed: > http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154985 > Webrev: http://cr.openjdk.java.net/~rehn/8154985/webrev/ > > Passes jdk/test/sun/tools/ > (or 1 test fails locally, but that tests also fails in vanilla) > And manual testing. > > Thanks! > > /Robbin -- 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 May 9 20:20:55 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 9 May 2016 22:20:55 +0200 Subject: 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack In-Reply-To: <5730F088.4020907@oracle.com> References: <3148362e-69d6-7c01-4b2c-cf763e73448d@oracle.com> <5730F088.4020907@oracle.com> Message-ID: <5b91affa-c162-838b-5998-f633c75c853b@oracle.com> Hi Dmitry, Thanks! On 05/09/2016 10:18 PM, Dmitry Samersoff wrote: > Robbin, > > Looks good for me. > > Did you test the situation when more than one pid returned ? Yes! I actually had test for that but it had same name as yours, so it was overwritten. I'll add it back after FC (and a few more tests). /Robbin > > -Dmitry > > On 2016-05-09 17:10, Robbin Ehn wrote: >> Hi all, >> >> Please review this enhancement for jinfo, jstack and jmap. >> >> It is based on top of "8155091: Remove SA related functions from tmtools" >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019609.html >> >> Version 5 which is reviewed but not yet pushed: >> http://cr.openjdk.java.net/~dsamersoff/JDK-8155091/webrev.05/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154985 >> Webrev: http://cr.openjdk.java.net/~rehn/8154985/webrev/ >> >> Passes jdk/test/sun/tools/ >> (or 1 test fails locally, but that tests also fails in vanilla) >> And manual testing. >> >> Thanks! >> >> /Robbin > > From yasuenag at gmail.com Mon May 9 23:06:26 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 10 May 2016 08:06:26 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> Message-ID: <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> We need a second reviewer. Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ Yasumasa On 2016/05/04 23:38, Marcus Larsson wrote: > Hi, > > > On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); >> >> Thanks, I applied it to new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ > > Looks OK. > > Thanks, > Marcus > >> >> Could you review again? >> >> >> Yasumasa >> >> >> On 2016/05/04 22:35, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >>>> Hi Marcus, >>>> >>>> Thank you for your comment. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ >>> >>> Looks better. The format for _rotate_size should be SIZE_FORMAT. >>> >>> While we're at it I think it would be good (as I mentioned) to use a proper unit for the filesize. Basically changing >>> >>> 93 out->print("filecount=%u,filesize=%lu ", _file_count, _rotate_size); >>> >>> into >>> >>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); >>> >>> >>> Thanks, >>> Marcus >>> >>>> >>>> I fixed to use _rotate_size and _file_count directly to show VM.log list jcmd. >>>> I do not store option string, and I added new function to print option string. >>>> >>>> Could you review it again? >>>> >>>> >>>> Thanks. >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 18:33, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>> >>>>> I would prefer to generate the option string from the actual options rather than saving the string from when it was configured. This would also produce/print the options for outputs that are using the defaults (which is not the case now). The filesize option could then use byte_size_in_proper_unit and proper_unit_for_byte_size to make it easier to read. >>>>> >>>>> Also, get_option_string() should just be called option_string(). >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> This patch makes to show option string of LogFileOutput. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>> >>>>>>> Please review. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>>>> PING: >>>>>>>> >>>>>>>> I've sent review request for JDK-8153074. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>> >>>>>>>> If this patch is merged, user can confirm output option via VM.log jcmd. >>>>>>>> >>>>>>>> >>>>>>>> Please review and sponsor it. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>>>> CC'ed to serviceability-dev. >>>>>>>>>> >>>>>>>>>> Could you review it? >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> This request review is related to [1]. >>>>>>>>>>> >>>>>>>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>>>>>>> >>>>>>>>>>> Output sample: >>>>>>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>>>>>>>>> >>>>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>> >>>>>>>>>>> >>>>> >>> > From cheleswer.sahu at oracle.com Tue May 10 11:47:27 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 10 May 2016 04:47:27 -0700 (PDT) Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> Message-ID: <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> Hi, I need one reviewer (R) to review these changes before pushing in JDK9. Can somebody please review the changes. Regards, Cheleswer > -----Original Message----- > From: Kevin Walls > Sent: Friday, May 06, 2016 3:53 PM > To: Cheleswer Sahu; Gerard Ziemski > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > > Thanks Cheleswer, looks good to me too, have been over the macros as > much as I can! > > Thanks > Kevin > > > > On 03/05/2016 07:34, Cheleswer Sahu wrote: > > Hi Gerard, > > > > > >> -----Original Message----- > >> From: Gerard Ziemski > >> Sent: Monday, May 02, 2016 9:07 PM > >> To: Cheleswer Sahu > >> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- > >> dev at openjdk.java.net > >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > >> > >> hi Cheleswer, > >> > >> > >> #1 Shouldn?t the following files be modified as well? : > >> > >> open: > >> > >> src/cpu/sparc/vm/globals_sparc.hpp > >> src/cpu/x86/vm/globals_x86.hpp > >> src/cpu/zero/vm/globals_zero.hpp > >> > >> closed: > >> > >> cpu/arm/vm/globals_arm.hpp > > I have implemented "diagnostic_pd" using "product_pd" as a reference > implementation. "product_pd" is not implemented for " ARCH_FLAGS ", > therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" > type. > > > >> share/vm/runtime/globals_ext.hpp > >> share/vm/runtime/os_ext.hpp > > These 2 files are under closed repository, so I have initiated a separate > internal review request for those changes. > > > >> > >> #2 Bunch of header files need to be updated with 2016 for Copyright: > >> > >> /* > >> - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. > >> + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. > >> * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > >> */ > >> > >> > > I agree, I will update the copyright headers. > > > >> #3 What tests have you run? Did you do: > >> > >> a) JPRT hotspot > >> b) RBT hs-nightly-runtime > >> > > I have run JPRT hostspot tests for this. It shows no error. > > > >> Please email me if you need help with those. > >> > >> > >> #4 Just heads up that I will be shortly asking for review of my fix > >> (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches > >> many of the same file, so one of us will have a tricky merge > >> > > Thanks for informing about this. > > > > > > Regards, > > Cheleswer > > > >> cheers > >> > >>> On May 2, 2016, at 4:51 AM, Cheleswer Sahu > >> wrote: > >>> Hi, > >>> > >>> > >>> > >>> Please review the code changes for > >> https://bugs.openjdk.java.net/browse/JDK-8150900. > >>> > >>> > >>> Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ > >>> > >>> > >>> > >>> Enhancement Brief: A new variant of flag "diagnostic_pd" is > implemented. > >> All flags which are diagnostic in nature and platform dependent can > >> be placed > >>> under this variant. These flags can be enable using "- > >> XX:+UnlockDiagnosticVMOptions". > >>> At present I have placed 4 flags under "diagnostic_pd" > >>> > >>> 1. 1. InitArrayShortSize > >>> > >>> 2. 2. ImplicitNullChecks > >>> > >>> 3. 3. InlineFrequencyCount > >>> > >>> 4. 4. PostLoopMultiversioning > >>> > >>> > >>> > >>> > >>> > >>> Regards, > >>> > >>> Cheleswer > From christian.thalinger at oracle.com Tue May 10 19:30:02 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 09:30:02 -1000 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> Message-ID: src/share/vm/runtime/globals.hpp - develop_pd(bool, ImplicitNullChecks, \ + diagnostic_pd(bool, ImplicitNullChecks, \ "Generate code for implicit null checks") \ Align the \ > On May 10, 2016, at 1:47 AM, Cheleswer Sahu wrote: > > Hi, > I need one reviewer (R) to review these changes before pushing in JDK9. Can somebody please review the changes. > > Regards, > Cheleswer > >> -----Original Message----- >> From: Kevin Walls >> Sent: Friday, May 06, 2016 3:53 PM >> To: Cheleswer Sahu; Gerard Ziemski >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> >> Thanks Cheleswer, looks good to me too, have been over the macros as >> much as I can! >> >> Thanks >> Kevin >> >> >> >> On 03/05/2016 07:34, Cheleswer Sahu wrote: >>> Hi Gerard, >>> >>> >>>> -----Original Message----- >>>> From: Gerard Ziemski >>>> Sent: Monday, May 02, 2016 9:07 PM >>>> To: Cheleswer Sahu >>>> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >>>> >>>> hi Cheleswer, >>>> >>>> >>>> #1 Shouldn?t the following files be modified as well? : >>>> >>>> open: >>>> >>>> src/cpu/sparc/vm/globals_sparc.hpp >>>> src/cpu/x86/vm/globals_x86.hpp >>>> src/cpu/zero/vm/globals_zero.hpp >>>> >>>> closed: >>>> >>>> cpu/arm/vm/globals_arm.hpp >>> I have implemented "diagnostic_pd" using "product_pd" as a reference >> implementation. "product_pd" is not implemented for " ARCH_FLAGS ", >> therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" >> type. >>> >>>> share/vm/runtime/globals_ext.hpp >>>> share/vm/runtime/os_ext.hpp >>> These 2 files are under closed repository, so I have initiated a separate >> internal review request for those changes. >>> >>>> >>>> #2 Bunch of header files need to be updated with 2016 for Copyright: >>>> >>>> /* >>>> - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. >>>> * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. >>>> */ >>>> >>>> >>> I agree, I will update the copyright headers. >>> >>>> #3 What tests have you run? Did you do: >>>> >>>> a) JPRT hotspot >>>> b) RBT hs-nightly-runtime >>>> >>> I have run JPRT hostspot tests for this. It shows no error. >>> >>>> Please email me if you need help with those. >>>> >>>> >>>> #4 Just heads up that I will be shortly asking for review of my fix >>>> (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches >>>> many of the same file, so one of us will have a tricky merge >>>> >>> Thanks for informing about this. >>> >>> >>> Regards, >>> Cheleswer >>> >>>> cheers >>>> >>>>> On May 2, 2016, at 4:51 AM, Cheleswer Sahu >>>> wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Please review the code changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8150900. >>>>> >>>>> >>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ >>>>> >>>>> >>>>> >>>>> Enhancement Brief: A new variant of flag "diagnostic_pd" is >> implemented. >>>> All flags which are diagnostic in nature and platform dependent can >>>> be placed >>>>> under this variant. These flags can be enable using "- >>>> XX:+UnlockDiagnosticVMOptions". >>>>> At present I have placed 4 flags under "diagnostic_pd" >>>>> >>>>> 1. 1. InitArrayShortSize >>>>> >>>>> 2. 2. ImplicitNullChecks >>>>> >>>>> 3. 3. InlineFrequencyCount >>>>> >>>>> 4. 4. PostLoopMultiversioning >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Cheleswer >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheleswer.sahu at oracle.com Wed May 11 08:58:42 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Wed, 11 May 2016 01:58:42 -0700 (PDT) Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> Message-ID: <1073c73e-dc90-410c-9774-eb1d758065e8@default> Thanks Christian for review. I will correct the alignment. ? Regards, Cheleswer ? From: Christian Thalinger Sent: Wednesday, May 11, 2016 1:00 AM To: Cheleswer Sahu Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd ? src/share/vm/runtime/globals.hpp -? develop_pd(bool, ImplicitNullChecks,????????????????????????????????????? \ +? diagnostic_pd(bool, ImplicitNullChecks,????????????????????????????????????? \ ?????????? "Generate code for implicit null checks")???????? ????????????????\ Align the \ ? On May 10, 2016, at 1:47 AM, Cheleswer Sahu wrote: ? Hi, I need one reviewer (R) to review these changes before pushing in JDK9. ?Can somebody please review the changes. Regards, Cheleswer -----Original Message----- From: Kevin Walls Sent: Friday, May 06, 2016 3:53 PM To: Cheleswer Sahu; Gerard Ziemski Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; hotspot-runtime- HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd Thanks Cheleswer, looks good to me too, have been over the macros as much as I can! Thanks Kevin On 03/05/2016 07:34, Cheleswer Sahu wrote: Hi Gerard, -----Original Message----- From: Gerard Ziemski Sent: Monday, May 02, 2016 9:07 PM To: Cheleswer Sahu Cc: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; serviceability- HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd hi Cheleswer, #1 Shouldn?t the following files be modified as well? : open: src/cpu/sparc/vm/globals_sparc.hpp src/cpu/x86/vm/globals_x86.hpp src/cpu/zero/vm/globals_zero.hpp closed: cpu/arm/vm/globals_arm.hpp I have implemented ?"diagnostic_pd" using "product_pd" as a reference implementation. "product_pd" is not implemented for " ARCH_FLAGS ", therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" type. share/vm/runtime/globals_ext.hpp share/vm/runtime/os_ext.hpp These 2 files are under closed repository, so I have initiated a separate internal review request for those changes. #2 Bunch of header files need to be updated with 2016 for Copyright: /* - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. ?* ORACLE PROPRIETARY/CONFIDENTIAL. ?Use is subject to license terms. ?*/ I agree, I will update the copyright headers. #3 What tests have you run? Did you do: a) JPRT hotspot b) RBT hs-nightly-runtime I have run JPRT hostspot tests for this. It shows no error. Please email me if you need help with those. #4 Just heads up that I will be shortly asking for review of my fix (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches many of the same file, so one of us will have a tricky merge Thanks for informing about this. Regards, Cheleswer cheers On May 2, 2016, at 4:51 AM, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8150900. Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ Enhancement Brief: ?A new variant of flag "diagnostic_pd" is implemented. All flags which are diagnostic in nature and platform dependent can be placed under this variant. These flags can be enable using ?"- XX:+UnlockDiagnosticVMOptions". At present I have placed 4 flags under "diagnostic_pd" 1. ???????1. InitArrayShortSize 2. ???????2. ImplicitNullChecks 3. ???????3. InlineFrequencyCount 4. ???????4. PostLoopMultiversioning Regards, Cheleswer ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Wed May 11 16:36:40 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 11 May 2016 19:36:40 +0300 Subject: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM Message-ID: <57335F98.5060905@oracle.com> Hi Could you please review this extra small fix which add @requires to the single test. This test is not compatible with minimal VM even it doesn't require any specific modules outside compact2. So I've just added corresponding @requires. Bug: https://bugs.openjdk.java.net/browse/JDK-8156777 Tested by manual jtreg execution with -minimal/-client/default vm options. Fix inlined: --- a/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 02:32:14 2016 -0400 +++ b/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 19:24:34 2016 +0300 @@ -24,7 +24,7 @@ /* * @test * @library /testlibrary - * + * @requires vm.flavor != "minimal" * @run main/othervm/native -agentlib:SimpleClassFileLoadHook=Foo,XXX,YYY * SimpleClassFileLoadHookTest */ Leonid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhailo.seledtsov at oracle.com Wed May 11 17:02:34 2016 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 11 May 2016 10:02:34 -0700 Subject: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM In-Reply-To: <57335F98.5060905@oracle.com> References: <57335F98.5060905@oracle.com> Message-ID: <573365AA.507@oracle.com> Fix looks good to me. Thank you, Misha On 05/11/2016 09:36 AM, Leonid Mesnik wrote: > Hi > > Could you please review this extra small fix which add @requires to > the single test. This test is not compatible with minimal VM even it > doesn't require any specific modules outside compact2. So I've just > added corresponding @requires. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156777 > > Tested by manual jtreg execution with -minimal/-client/default vm > options. > > Fix inlined: > > --- a/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May > 11 02:32:14 2016 -0400 > +++ b/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May > 11 19:24:34 2016 +0300 > @@ -24,7 +24,7 @@ > /* > * @test > * @library /testlibrary > - * > + * @requires vm.flavor != "minimal" > * @run main/othervm/native > -agentlib:SimpleClassFileLoadHook=Foo,XXX,YYY > * SimpleClassFileLoadHookTest > */ > > > Leonid From christian.tornqvist at oracle.com Thu May 12 11:21:49 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 12 May 2016 07:21:49 -0400 Subject: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM In-Reply-To: <57335F98.5060905@oracle.com> References: <57335F98.5060905@oracle.com> Message-ID: <56BFDF3F-AA0A-410E-8CE5-A770A7A3DA37@oracle.com> Hi Leonid, Change looks good. Thanks, Christian > On May 11, 2016, at 12:36 PM, Leonid Mesnik wrote: > > Hi > > Could you please review this extra small fix which add @requires to the single test. This test is not compatible with minimal VM even it doesn't require any specific modules outside compact2. So I've just added corresponding @requires. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156777 > > Tested by manual jtreg execution with -minimal/-client/default vm options. > > Fix inlined: > --- a/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 02:32:14 2016 -0400 > +++ b/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 19:24:34 2016 +0300 > @@ -24,7 +24,7 @@ > /* > * @test > * @library /testlibrary > - * > + * @requires vm.flavor != "minimal" > * @run main/othervm/native -agentlib:SimpleClassFileLoadHook=Foo,XXX,YYY > * SimpleClassFileLoadHookTest > */ > > Leonid -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Thu May 12 11:31:10 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 12 May 2016 14:31:10 +0300 Subject: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM In-Reply-To: <56BFDF3F-AA0A-410E-8CE5-A770A7A3DA37@oracle.com> References: <57335F98.5060905@oracle.com> <56BFDF3F-AA0A-410E-8CE5-A770A7A3DA37@oracle.com> Message-ID: <5734697E.1080800@oracle.com> Chris, Misha, George Thank you for review. Leonid On 12.05.2016 14:21, Christian Tornqvist wrote: > Hi Leonid, > > Change looks good. > > Thanks, > Christian > > On May 11, 2016, at 12:36 PM, Leonid Mesnik > wrote: > >> Hi >> >> Could you please review this extra small fix which add @requires to >> the single test. This test is not compatible with minimal VM even it >> doesn't require any specific modules outside compact2. So I've just >> added corresponding @requires. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156777 >> >> Tested by manual jtreg execution with -minimal/-client/default vm >> options. >> >> Fix inlined: >> --- a/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 02:32:14 2016 -0400 >> +++ b/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 19:24:34 2016 +0300 >> @@ -24,7 +24,7 @@ >> /* >> * @test >> * @library /testlibrary >> - * >> + * @requires vm.flavor != "minimal" >> * @run main/othervm/native -agentlib:SimpleClassFileLoadHook=Foo,XXX,YYY >> * SimpleClassFileLoadHookTest >> */ >> >> Leonid -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu May 12 13:25:41 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 May 2016 16:25:41 +0300 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception Message-ID: <57348455.7070006@oracle.com> Everybody, Please review test changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ The test is updated to use jhsdb launcher instead of jmap. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu May 12 14:02:32 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 May 2016 16:02:32 +0200 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception In-Reply-To: <57348455.7070006@oracle.com> References: <57348455.7070006@oracle.com> Message-ID: <9E904576-4B7D-4FA6-917D-584236AE0971@oracle.com> Looks good! The GC.heap_info Diagnostic Command should really be updated to contain a lot more information (similar to what SA produces). Should we file an enhancement for that? Thanks, /Staffan > On 12 maj 2016, at 15:25, Dmitry Samersoff wrote: > > Everybody, > > Please review test changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ > > The test is updated to use jhsdb launcher instead of jmap. > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu May 12 14:29:17 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 May 2016 17:29:17 +0300 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception In-Reply-To: <9E904576-4B7D-4FA6-917D-584236AE0971@oracle.com> References: <57348455.7070006@oracle.com> <9E904576-4B7D-4FA6-917D-584236AE0971@oracle.com> Message-ID: <5734933D.8010509@oracle.com> Staffan, > The GC.heap_info Diagnostic Command should really be updated to > contain a lot more information (similar to what SA produces). > Should we file an enhancement for that? I think yes. -Dmitry On 2016-05-12 17:02, Staffan Larsen wrote: > Looks good! > > The GC.heap_info Diagnostic Command should really be updated to > contain a lot more information (similar to what SA produces). Should > we file an enhancement for that? > > Thanks, /Staffan > > >> On 12 maj 2016, at 15:25, Dmitry Samersoff >> wrote: >> >> Everybody, >> >> Please review test changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ >> >> The test is updated to use jhsdb launcher instead of jmap. >> >> -Dmitry >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Thu May 12 16:27:30 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 12 May 2016 09:27:30 -0700 (PDT) Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception Message-ID: <026bd110-3dae-4dbb-bbd9-1577ff9580aa@default> Hi Dmitry, With this change we are not launching jmap anymore, launching jhsdb instead. I just wanted to make sure if it is ok not to test jmap anymore? Perhaps, instead of changing we should make the test to test both ? Best regards, Alexander ----- Original Message ----- From: dmitry.samersoff at oracle.com To: staffan.larsen at oracle.com Cc: serviceability-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net Sent: Thursday, May 12, 2016 5:30:26 PM GMT +03:00 Iraq Subject: Re: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception Staffan, > The GC.heap_info Diagnostic Command should really be updated to > contain a lot more information (similar to what SA produces). > Should we file an enhancement for that? I think yes. -Dmitry On 2016-05-12 17:02, Staffan Larsen wrote: > Looks good! > > The GC.heap_info Diagnostic Command should really be updated to > contain a lot more information (similar to what SA produces). Should > we file an enhancement for that? > > Thanks, /Staffan > > >> On 12 maj 2016, at 15:25, Dmitry Samersoff >> wrote: >> >> Everybody, >> >> Please review test changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ >> >> The test is updated to use jhsdb launcher instead of jmap. >> >> -Dmitry >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu May 12 17:13:11 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 May 2016 10:13:11 -0700 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception In-Reply-To: <57348455.7070006@oracle.com> References: <57348455.7070006@oracle.com> Message-ID: <5734B9A7.7080900@oracle.com> This looks good. Thanks, Serguei On 5/12/16 06:25, Dmitry Samersoff wrote: > Everybody, > > Please review test changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ > > The test is updated to use jhsdb launcher instead of jmap. > > -Dmitry > From dmitry.samersoff at oracle.com Thu May 12 17:26:00 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 12 May 2016 20:26:00 +0300 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception In-Reply-To: <026bd110-3dae-4dbb-bbd9-1577ff9580aa@default> References: <026bd110-3dae-4dbb-bbd9-1577ff9580aa@default> Message-ID: <5734BCA8.5080208@oracle.com> Alexander, jmap doesn't support coredump (non-cooperative) access anymore. This functionality moved to jhsdb. As a long term, we should create two different set of tests - one for cooperative mode (jmap, jstack, etc) and one for non-cooperative mode (jhsdb). Cooperative mode tests should resides alongside with other attach related tests - i.e. in jdk/test/sun/tools Non-cooperative mode (jhsdb) tests should be placed together with other SA tests - in hotspot/test/serviceability/sa -Dmitry On 2016-05-12 19:27, Alexander Kulyakhtin wrote: > Hi Dmitry, > > With this change we are not launching jmap anymore, launching jhsdb instead. > I just wanted to make sure if it is ok not to test jmap anymore? > Perhaps, instead of changing we should make the test to test both ? > > Best regards, > Alexander > > ----- Original Message ----- > From: dmitry.samersoff at oracle.com > To: staffan.larsen at oracle.com > Cc: serviceability-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > Sent: Thursday, May 12, 2016 5:30:26 PM GMT +03:00 Iraq > Subject: Re: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception > > Staffan, > >> The GC.heap_info Diagnostic Command should really be updated to >> contain a lot more information (similar to what SA produces). > >> Should we file an enhancement for that? > > I think yes. > > -Dmitry > > > On 2016-05-12 17:02, Staffan Larsen wrote: >> Looks good! >> >> The GC.heap_info Diagnostic Command should really be updated to >> contain a lot more information (similar to what SA produces). Should >> we file an enhancement for that? >> >> Thanks, /Staffan >> >> >>> On 12 maj 2016, at 15:25, Dmitry Samersoff >>> wrote: >>> >>> Everybody, >>> >>> Please review test changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ >>> >>> The test is updated to use jhsdb launcher instead of jmap. >>> >>> -Dmitry >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * I would love to change the world, but they won't give me >>> the sources. >> > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu May 12 18:01:57 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 May 2016 20:01:57 +0200 Subject: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception In-Reply-To: <5734BCA8.5080208@oracle.com> References: <026bd110-3dae-4dbb-bbd9-1577ff9580aa@default> <5734BCA8.5080208@oracle.com> Message-ID: <02447EE8-F238-44A6-8E46-4E767498C099@oracle.com> > On 12 maj 2016, at 19:26, Dmitry Samersoff wrote: > > Alexander, > > jmap doesn't support coredump (non-cooperative) access anymore. This > functionality moved to jhsdb. > > As a long term, we should create two different set of tests - one for > cooperative mode (jmap, jstack, etc) and one for non-cooperative mode > (jhsdb). > > Cooperative mode tests should resides alongside with other attach > related tests - i.e. in jdk/test/sun/tools Or they could be part of the diagnostic command test suite (hotspot/test/serviceability/dcmd/) since all they do is run diagnostic commands. > > Non-cooperative mode (jhsdb) tests should be placed together with other > SA tests - in hotspot/test/serviceability/sa > > -Dmitry > > On 2016-05-12 19:27, Alexander Kulyakhtin wrote: >> Hi Dmitry, >> >> With this change we are not launching jmap anymore, launching jhsdb instead. >> I just wanted to make sure if it is ok not to test jmap anymore? >> Perhaps, instead of changing we should make the test to test both ? >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From: dmitry.samersoff at oracle.com >> To: staffan.larsen at oracle.com >> Cc: serviceability-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net >> Sent: Thursday, May 12, 2016 5:30:26 PM GMT +03:00 Iraq >> Subject: Re: RFR(S): JDK-8156769 gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception >> >> Staffan, >> >>> The GC.heap_info Diagnostic Command should really be updated to >>> contain a lot more information (similar to what SA produces). >> >>> Should we file an enhancement for that? >> >> I think yes. >> >> -Dmitry >> >> >> On 2016-05-12 17:02, Staffan Larsen wrote: >>> Looks good! >>> >>> The GC.heap_info Diagnostic Command should really be updated to >>> contain a lot more information (similar to what SA produces). Should >>> we file an enhancement for that? >>> >>> Thanks, /Staffan >>> >>> >>>> On 12 maj 2016, at 15:25, Dmitry Samersoff >>>> wrote: >>>> >>>> Everybody, >>>> >>>> Please review test changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8156769/webrev.01/ >>>> >>>> The test is updated to use jhsdb launcher instead of jmap. >>>> >>>> -Dmitry >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * I would love to change the world, but they won't give me >>>> the sources. >>> >> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Thu May 12 18:14:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 12 May 2016 14:14:41 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool Message-ID: 8151066: assert(0 <= i && i < length()) failed: index out of bounds Summary: lock classes for redefinition because constant pool merging isn't thread safe, use method constant pool because constant pool merging doesn't make equivalent cpCaches because of invokedynamic I had to make these changes together. See bugs for more details. open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8155951 bug link https://bugs.openjdk.java.net/browse/JDK-8151066 Tested with rbt nightly test and 24 hours with StressRedefine test. Thanks, Coleen From serguei.spitsyn at oracle.com Thu May 12 20:21:50 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 12 May 2016 13:21:50 -0700 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: References: Message-ID: <5734E5DE.9070106@oracle.com> Hi Coleen, Great fix. Thank you a lot for finding the root causes of these issues! Thanks, Serguei On 5/12/16 11:14, Coleen Phillimore wrote: > 8151066: assert(0 <= i && i < length()) failed: index out of bounds > Summary: lock classes for redefinition because constant pool merging > isn't thread safe, use method constant pool because constant pool > merging doesn't make equivalent cpCaches because of invokedynamic > > I had to make these changes together. See bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8155951 > bug link https://bugs.openjdk.java.net/browse/JDK-8151066 > > Tested with rbt nightly test and 24 hours with StressRedefine test. > > Thanks, > Coleen > > > From coleen.phillimore at oracle.com Fri May 13 12:26:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 May 2016 08:26:45 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <5734E5DE.9070106@oracle.com> References: <5734E5DE.9070106@oracle.com> Message-ID: Serguei, Thank you so much for the quick code review. And for the idea of how to lock class redefinition. Coleen On 5/12/16 4:21 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Great fix. > Thank you a lot for finding the root causes of these issues! > > Thanks, > Serguei > > > On 5/12/16 11:14, Coleen Phillimore wrote: >> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >> Summary: lock classes for redefinition because constant pool merging >> isn't thread safe, use method constant pool because constant pool >> merging doesn't make equivalent cpCaches because of invokedynamic >> >> I had to make these changes together. See bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >> >> Tested with rbt nightly test and 24 hours with StressRedefine test. >> >> Thanks, >> Coleen >> >> >> > From david.holmes at oracle.com Mon May 16 01:51:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 May 2016 11:51:51 +1000 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: References: Message-ID: Hi Coleen, On 13/05/2016 4:14 AM, Coleen Phillimore wrote: > 8151066: assert(0 <= i && i < length()) failed: index out of bounds > Summary: lock classes for redefinition because constant pool merging > isn't thread safe, use method constant pool because constant pool > merging doesn't make equivalent cpCaches because of invokedynamic > > I had to make these changes together. See bugs for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8155951 > bug link https://bugs.openjdk.java.net/browse/JDK-8151066 In general the locking approach seems okay - as long as all mutating actions on the constantpool are being guarded with this locking. But I'm concerned that you are using a bit in _misc_flags for this mutable state. It isn't clear to me when the other bits in _misc_flags might be set but I'm assuming only during initial class parsing, or some other single-threaded use? Putting a mutable bit into such a flag set is fragile and can only be done once. Thanks, David > Tested with rbt nightly test and 24 hours with StressRedefine test. > > Thanks, > Coleen > > > From coleen.phillimore at oracle.com Mon May 16 16:28:23 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 May 2016 12:28:23 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: References: Message-ID: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> David, Thank you for looking at this change. On 5/15/16 9:51 PM, David Holmes wrote: > Hi Coleen, > > On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >> Summary: lock classes for redefinition because constant pool merging >> isn't thread safe, use method constant pool because constant pool >> merging doesn't make equivalent cpCaches because of invokedynamic >> >> I had to make these changes together. See bugs for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 > > In general the locking approach seems okay - as long as all mutating > actions on the constantpool are being guarded with this locking. > > But I'm concerned that you are using a bit in _misc_flags for this > mutable state. It isn't clear to me when the other bits in _misc_flags > might be set but I'm assuming only during initial class parsing, or > some other single-threaded use? Putting a mutable bit into such a flag > set is fragile and can only be done once. I was uneasy about this too. Most of the _misc_flags are set during initialization but there are a couple that are set while the vm is running. I moved _is_being_redefined to a bool sized gap just about the _misc_flags, which makes me more confident of the state of this field when doing locking. Retesting this small change with StressRedefine in a loop. open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev Thanks, Coleen > > Thanks, > David > > >> Tested with rbt nightly test and 24 hours with StressRedefine test. >> >> Thanks, >> Coleen >> >> >> From serguei.spitsyn at oracle.com Mon May 16 17:33:30 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 16 May 2016 10:33:30 -0700 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> Message-ID: <573A046A.80202@oracle.com> Coleen, It looks good. Good catch by David H. Thanks, Serguei On 5/16/16 09:28, Coleen Phillimore wrote: > > David, Thank you for looking at this change. > > On 5/15/16 9:51 PM, David Holmes wrote: >> Hi Coleen, >> >> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>> Summary: lock classes for redefinition because constant pool merging >>> isn't thread safe, use method constant pool because constant pool >>> merging doesn't make equivalent cpCaches because of invokedynamic >>> >>> I had to make these changes together. See bugs for more details. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >> >> In general the locking approach seems okay - as long as all mutating >> actions on the constantpool are being guarded with this locking. >> >> But I'm concerned that you are using a bit in _misc_flags for this >> mutable state. It isn't clear to me when the other bits in >> _misc_flags might be set but I'm assuming only during initial class >> parsing, or some other single-threaded use? Putting a mutable bit >> into such a flag set is fragile and can only be done once. > > I was uneasy about this too. Most of the _misc_flags are set during > initialization but there are a couple that are set while the vm is > running. I moved _is_being_redefined to a bool sized gap just about > the _misc_flags, which makes me more confident of the state of this > field when doing locking. > > Retesting this small change with StressRedefine in a loop. > > open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev > > Thanks, > Coleen > >> >> Thanks, >> David >> >> >>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>> >>> Thanks, >>> Coleen >>> >>> >>> > From coleen.phillimore at oracle.com Mon May 16 18:11:34 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 May 2016 14:11:34 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <573A046A.80202@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> <573A046A.80202@oracle.com> Message-ID: <107e4681-d047-e635-1cf1-197ed07f82ac@oracle.com> Thanks, again, Serguei! Coleen On 5/16/16 1:33 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > It looks good. > Good catch by David H. > > Thanks, > Serguei > > On 5/16/16 09:28, Coleen Phillimore wrote: >> >> David, Thank you for looking at this change. >> >> On 5/15/16 9:51 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>>> Summary: lock classes for redefinition because constant pool merging >>>> isn't thread safe, use method constant pool because constant pool >>>> merging doesn't make equivalent cpCaches because of invokedynamic >>>> >>>> I had to make these changes together. See bugs for more details. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >>> >>> In general the locking approach seems okay - as long as all mutating >>> actions on the constantpool are being guarded with this locking. >>> >>> But I'm concerned that you are using a bit in _misc_flags for this >>> mutable state. It isn't clear to me when the other bits in >>> _misc_flags might be set but I'm assuming only during initial class >>> parsing, or some other single-threaded use? Putting a mutable bit >>> into such a flag set is fragile and can only be done once. >> >> I was uneasy about this too. Most of the _misc_flags are set during >> initialization but there are a couple that are set while the vm is >> running. I moved _is_being_redefined to a bool sized gap just about >> the _misc_flags, which makes me more confident of the state of this >> field when doing locking. >> >> Retesting this small change with StressRedefine in a loop. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> >>>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >> > From david.holmes at oracle.com Mon May 16 20:59:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 May 2016 06:59:59 +1000 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> Message-ID: <74dbcc5e-7de2-2675-0623-fb8f0e5d459a@oracle.com> Looks good! Thanks, David On 17/05/2016 2:28 AM, Coleen Phillimore wrote: > > David, Thank you for looking at this change. > > On 5/15/16 9:51 PM, David Holmes wrote: >> Hi Coleen, >> >> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>> Summary: lock classes for redefinition because constant pool merging >>> isn't thread safe, use method constant pool because constant pool >>> merging doesn't make equivalent cpCaches because of invokedynamic >>> >>> I had to make these changes together. See bugs for more details. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >> >> In general the locking approach seems okay - as long as all mutating >> actions on the constantpool are being guarded with this locking. >> >> But I'm concerned that you are using a bit in _misc_flags for this >> mutable state. It isn't clear to me when the other bits in _misc_flags >> might be set but I'm assuming only during initial class parsing, or >> some other single-threaded use? Putting a mutable bit into such a flag >> set is fragile and can only be done once. > > I was uneasy about this too. Most of the _misc_flags are set during > initialization but there are a couple that are set while the vm is > running. I moved _is_being_redefined to a bool sized gap just about > the _misc_flags, which makes me more confident of the state of this > field when doing locking. > > Retesting this small change with StressRedefine in a loop. > > open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev > > Thanks, > Coleen > >> >> Thanks, >> David >> >> >>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>> >>> Thanks, >>> Coleen >>> >>> >>> > From coleen.phillimore at oracle.com Mon May 16 21:42:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 16 May 2016 17:42:21 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <74dbcc5e-7de2-2675-0623-fb8f0e5d459a@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> <74dbcc5e-7de2-2675-0623-fb8f0e5d459a@oracle.com> Message-ID: <082eb574-6db8-1d76-9f8a-4579fd31a1b5@oracle.com> Thank you, David! Coleen On 5/16/16 4:59 PM, David Holmes wrote: > Looks good! > > Thanks, > David > > On 17/05/2016 2:28 AM, Coleen Phillimore wrote: >> >> David, Thank you for looking at this change. >> >> On 5/15/16 9:51 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>>> Summary: lock classes for redefinition because constant pool merging >>>> isn't thread safe, use method constant pool because constant pool >>>> merging doesn't make equivalent cpCaches because of invokedynamic >>>> >>>> I had to make these changes together. See bugs for more details. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >>> >>> In general the locking approach seems okay - as long as all mutating >>> actions on the constantpool are being guarded with this locking. >>> >>> But I'm concerned that you are using a bit in _misc_flags for this >>> mutable state. It isn't clear to me when the other bits in _misc_flags >>> might be set but I'm assuming only during initial class parsing, or >>> some other single-threaded use? Putting a mutable bit into such a flag >>> set is fragile and can only be done once. >> >> I was uneasy about this too. Most of the _misc_flags are set during >> initialization but there are a couple that are set while the vm is >> running. I moved _is_being_redefined to a bool sized gap just about >> the _misc_flags, which makes me more confident of the state of this >> field when doing locking. >> >> Retesting this small change with StressRedefine in a loop. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> >>>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >> From yasuenag at gmail.com Tue May 17 10:15:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 17 May 2016 19:15:22 +0900 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> Message-ID: <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> PING: Could you review it? We need a reviewer. > bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ Thanks, Yasumasa On 2016/05/06 1:18, Gerard Ziemski wrote: > I?m including serviceability mailing list. > > bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ > > > cheers > >> Begin forwarded message: >> >> From: Yasumasa Suenaga >> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd >> Date: May 4, 2016 at 9:34:15 AM CDT >> To: "hotspot-runtime-dev at openjdk.java.net" >> Cc: Gerard Ziemski >> >> Hi all, >> >> We still need a second Reviewer. >> Could you review? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>> Hi Gerard, >>> >>>> Reviewed and I will sponsor it. >>> >>> Thanks! >>> >>>> Just one question: there is no existing JDK issue covering this yet, is there? Can you file one please if none exists yet? >>> >>> I do not change in jdk repos. >>> My change affects jinfo, however jtreg test for jinfo passed. >>> >>> I ran jtreg with two directories: >>> >>> - hotspot/test/serviceability/dcmd/vm >>> - jdk/test/sun/tools/jinfo >>> >>> They work fine. >>> (JInfoRunningProcessFlagTest is failed. But it is listed in ProblemList.) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>> hi Yasumasa, >>>> >>>> Thank you for the fix, I like it - the very first time I tried using jcmd to set a boolean value I tried using ?true?, so this will make jcmd easier to use. >>>> >>>> Reviewed and I will sponsor it. >>>> >>>> Just one question: there is no existing JDK issue covering this yet, is there? Can you file one please if none exists yet? >>>> >>>> >>>> >>>> cheers >>>> >>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request relates to [1]. >>>>> >>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>> This jcmd requires 1 or 0 as boolean value. >>>>> However, we can set 0 or not (NOT 1). >>>>> >>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>> So I think it is useful if VM.set_flag accept boolean value in true/false. >>>>> >>>>> I uploaded a webrev for this issue. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>> >>>>> I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>> > From yasuenag at gmail.com Tue May 17 10:17:15 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 17 May 2016 19:17:15 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> References: <56FBDE2F.60701@gmail.com> <56FD2786.9020102@gmail.com> <570B6E86.6020507@gmail.com> <5714EA83.8050007@gmail.com> <571638D1.3040702@gmail.com> <5d0b6dfb-9b93-3d6e-c126-e3919010a1e6@gmail.com> <06238868-beb1-6e53-49e4-f4e01047aa7e@oracle.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> Message-ID: <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> PING: Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ Thanks, Yasumasa On 2016/05/10 8:06, Yasumasa Suenaga wrote: > We need a second reviewer. > Could you review it? > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ > > > Yasumasa > > > On 2016/05/04 23:38, Marcus Larsson wrote: >> Hi, >> >> >> On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); >>> >>> Thanks, I applied it to new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >> >> Looks OK. >> >> Thanks, >> Marcus >> >>> >>> Could you review again? >>> >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 22:35, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote: >>>>> Hi Marcus, >>>>> >>>>> Thank you for your comment. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/ >>>> >>>> Looks better. The format for _rotate_size should be SIZE_FORMAT. >>>> >>>> While we're at it I think it would be good (as I mentioned) to use a proper unit for the filesize. Basically changing >>>> >>>> 93 out->print("filecount=%u,filesize=%lu ", _file_count, _rotate_size); >>>> >>>> into >>>> >>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ", _file_count, byte_size_in_proper_unit(_rotate_size), proper_unit_for_byte_size(_rotate_size)); >>>> >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> I fixed to use _rotate_size and _file_count directly to show VM.log list jcmd. >>>>> I do not store option string, and I added new function to print option string. >>>>> >>>>> Could you review it again? >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/04 18:33, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>> >>>>>> I would prefer to generate the option string from the actual options rather than saving the string from when it was configured. This would also produce/print the options for outputs that are using the defaults (which is not the case now). The filesize option could then use byte_size_in_proper_unit and proper_unit_for_byte_size to make it easier to read. >>>>>> >>>>>> Also, get_option_string() should just be called option_string(). >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> This patch makes to show option string of LogFileOutput. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote: >>>>>>>> I adapted changes to jdk9/hs/hotspot repos. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/ >>>>>>>> >>>>>>>> Please review. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote: >>>>>>>>> PING: >>>>>>>>> >>>>>>>>> I've sent review request for JDK-8153074. >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>> >>>>>>>>> If this patch is merged, user can confirm output option via VM.log jcmd. >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review and sponsor it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote: >>>>>>>>>>> CC'ed to serviceability-dev. >>>>>>>>>>> >>>>>>>>>>> Could you review it? >>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> This request review is related to [1]. >>>>>>>>>>>> >>>>>>>>>>>> I want to see output option (filecount, filesize) in VM.log jcmd. >>>>>>>>>>>> >>>>>>>>>>>> Output sample: >>>>>>>>>>>> #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level, >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev. Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>> >> From dmitry.samersoff at oracle.com Tue May 17 10:25:20 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 17 May 2016 13:25:20 +0300 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> Message-ID: <573AF190.3000707@oracle.com> Yasumasa, 1. Please use strcasecmp for true/false 2. You may save one strcmp call by replacing it to (*arg == '0' && *(arg+1) == 0) -Dmitry On 2016-05-17 13:15, Yasumasa Suenaga wrote: > PING: Could you review it? > We need a reviewer. > >> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2016/05/06 1:18, Gerard Ziemski wrote: >> I?m including serviceability mailing list. >> >> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >> >> >> cheers >> >>> Begin forwarded message: >>> >>> From: Yasumasa Suenaga >>> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or >>> true/false via VM.set_flag jcmd >>> Date: May 4, 2016 at 9:34:15 AM CDT >>> To: "hotspot-runtime-dev at openjdk.java.net" >>> >>> Cc: Gerard Ziemski >>> >>> Hi all, >>> >>> We still need a second Reviewer. >>> Could you review? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>>> Hi Gerard, >>>> >>>>> Reviewed and I will sponsor it. >>>> >>>> Thanks! >>>> >>>>> Just one question: there is no existing JDK issue covering this >>>>> yet, is there? Can you file one please if none exists yet? >>>> >>>> I do not change in jdk repos. >>>> My change affects jinfo, however jtreg test for jinfo passed. >>>> >>>> I ran jtreg with two directories: >>>> >>>> - hotspot/test/serviceability/dcmd/vm >>>> - jdk/test/sun/tools/jinfo >>>> >>>> They work fine. >>>> (JInfoRunningProcessFlagTest is failed. But it is listed in >>>> ProblemList.) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>>> hi Yasumasa, >>>>> >>>>> Thank you for the fix, I like it - the very first time I tried >>>>> using jcmd to set a boolean value I tried using ?true?, so this >>>>> will make jcmd easier to use. >>>>> >>>>> Reviewed and I will sponsor it. >>>>> >>>>> Just one question: there is no existing JDK issue covering this >>>>> yet, is there? Can you file one please if none exists yet? >>>>> >>>>> >>>>> >>>>> cheers >>>>> >>>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> This review request relates to [1]. >>>>>> >>>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>>> This jcmd requires 1 or 0 as boolean value. >>>>>> However, we can set 0 or not (NOT 1). >>>>>> >>>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>>> So I think it is useful if VM.set_flag accept boolean value in >>>>>> true/false. >>>>>> >>>>>> I uploaded a webrev for this issue. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>>> >>>>>> I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>>>> >>>>> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Tue May 17 14:31:30 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 17 May 2016 23:31:30 +0900 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <573AF190.3000707@oracle.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> <573AF190.3000707@oracle.com> Message-ID: <60639382-bbab-0211-46c9-ac194c360f2a@gmail.com> Hi Dmitry, Thank you for your comment. I've fixed them in new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.01/ Yasumasa On 2016/05/17 19:25, Dmitry Samersoff wrote: > Yasumasa, > > 1. Please use strcasecmp for true/false > > 2. You may save one strcmp call by replacing it to > (*arg == '0' && *(arg+1) == 0) > > -Dmitry > > > On 2016-05-17 13:15, Yasumasa Suenaga wrote: >> PING: Could you review it? >> We need a reviewer. >> >>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/06 1:18, Gerard Ziemski wrote: >>> I?m including serviceability mailing list. >>> >>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>> >>> >>> cheers >>> >>>> Begin forwarded message: >>>> >>>> From: Yasumasa Suenaga >>>> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or >>>> true/false via VM.set_flag jcmd >>>> Date: May 4, 2016 at 9:34:15 AM CDT >>>> To: "hotspot-runtime-dev at openjdk.java.net" >>>> >>>> Cc: Gerard Ziemski >>>> >>>> Hi all, >>>> >>>> We still need a second Reviewer. >>>> Could you review? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>>>> Hi Gerard, >>>>> >>>>>> Reviewed and I will sponsor it. >>>>> >>>>> Thanks! >>>>> >>>>>> Just one question: there is no existing JDK issue covering this >>>>>> yet, is there? Can you file one please if none exists yet? >>>>> >>>>> I do not change in jdk repos. >>>>> My change affects jinfo, however jtreg test for jinfo passed. >>>>> >>>>> I ran jtreg with two directories: >>>>> >>>>> - hotspot/test/serviceability/dcmd/vm >>>>> - jdk/test/sun/tools/jinfo >>>>> >>>>> They work fine. >>>>> (JInfoRunningProcessFlagTest is failed. But it is listed in >>>>> ProblemList.) >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>>>> hi Yasumasa, >>>>>> >>>>>> Thank you for the fix, I like it - the very first time I tried >>>>>> using jcmd to set a boolean value I tried using ?true?, so this >>>>>> will make jcmd easier to use. >>>>>> >>>>>> Reviewed and I will sponsor it. >>>>>> >>>>>> Just one question: there is no existing JDK issue covering this >>>>>> yet, is there? Can you file one please if none exists yet? >>>>>> >>>>>> >>>>>> >>>>>> cheers >>>>>> >>>>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> This review request relates to [1]. >>>>>>> >>>>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>>>> This jcmd requires 1 or 0 as boolean value. >>>>>>> However, we can set 0 or not (NOT 1). >>>>>>> >>>>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>>>> So I think it is useful if VM.set_flag accept boolean value in >>>>>>> true/false. >>>>>>> >>>>>>> I uploaded a webrev for this issue. >>>>>>> Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>>>> >>>>>>> I cannot access JPRT. >>>>>>> So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>>>>> >>>>>> >>> > > From alexhenrie24 at gmail.com Tue May 17 15:46:02 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 17 May 2016 09:46:02 -0600 Subject: [PATCH resend2] 8145278: Fix memory leak in splitPathList In-Reply-To: <57154B50.4050900@oracle.com> References: <66c6fa3b2280afa12a2d.1460489321@wolverine> <570D64D3.8000005@oracle.com> <570D69F0.3040504@oracle.com> <570F5638.1030708@oracle.com> <57154236.7060703@oracle.com> <57154626.8020403@oracle.com> <571549BF.4080704@oracle.com> <57154A45.4000208@oracle.com> <57154B50.4050900@oracle.com> Message-ID: I can see the change now at and , thank you. -Alex From dmitry.samersoff at oracle.com Tue May 17 17:36:28 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 17 May 2016 20:36:28 +0300 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <60639382-bbab-0211-46c9-ac194c360f2a@gmail.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> <573AF190.3000707@oracle.com> <60639382-bbab-0211-46c9-ac194c360f2a@gmail.com> Message-ID: <573B569C.7090007@oracle.com> Yasumasa, Looks good for me. -Dmitry On 2016-05-17 17:31, Yasumasa Suenaga wrote: > Hi Dmitry, > > Thank you for your comment. > I've fixed them in new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.01/ > > > Yasumasa > > > On 2016/05/17 19:25, Dmitry Samersoff wrote: >> Yasumasa, >> >> 1. Please use strcasecmp for true/false >> >> 2. You may save one strcmp call by replacing it to >> (*arg == '0' && *(arg+1) == 0) >> >> -Dmitry >> >> >> On 2016-05-17 13:15, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> We need a reviewer. >>> >>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/06 1:18, Gerard Ziemski wrote: >>>> I?m including serviceability mailing list. >>>> >>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v >>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>> >>>> >>>> cheers >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Yasumasa Suenaga >>>>> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or >>>>> true/false via VM.set_flag jcmd >>>>> Date: May 4, 2016 at 9:34:15 AM CDT >>>>> To: "hotspot-runtime-dev at openjdk.java.net" >>>>> >>>>> Cc: Gerard Ziemski >>>>> >>>>> Hi all, >>>>> >>>>> We still need a second Reviewer. >>>>> Could you review? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>>>>> Hi Gerard, >>>>>> >>>>>>> Reviewed and I will sponsor it. >>>>>> >>>>>> Thanks! >>>>>> >>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>> >>>>>> I do not change in jdk repos. >>>>>> My change affects jinfo, however jtreg test for jinfo passed. >>>>>> >>>>>> I ran jtreg with two directories: >>>>>> >>>>>> - hotspot/test/serviceability/dcmd/vm >>>>>> - jdk/test/sun/tools/jinfo >>>>>> >>>>>> They work fine. >>>>>> (JInfoRunningProcessFlagTest is failed. But it is listed in >>>>>> ProblemList.) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>>>>> hi Yasumasa, >>>>>>> >>>>>>> Thank you for the fix, I like it - the very first time I tried >>>>>>> using jcmd to set a boolean value I tried using ?true?, so this >>>>>>> will make jcmd easier to use. >>>>>>> >>>>>>> Reviewed and I will sponsor it. >>>>>>> >>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>>> >>>>>>> >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This review request relates to [1]. >>>>>>>> >>>>>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>>>>> This jcmd requires 1 or 0 as boolean value. >>>>>>>> However, we can set 0 or not (NOT 1). >>>>>>>> >>>>>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>>>>> So I think it is useful if VM.set_flag accept boolean value in >>>>>>>> true/false. >>>>>>>> >>>>>>>> I uploaded a webrev for this issue. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>>>>> >>>>>>>> I cannot access JPRT. >>>>>>>> So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>>>>>> >>>>>>>> >>>>>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From gerard.ziemski at oracle.com Tue May 17 18:15:14 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 17 May 2016 13:15:14 -0500 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <573B569C.7090007@oracle.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> <573AF190.3000707@oracle.com> <60639382-bbab-0211-46c9-ac194c360f2a@gmail.com> <573B569C.7090007@oracle.com> Message-ID: hi Yasumasa, We now have 2 reviewers, so I will push it in as soon as I get final testing results passing. cheers > On May 17, 2016, at 12:36 PM, Dmitry Samersoff wrote: > > Yasumasa, > > Looks good for me. > > -Dmitry > > On 2016-05-17 17:31, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> Thank you for your comment. >> I've fixed them in new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.01/ >> >> >> Yasumasa >> >> >> On 2016/05/17 19:25, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> 1. Please use strcasecmp for true/false >>> >>> 2. You may save one strcmp call by replacing it to >>> (*arg == '0' && *(arg+1) == 0) >>> >>> -Dmitry >>> >>> >>> On 2016-05-17 13:15, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> We need a reviewer. >>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/06 1:18, Gerard Ziemski wrote: >>>>> I?m including serviceability mailing list. >>>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>> >>>>> >>>>> cheers >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> From: Yasumasa Suenaga >>>>>> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or >>>>>> true/false via VM.set_flag jcmd >>>>>> Date: May 4, 2016 at 9:34:15 AM CDT >>>>>> To: "hotspot-runtime-dev at openjdk.java.net" >>>>>> >>>>>> Cc: Gerard Ziemski >>>>>> >>>>>> Hi all, >>>>>> >>>>>> We still need a second Reviewer. >>>>>> Could you review? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>>>>>> Hi Gerard, >>>>>>> >>>>>>>> Reviewed and I will sponsor it. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>>> >>>>>>> I do not change in jdk repos. >>>>>>> My change affects jinfo, however jtreg test for jinfo passed. >>>>>>> >>>>>>> I ran jtreg with two directories: >>>>>>> >>>>>>> - hotspot/test/serviceability/dcmd/vm >>>>>>> - jdk/test/sun/tools/jinfo >>>>>>> >>>>>>> They work fine. >>>>>>> (JInfoRunningProcessFlagTest is failed. But it is listed in >>>>>>> ProblemList.) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>>>>>> hi Yasumasa, >>>>>>>> >>>>>>>> Thank you for the fix, I like it - the very first time I tried >>>>>>>> using jcmd to set a boolean value I tried using ?true?, so this >>>>>>>> will make jcmd easier to use. >>>>>>>> >>>>>>>> Reviewed and I will sponsor it. >>>>>>>> >>>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This review request relates to [1]. >>>>>>>>> >>>>>>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>>>>>> This jcmd requires 1 or 0 as boolean value. >>>>>>>>> However, we can set 0 or not (NOT 1). >>>>>>>>> >>>>>>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>>>>>> So I think it is useful if VM.set_flag accept boolean value in >>>>>>>>> true/false. >>>>>>>>> >>>>>>>>> I uploaded a webrev for this issue. >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>>>>>> >>>>>>>>> I cannot access JPRT. >>>>>>>>> So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>> >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Thu May 19 04:52:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 14:52:50 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 Message-ID: Not sure who really owns this file so cc'ing core-libs and serviceability. bug: https://bugs.openjdk.java.net/browse/JDK-8157188 The file src/java.base/share/native/include/classfile_constants.h describes information about classfiles and is used by libverify and ./demo/share/jvmti/java_crw_demo/java_crw_demo.c This file has not been updated for classfile version 53 and so asserts will fail in java_crw_demo.c when it encounters classes compiled for version 53 - as they now are. This version change caused test failures in the hotspot forest when it was pulled down earlier this week. This fix trivially bumps the current version number to 53 to fix the failing tests. It is a separate issue as to whether other changes are needed in this file to reflect what is new with classfile version 53. Diff below. Thanks, David ------ diff -r 3eea6819cc1f src/java.base/share/native/include/classfile_constants.h --- a/src/java.base/share/native/include/classfile_constants.h +++ b/src/java.base/share/native/include/classfile_constants.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -31,7 +31,7 @@ #endif /* Classfile version number for this information */ -#define JVM_CLASSFILE_MAJOR_VERSION 52 +#define JVM_CLASSFILE_MAJOR_VERSION 53 #define JVM_CLASSFILE_MINOR_VERSION 0 /* Flags */ From dmitry.samersoff at oracle.com Thu May 19 05:01:25 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 19 May 2016 08:01:25 +0300 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D48A5.6040505@oracle.com> David, Looks good for me. Probably I was the last person who do something with java_crw_demo.c. -Dmitry On 2016-05-19 07:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. > > Diff below. > > Thanks, > David > ------ > > diff -r 3eea6819cc1f > src/java.base/share/native/include/classfile_constants.h > --- a/src/java.base/share/native/include/classfile_constants.h > +++ b/src/java.base/share/native/include/classfile_constants.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -31,7 +31,7 @@ > #endif > > /* Classfile version number for this information */ > -#define JVM_CLASSFILE_MAJOR_VERSION 52 > +#define JVM_CLASSFILE_MAJOR_VERSION 53 > #define JVM_CLASSFILE_MINOR_VERSION 0 > > /* Flags */ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu May 19 05:37:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 06:37:38 +0100 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D5122.8030207@oracle.com> On 19/05/2016 05:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and > serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. It's the serviceability area that has historically maintained this. The change looks fine. -Alan From david.holmes at oracle.com Thu May 19 07:48:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 17:48:12 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: <573D48A5.6040505@oracle.com> References: <573D48A5.6040505@oracle.com> Message-ID: <52fe8557-7600-4123-9862-8823c8fa9b9f@oracle.com> Thanks Dmitry! David On 19/05/2016 3:01 PM, Dmitry Samersoff wrote: > David, > > Looks good for me. > > Probably I was the last person who do something with java_crw_demo.c. > > -Dmitry > > On 2016-05-19 07:52, David Holmes wrote: >> Not sure who really owns this file so cc'ing core-libs and serviceability. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157188 >> >> The file src/java.base/share/native/include/classfile_constants.h >> describes information about classfiles and is used by libverify and >> ./demo/share/jvmti/java_crw_demo/java_crw_demo.c >> >> This file has not been updated for classfile version 53 and so asserts >> will fail in java_crw_demo.c when it encounters classes compiled for >> version 53 - as they now are. This version change caused test failures >> in the hotspot forest when it was pulled down earlier this week. >> >> This fix trivially bumps the current version number to 53 to fix the >> failing tests. It is a separate issue as to whether other changes are >> needed in this file to reflect what is new with classfile version 53. >> >> Diff below. >> >> Thanks, >> David >> ------ >> >> diff -r 3eea6819cc1f >> src/java.base/share/native/include/classfile_constants.h >> --- a/src/java.base/share/native/include/classfile_constants.h >> +++ b/src/java.base/share/native/include/classfile_constants.h >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -31,7 +31,7 @@ >> #endif >> >> /* Classfile version number for this information */ >> -#define JVM_CLASSFILE_MAJOR_VERSION 52 >> +#define JVM_CLASSFILE_MAJOR_VERSION 53 >> #define JVM_CLASSFILE_MINOR_VERSION 0 >> >> /* Flags */ > > From david.holmes at oracle.com Thu May 19 07:51:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 17:51:32 +1000 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: <573D5122.8030207@oracle.com> References: <573D5122.8030207@oracle.com> Message-ID: <3944d8fa-7ac3-6a90-da16-aec7006c7805@oracle.com> Thanks Alan! David On 19/05/2016 3:37 PM, Alan Bateman wrote: > On 19/05/2016 05:52, David Holmes wrote: >> Not sure who really owns this file so cc'ing core-libs and >> serviceability. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157188 >> >> The file src/java.base/share/native/include/classfile_constants.h >> describes information about classfiles and is used by libverify and >> ./demo/share/jvmti/java_crw_demo/java_crw_demo.c >> >> This file has not been updated for classfile version 53 and so asserts >> will fail in java_crw_demo.c when it encounters classes compiled for >> version 53 - as they now are. This version change caused test failures >> in the hotspot forest when it was pulled down earlier this week. >> >> This fix trivially bumps the current version number to 53 to fix the >> failing tests. It is a separate issue as to whether other changes are >> needed in this file to reflect what is new with classfile version 53. > It's the serviceability area that has historically maintained this. The > change looks fine. > > -Alan From serguei.spitsyn at oracle.com Thu May 19 08:09:26 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 May 2016 01:09:26 -0700 Subject: RFR (XS): 8157188: 2 test failures in demo/jvmti due to unexpected class file version 53 In-Reply-To: References: Message-ID: <573D74B6.10401@oracle.com> David, The change looks good but you already have enough reviewers. :) Just wanted to thank you for taking steps on this issue. Thanks, Serguei On 5/18/16 21:52, David Holmes wrote: > Not sure who really owns this file so cc'ing core-libs and > serviceability. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157188 > > The file src/java.base/share/native/include/classfile_constants.h > describes information about classfiles and is used by libverify and > ./demo/share/jvmti/java_crw_demo/java_crw_demo.c > > This file has not been updated for classfile version 53 and so asserts > will fail in java_crw_demo.c when it encounters classes compiled for > version 53 - as they now are. This version change caused test failures > in the hotspot forest when it was pulled down earlier this week. > > This fix trivially bumps the current version number to 53 to fix the > failing tests. It is a separate issue as to whether other changes are > needed in this file to reflect what is new with classfile version 53. > > Diff below. > > Thanks, > David > ------ > > diff -r 3eea6819cc1f > src/java.base/share/native/include/classfile_constants.h > --- a/src/java.base/share/native/include/classfile_constants.h > +++ b/src/java.base/share/native/include/classfile_constants.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -31,7 +31,7 @@ > #endif > > /* Classfile version number for this information */ > -#define JVM_CLASSFILE_MAJOR_VERSION 52 > +#define JVM_CLASSFILE_MAJOR_VERSION 53 > #define JVM_CLASSFILE_MINOR_VERSION 0 > > /* Flags */ From staffan at larsen.se Mon May 23 09:17:12 2016 From: staffan at larsen.se (Staffan Larsen) Date: Mon, 23 May 2016 11:17:12 +0200 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode Message-ID: This is my second attempt at fixing this timeout by taking the jtreg timeout factor into account in the tests. The first fix [1] looked at the wrong environment variable, and also would have caused the test to run unnecessarily slow since it set sleep_seconds to a higher value instead of changing the timeout. In this version I have tried to fix these problems. I now look at the env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout factor in floating point notation. Since it is easier to work with integers in shell scripts, I truncate this value using and awk expression. I then use this value to set up time limits in the two places where we have them. To simplify the code in the cmd() function, I no longer print out stack traces after half the timeLimit, only when the limit has expired. I think this is reasonable. bug: https://bugs.openjdk.java.net/browse/JDK-8157555 webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ Thanks, /Staffan [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon May 23 21:39:13 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 23 May 2016 14:39:13 -0700 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: References: Message-ID: <57437881.3060901@oracle.com> Staffan, I do not see any issues, the fix looks good to me. One question though. Where does the TESTTIMEOUTFACTOR environment variable come from? I do not see it used anywhere in the jtreg tests. Thanks, Serguei On 5/23/16 02:17, Staffan Larsen wrote: > This is my second attempt at fixing this timeout by taking the jtreg > timeout factor into account in the tests. The first fix [1] looked at > the wrong environment variable, and also would have caused the test to > run unnecessarily slow since it set sleep_seconds to a higher value > instead of changing the timeout. > > In this version I have tried to fix these problems. I now look at the > env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout > factor in floating point notation. Since it is easier to work with > integers in shell scripts, I truncate this value using and awk > expression. I then use this value to set up time limits in the two > places where we have them. To simplify the code in the cmd() function, > I no longer print out stack traces after half the timeLimit, only when > the limit has expired. I think this is reasonable. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157555 > webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ > > > Thanks, > /Staffan > > [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan at larsen.se Tue May 24 06:35:58 2016 From: staffan at larsen.se (Staffan Larsen) Date: Tue, 24 May 2016 08:35:58 +0200 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: <57437881.3060901@oracle.com> References: <57437881.3060901@oracle.com> Message-ID: <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> > On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com wrote: > > Staffan, > > I do not see any issues, the fix looks good to me. Thanks! > One question though. > > Where does the TESTTIMEOUTFACTOR environment variable come from? > I do not see it used anywhere in the jtreg tests. It is set by jtreg. See: http://openjdk.java.net/jtreg/tag-spec.html#testvars > > Thanks, > Serguei > > > On 5/23/16 02:17, Staffan Larsen wrote: >> This is my second attempt at fixing this timeout by taking the jtreg timeout factor into account in the tests. The first fix [1] looked at the wrong environment variable, and also would have caused the test to run unnecessarily slow since it set sleep_seconds to a higher value instead of changing the timeout. >> >> In this version I have tried to fix these problems. I now look at the env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout factor in floating point notation. Since it is easier to work with integers in shell scripts, I truncate this value using and awk expression. I then use this value to set up time limits in the two places where we have them. To simplify the code in the cmd() function, I no longer print out stack traces after half the timeLimit, only when the limit has expired. I think this is reasonable. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >> >> Thanks, >> /Staffan >> >> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 24 07:01:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 00:01:47 -0700 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> References: <57437881.3060901@oracle.com> <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> Message-ID: <5743FC5B.6080904@oracle.com> On 5/23/16 23:35, Staffan Larsen wrote: > >> On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com >> wrote: >> >> Staffan, >> >> I do not see any issues, the fix looks good to me. > > Thanks! > >> One question though. >> >> Where does the TESTTIMEOUTFACTOR environment variable come from? >> I do not see it used anywhere in the jtreg tests. > > It is set by jtreg. See: > http://openjdk.java.net/jtreg/tag-spec.html#testvars Ok, I see. It looks like it was not used in the jtreg tests. But maybe my grep was not consistent. Thanks, Serguei > >> >> Thanks, >> Serguei >> >> >> On 5/23/16 02:17, Staffan Larsen wrote: >>> This is my second attempt at fixing this timeout by taking the jtreg >>> timeout factor into account in the tests. The first fix [1] looked >>> at the wrong environment variable, and also would have caused the >>> test to run unnecessarily slow since it set sleep_seconds to a >>> higher value instead of changing the timeout. >>> >>> In this version I have tried to fix these problems. I now look at >>> the env variable TESTTIMEOUTFACTOR which will contain the jtreg >>> timeout factor in floating point notation. Since it is easier to >>> work with integers in shell scripts, I truncate this value using and >>> awk expression. I then use this value to set up time limits in the >>> two places where we have them. To simplify the code in the cmd() >>> function, I no longer print out stack traces after half the >>> timeLimit, only when the limit has expired. I think this is reasonable. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 >>> webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>> >>> >>> Thanks, >>> /Staffan >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 24 07:06:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 00:06:44 -0700 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: <5743FC5B.6080904@oracle.com> References: <57437881.3060901@oracle.com> <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> <5743FC5B.6080904@oracle.com> Message-ID: <5743FD84.90703@oracle.com> On 5/24/16 00:01, serguei.spitsyn at oracle.com wrote: > On 5/23/16 23:35, Staffan Larsen wrote: >> >>> On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com wrote: >>> >>> Staffan, >>> >>> I do not see any issues, the fix looks good to me. >> >> Thanks! >> >>> One question though. >>> >>> Where does the TESTTIMEOUTFACTOR environment variable come from? >>> I do not see it used anywhere in the jtreg tests. >> >> It is set by jtreg. See: >> http://openjdk.java.net/jtreg/tag-spec.html#testvars > > Ok, I see. > It looks like it was not used in the jtreg tests. > But maybe my grep was not consistent. Probably, it is used in the property form: " |test.timeout.factor". Thanks, Serguei | > > Thanks, > Serguei > >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/23/16 02:17, Staffan Larsen wrote: >>>> This is my second attempt at fixing this timeout by taking the >>>> jtreg timeout factor into account in the tests. The first fix [1] >>>> looked at the wrong environment variable, and also would have >>>> caused the test to run unnecessarily slow since it set >>>> sleep_seconds to a higher value instead of changing the timeout. >>>> >>>> In this version I have tried to fix these problems. I now look at >>>> the env variable TESTTIMEOUTFACTOR which will contain the jtreg >>>> timeout factor in floating point notation. Since it is easier to >>>> work with integers in shell scripts, I truncate this value using >>>> and awk expression. I then use this value to set up time limits in >>>> the two places where we have them. To simplify the code in the >>>> cmd() function, I no longer print out stack traces after half the >>>> timeLimit, only when the limit has expired. I think this is reasonable. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 >>>> webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan at larsen.se Tue May 24 07:08:54 2016 From: staffan at larsen.se (Staffan Larsen) Date: Tue, 24 May 2016 09:08:54 +0200 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: <5743FD84.90703@oracle.com> References: <57437881.3060901@oracle.com> <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> <5743FC5B.6080904@oracle.com> <5743FD84.90703@oracle.com> Message-ID: > On 24 maj 2016, at 09:06, serguei.spitsyn at oracle.com wrote: > > On 5/24/16 00:01, serguei.spitsyn at oracle.com wrote: >> On 5/23/16 23:35, Staffan Larsen wrote: >>> >>>> On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com wrote: >>>> >>>> Staffan, >>>> >>>> I do not see any issues, the fix looks good to me. >>> >>> Thanks! >>> >>>> One question though. >>>> >>>> Where does the TESTTIMEOUTFACTOR environment variable come from? >>>> I do not see it used anywhere in the jtreg tests. >>> >>> It is set by jtreg. See: http://openjdk.java.net/jtreg/tag-spec.html#testvars >> Ok, I see. >> It looks like it was not used in the jtreg tests. >> But maybe my grep was not consistent. > > Probably, it is used in the property form: " test.timeout.factor?. Yes, in Java tests it is used as the property. But in shell tests you have to use the environment variable. > > > Thanks, > Serguei > >> >> Thanks, >> Serguei >> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/23/16 02:17, Staffan Larsen wrote: >>>>> This is my second attempt at fixing this timeout by taking the jtreg timeout factor into account in the tests. The first fix [1] looked at the wrong environment variable, and also would have caused the test to run unnecessarily slow since it set sleep_seconds to a higher value instead of changing the timeout. >>>>> >>>>> In this version I have tried to fix these problems. I now look at the env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout factor in floating point notation. Since it is easier to work with integers in shell scripts, I truncate this value using and awk expression. I then use this value to set up time limits in the two places where we have them. To simplify the code in the cmd() function, I no longer print out stack traces after half the timeLimit, only when the limit has expired. I think this is reasonable. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 24 07:16:36 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 00:16:36 -0700 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: References: <57437881.3060901@oracle.com> <277C5DA4-678E-4F35-B783-7AF9B46BD6B8@larsen.se> <5743FC5B.6080904@oracle.com> <5743FD84.90703@oracle.com> Message-ID: <5743FFD4.3040000@oracle.com> On 5/24/16 00:08, Staffan Larsen wrote: > >> On 24 maj 2016, at 09:06, serguei.spitsyn at oracle.com >> wrote: >> >> On 5/24/16 00:01, serguei.spitsyn at oracle.com wrote: >>> On 5/23/16 23:35, Staffan Larsen wrote: >>>> >>>>> On 23 maj 2016, at 23:39, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Staffan, >>>>> >>>>> I do not see any issues, the fix looks good to me. >>>> >>>> Thanks! >>>> >>>>> One question though. >>>>> >>>>> Where does the TESTTIMEOUTFACTOR environment variable come from? >>>>> I do not see it used anywhere in the jtreg tests. >>>> >>>> It is set by jtreg. See: >>>> http://openjdk.java.net/jtreg/tag-spec.html#testvars >>> >>> Ok, I see. >>> It looks like it was not used in the jtreg tests. >>> But maybe my grep was not consistent. >> >> Probably, it is used in the property form: " |test.timeout.factor?. >> | > > Yes, in Java tests it is used as the property. But in shell tests you > have to use the environment variable. Agreed. Thanks, Serguei > >> | >> >> Thanks, >> Serguei >> | >>> >>> Thanks, >>> Serguei >>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 5/23/16 02:17, Staffan Larsen wrote: >>>>>> This is my second attempt at fixing this timeout by taking the >>>>>> jtreg timeout factor into account in the tests. The first fix [1] >>>>>> looked at the wrong environment variable, and also would have >>>>>> caused the test to run unnecessarily slow since it set >>>>>> sleep_seconds to a higher value instead of changing the timeout. >>>>>> >>>>>> In this version I have tried to fix these problems. I now look at >>>>>> the env variable TESTTIMEOUTFACTOR which will contain the jtreg >>>>>> timeout factor in floating point notation. Since it is easier to >>>>>> work with integers in shell scripts, I truncate this value using >>>>>> and awk expression. I then use this value to set up time limits >>>>>> in the two places where we have them. To simplify the code in the >>>>>> cmd() function, I no longer print out stack traces after half the >>>>>> timeLimit, only when the limit has expired. I think this is >>>>>> reasonable. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 >>>>>> webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue May 24 08:42:06 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 24 May 2016 11:42:06 +0300 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: References: Message-ID: <574413DE.3030101@oracle.com> Staffan, 37: It's better to write it as: timeout_factor=`echo $TESTTIMEOUTFACTOR | awk '{printf "%3.0f\n", $1}'` It uses the same synax as the rest of script and round value rather than truncate it. -Dmitry On 2016-05-23 12:17, Staffan Larsen wrote: > This is my second attempt at fixing this timeout by taking the jtreg > timeout factor into account in the tests. The first fix [1] looked at > the wrong environment variable, and also would have caused the test to > run unnecessarily slow since it set sleep_seconds to a higher value > instead of changing the timeout. > > In this version I have tried to fix these problems. I now look at the > env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout > factor in floating point notation. Since it is easier to work with > integers in shell scripts, I truncate this value using and awk > expression. I then use this value to set up time limits in the two > places where we have them. To simplify the code in the cmd() function, I > no longer print out stack traces after half the timeLimit, only when the > limit has expired. I think this is reasonable. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157555 > webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ > > Thanks, > /Staffan > > [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue May 24 09:00:38 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 24 May 2016 11:00:38 +0200 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: <574413DE.3030101@oracle.com> References: <574413DE.3030101@oracle.com> Message-ID: Yes, that would have been a little better. Unfortunately I have already pushed the change. Let me know if you think it is important enough to fix. /Staffan > On 24 maj 2016, at 10:42, Dmitry Samersoff wrote: > > Staffan, > > 37: It's better to write it as: > > timeout_factor=`echo $TESTTIMEOUTFACTOR | > awk '{printf "%3.0f\n", $1}'` > > It uses the same synax as the rest of script and round value rather than > truncate it. > > -Dmitry > > On 2016-05-23 12:17, Staffan Larsen wrote: >> This is my second attempt at fixing this timeout by taking the jtreg >> timeout factor into account in the tests. The first fix [1] looked at >> the wrong environment variable, and also would have caused the test to >> run unnecessarily slow since it set sleep_seconds to a higher value >> instead of changing the timeout. >> >> In this version I have tried to fix these problems. I now look at the >> env variable TESTTIMEOUTFACTOR which will contain the jtreg timeout >> factor in floating point notation. Since it is easier to work with >> integers in shell scripts, I truncate this value using and awk >> expression. I then use this value to set up time limits in the two >> places where we have them. To simplify the code in the cmd() function, I >> no longer print out stack traces after half the timeLimit, only when the >> limit has expired. I think this is reasonable. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 >> webrev: http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >> >> Thanks, >> /Staffan >> >> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue May 24 10:09:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 24 May 2016 13:09:08 +0300 Subject: RFR: 8157555 com/sun/jdi/RedefineClearBreakpoint.sh times out due to Indify String Concat being slow in debug mode In-Reply-To: References: <574413DE.3030101@oracle.com> Message-ID: <57442844.70006@oracle.com> Staffan, > Yes, that would have been a little better. Unfortunately I have > already pushed the change. Let me know if you think it is important > enough to fix. No, it's not so important. Sorry for being later. -Dmitry On 2016-05-24 12:00, Staffan Larsen wrote: > Yes, that would have been a little better. Unfortunately I have > already pushed the change. Let me know if you think it is important > enough to fix. > > /Staffan > >> On 24 maj 2016, at 10:42, Dmitry Samersoff >> wrote: >> >> Staffan, >> >> 37: It's better to write it as: >> >> timeout_factor=`echo $TESTTIMEOUTFACTOR | awk '{printf "%3.0f\n", >> $1}'` >> >> It uses the same synax as the rest of script and round value rather >> than truncate it. >> >> -Dmitry >> >> On 2016-05-23 12:17, Staffan Larsen wrote: >>> This is my second attempt at fixing this timeout by taking the >>> jtreg timeout factor into account in the tests. The first fix [1] >>> looked at the wrong environment variable, and also would have >>> caused the test to run unnecessarily slow since it set >>> sleep_seconds to a higher value instead of changing the timeout. >>> >>> In this version I have tried to fix these problems. I now look at >>> the env variable TESTTIMEOUTFACTOR which will contain the jtreg >>> timeout factor in floating point notation. Since it is easier to >>> work with integers in shell scripts, I truncate this value using >>> and awk expression. I then use this value to set up time limits >>> in the two places where we have them. To simplify the code in the >>> cmd() function, I no longer print out stack traces after half the >>> timeLimit, only when the limit has expired. I think this is >>> reasonable. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8157555 webrev: >>> http://cr.openjdk.java.net/~sla/8157555/webrev.00/ >>> >>> Thanks, /Staffan >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/5a553039e9fc >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From cheleswer.sahu at oracle.com Tue May 24 11:49:45 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 24 May 2016 04:49:45 -0700 (PDT) Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <1073c73e-dc90-410c-9774-eb1d758065e8@default> References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> <1073c73e-dc90-410c-9774-eb1d758065e8@default> Message-ID: Hi, ? I just wanted to let you know that since review there has been one new file added ??commandLineFlagWriteableList.cpp?, ?and this files also needs to be modified/updated for implementing ?diagnostic_pd?. This is just one additional change over what was reviewed before, ?so I am ?going ahead with this fix and need not a new review. I have tested this change and its working fine as before. ? Webrev link: http://cr.openjdk.java.net/~csahu/8150900/webrev.01/ ? Regards, Cheleswer ? From: Cheleswer Sahu Sent: Wednesday, May 11, 2016 2:29 PM To: Christian Thalinger Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd ? Thanks Christian for review. I will correct the alignment. ? Regards, Cheleswer ? From: Christian Thalinger Sent: Wednesday, May 11, 2016 1:00 AM To: Cheleswer Sahu Cc: Kevin Walls; Gerard Ziemski; 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]: 8150900: Implement diagnostic_pd ? src/share/vm/runtime/globals.hpp -? develop_pd(bool, ImplicitNullChecks,????????????????????????????????????? \ +? diagnostic_pd(bool, ImplicitNullChecks,????????????????????????????????????? \ ?????????? "Generate code for implicit null checks")???????? ????????????????\ Align the \ ? On May 10, 2016, at 1:47 AM, Cheleswer Sahu wrote: ? Hi, I need one reviewer (R) to review these changes before pushing in JDK9. ?Can somebody please review the changes. Regards, Cheleswer -----Original Message----- From: Kevin Walls Sent: Friday, May 06, 2016 3:53 PM To: Cheleswer Sahu; Gerard Ziemski Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; hotspot-runtime- HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd Thanks Cheleswer, looks good to me too, have been over the macros as much as I can! Thanks Kevin On 03/05/2016 07:34, Cheleswer Sahu wrote: Hi Gerard, -----Original Message----- From: Gerard Ziemski Sent: Monday, May 02, 2016 9:07 PM To: Cheleswer Sahu Cc: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; serviceability- HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd hi Cheleswer, #1 Shouldn?t the following files be modified as well? : open: src/cpu/sparc/vm/globals_sparc.hpp src/cpu/x86/vm/globals_x86.hpp src/cpu/zero/vm/globals_zero.hpp closed: cpu/arm/vm/globals_arm.hpp I have implemented ?"diagnostic_pd" using "product_pd" as a reference implementation. "product_pd" is not implemented for " ARCH_FLAGS ", therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" type. ? share/vm/runtime/globals_ext.hpp share/vm/runtime/os_ext.hpp These 2 files are under closed repository, so I have initiated a separate internal review request for those changes. ? #2 Bunch of header files need to be updated with 2016 for Copyright: /* - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. ?* ORACLE PROPRIETARY/CONFIDENTIAL. ?Use is subject to license terms. ?*/ I agree, I will update the copyright headers. #3 What tests have you run? Did you do: a) JPRT hotspot b) RBT hs-nightly-runtime I have run JPRT hostspot tests for this. It shows no error. Please email me if you need help with those. #4 Just heads up that I will be shortly asking for review of my fix (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches many of the same file, so one of us will have a tricky merge Thanks for informing about this. Regards, Cheleswer cheers On May 2, 2016, at 4:51 AM, Cheleswer Sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8150900. Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ Enhancement Brief: ?A new variant of flag "diagnostic_pd" is implemented. All flags which are diagnostic in nature and platform dependent can be placed under this variant. These flags can be enable using ?"- XX:+UnlockDiagnosticVMOptions". At present I have placed 4 flags under "diagnostic_pd" 1. ???????1. InitArrayShortSize 2. ???????2. ImplicitNullChecks 3. ???????3. InlineFrequencyCount 4. ???????4. PostLoopMultiversioning Regards, Cheleswer ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerard.ziemski at oracle.com Tue May 24 16:24:45 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 24 May 2016 11:24:45 -0500 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> <1073c73e-dc90-410c-9774-eb1d758065e8@default> Message-ID: hi Cheleswer, The change looks good. My understanding is that the jdk9 repo is now closed to features, so you will need an exception to push this fix - jesper.wilhelmsson at oracle.com told me yesterday that the process for that is not ready/documented yet. cheers > On May 24, 2016, at 6:49 AM, Cheleswer Sahu wrote: > > Hi, > > I just wanted to let you know that since review there has been one new file added ?commandLineFlagWriteableList.cpp?, and this files also needs to be modified/updated for implementing ?diagnostic_pd?. This is just one additional change over what was reviewed before, so I am going ahead with this fix and need not a new review. I have tested this change and its working fine as before. > > Webrev link: http://cr.openjdk.java.net/~csahu/8150900/webrev.01/ > > Regards, > Cheleswer > > From: Cheleswer Sahu > Sent: Wednesday, May 11, 2016 2:29 PM > To: Christian Thalinger > Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > Thanks Christian for review. I will correct the alignment. > > Regards, > Cheleswer > > From: Christian Thalinger > Sent: Wednesday, May 11, 2016 1:00 AM > To: Cheleswer Sahu > Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > src/share/vm/runtime/globals.hpp > > - develop_pd(bool, ImplicitNullChecks, \ > + diagnostic_pd(bool, ImplicitNullChecks, \ > "Generate code for implicit null checks") \ > Align the \ > > On May 10, 2016, at 1:47 AM, Cheleswer Sahu wrote: > > Hi, > I need one reviewer (R) to review these changes before pushing in JDK9. Can somebody please review the changes. > > Regards, > Cheleswer > > > -----Original Message----- > From: Kevin Walls > Sent: Friday, May 06, 2016 3:53 PM > To: Cheleswer Sahu; Gerard Ziemski > Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > > Thanks Cheleswer, looks good to me too, have been over the macros as > much as I can! > > Thanks > Kevin > > > > On 03/05/2016 07:34, Cheleswer Sahu wrote: > > Hi Gerard, > > > > -----Original Message----- > From: Gerard Ziemski > Sent: Monday, May 02, 2016 9:07 PM > To: Cheleswer Sahu > Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- > dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > > hi Cheleswer, > > > #1 Shouldn?t the following files be modified as well? : > > open: > > src/cpu/sparc/vm/globals_sparc.hpp > src/cpu/x86/vm/globals_x86.hpp > src/cpu/zero/vm/globals_zero.hpp > > closed: > > cpu/arm/vm/globals_arm.hpp > I have implemented "diagnostic_pd" using "product_pd" as a reference > implementation. "product_pd" is not implemented for " ARCH_FLAGS ", > therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" > type. > > > > share/vm/runtime/globals_ext.hpp > share/vm/runtime/os_ext.hpp > These 2 files are under closed repository, so I have initiated a separate > internal review request for those changes. > > > > > #2 Bunch of header files need to be updated with 2016 for Copyright: > > /* > - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. > * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > I agree, I will update the copyright headers. > > > #3 What tests have you run? Did you do: > > a) JPRT hotspot > b) RBT hs-nightly-runtime > > I have run JPRT hostspot tests for this. It shows no error. > > > Please email me if you need help with those. > > > #4 Just heads up that I will be shortly asking for review of my fix > (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches > many of the same file, so one of us will have a tricky merge > > Thanks for informing about this. > > > Regards, > Cheleswer > > > cheers > > > On May 2, 2016, at 4:51 AM, Cheleswer Sahu > wrote: > > Hi, > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8150900. > > > > Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ > > > > Enhancement Brief: A new variant of flag "diagnostic_pd" is > implemented. > > All flags which are diagnostic in nature and platform dependent can > be placed > > under this variant. These flags can be enable using "- > XX:+UnlockDiagnosticVMOptions". > > At present I have placed 4 flags under "diagnostic_pd" > > 1. 1. InitArrayShortSize > > 2. 2. ImplicitNullChecks > > 3. 3. InlineFrequencyCount > > 4. 4. PostLoopMultiversioning > > > > > > Regards, > > Cheleswer From kevin.walls at oracle.com Tue May 24 16:46:55 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 24 May 2016 17:46:55 +0100 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: References: <3047EF4D-C352-4F4A-905F-F332F03E0D45@oracle.com> <736d4731-1763-434a-99d2-376fbe01443d@default> <03d9a00a-0f88-e880-a86e-25412576bcc9@oracle.com> <0ffe1a86-18ce-462a-8f5d-7c31085aa819@default> <1073c73e-dc90-410c-9774-eb1d758065e8@default> Message-ID: <3c84643c-c10a-7eaa-d28e-83fa0ee037de@oracle.com> ...although we consider this a fix, more than a feature, and hope it isn't excluded from being pushed. --- Kevin On 24/05/2016 17:24, Gerard Ziemski wrote: > hi Cheleswer, > > The change looks good. > > My understanding is that the jdk9 repo is now closed to features, so you will need an exception to push this fix - jesper.wilhelmsson at oracle.com told me yesterday that the process for that is not ready/documented yet. > > > cheers > > >> On May 24, 2016, at 6:49 AM, Cheleswer Sahu wrote: >> >> Hi, >> >> I just wanted to let you know that since review there has been one new file added ?commandLineFlagWriteableList.cpp?, and this files also needs to be modified/updated for implementing ?diagnostic_pd?. This is just one additional change over what was reviewed before, so I am going ahead with this fix and need not a new review. I have tested this change and its working fine as before. >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8150900/webrev.01/ >> >> Regards, >> Cheleswer >> >> From: Cheleswer Sahu >> Sent: Wednesday, May 11, 2016 2:29 PM >> To: Christian Thalinger >> Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> Thanks Christian for review. I will correct the alignment. >> >> Regards, >> Cheleswer >> >> From: Christian Thalinger >> Sent: Wednesday, May 11, 2016 1:00 AM >> To: Cheleswer Sahu >> Cc: Kevin Walls; Gerard Ziemski; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> src/share/vm/runtime/globals.hpp >> >> - develop_pd(bool, ImplicitNullChecks, \ >> + diagnostic_pd(bool, ImplicitNullChecks, \ >> "Generate code for implicit null checks") \ >> Align the \ >> >> On May 10, 2016, at 1:47 AM, Cheleswer Sahu wrote: >> >> Hi, >> I need one reviewer (R) to review these changes before pushing in JDK9. Can somebody please review the changes. >> >> Regards, >> Cheleswer >> >> >> -----Original Message----- >> From: Kevin Walls >> Sent: Friday, May 06, 2016 3:53 PM >> To: Cheleswer Sahu; Gerard Ziemski >> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> >> Thanks Cheleswer, looks good to me too, have been over the macros as >> much as I can! >> >> Thanks >> Kevin >> >> >> >> On 03/05/2016 07:34, Cheleswer Sahu wrote: >> >> Hi Gerard, >> >> >> >> -----Original Message----- >> From: Gerard Ziemski >> Sent: Monday, May 02, 2016 9:07 PM >> To: Cheleswer Sahu >> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability- >> dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd >> >> hi Cheleswer, >> >> >> #1 Shouldn?t the following files be modified as well? : >> >> open: >> >> src/cpu/sparc/vm/globals_sparc.hpp >> src/cpu/x86/vm/globals_x86.hpp >> src/cpu/zero/vm/globals_zero.hpp >> >> closed: >> >> cpu/arm/vm/globals_arm.hpp >> I have implemented "diagnostic_pd" using "product_pd" as a reference >> implementation. "product_pd" is not implemented for " ARCH_FLAGS ", >> therefore I have also not implemented "diagnostic_pd" for "ARCH_FLAGS" >> type. >> >> >> >> share/vm/runtime/globals_ext.hpp >> share/vm/runtime/os_ext.hpp >> These 2 files are under closed repository, so I have initiated a separate >> internal review request for those changes. >> >> >> >> >> #2 Bunch of header files need to be updated with 2016 for Copyright: >> >> /* >> - * Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. >> * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. >> */ >> >> I agree, I will update the copyright headers. >> >> >> #3 What tests have you run? Did you do: >> >> a) JPRT hotspot >> b) RBT hs-nightly-runtime >> >> I have run JPRT hostspot tests for this. It shows no error. >> >> >> Please email me if you need help with those. >> >> >> #4 Just heads up that I will be shortly asking for review of my fix >> (https://bugs.openjdk.java.net/browse/JDK-8073500), which touches >> many of the same file, so one of us will have a tricky merge >> >> Thanks for informing about this. >> >> >> Regards, >> Cheleswer >> >> >> cheers >> >> >> On May 2, 2016, at 4:51 AM, Cheleswer Sahu >> wrote: >> >> Hi, >> >> >> >> Please review the code changes for >> https://bugs.openjdk.java.net/browse/JDK-8150900. >> >> >> >> Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ >> >> >> >> Enhancement Brief: A new variant of flag "diagnostic_pd" is >> implemented. >> >> All flags which are diagnostic in nature and platform dependent can >> be placed >> >> under this variant. These flags can be enable using "- >> XX:+UnlockDiagnosticVMOptions". >> >> At present I have placed 4 flags under "diagnostic_pd" >> >> 1. 1. InitArrayShortSize >> >> 2. 2. ImplicitNullChecks >> >> 3. 3. InlineFrequencyCount >> >> 4. 4. PostLoopMultiversioning >> >> >> >> >> >> Regards, >> >> Cheleswer From daniel.daugherty at oracle.com Tue May 24 22:46:24 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 May 2016 16:46:24 -0600 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <082eb574-6db8-1d76-9f8a-4579fd31a1b5@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> <74dbcc5e-7de2-2675-0623-fb8f0e5d459a@oracle.com> <082eb574-6db8-1d76-9f8a-4579fd31a1b5@oracle.com> Message-ID: <825cdf65-3b47-ad4a-f921-d05a47b3cb12@oracle.com> Finally caught up on this thread. The change looks great. I don't see any locking issues with this fix. Dan On 5/16/16 3:42 PM, Coleen Phillimore wrote: > > Thank you, David! > Coleen > > On 5/16/16 4:59 PM, David Holmes wrote: >> Looks good! >> >> Thanks, >> David >> >> On 17/05/2016 2:28 AM, Coleen Phillimore wrote: >>> >>> David, Thank you for looking at this change. >>> >>> On 5/15/16 9:51 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>>>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>>>> Summary: lock classes for redefinition because constant pool merging >>>>> isn't thread safe, use method constant pool because constant pool >>>>> merging doesn't make equivalent cpCaches because of invokedynamic >>>>> >>>>> I had to make these changes together. See bugs for more details. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >>>> >>>> In general the locking approach seems okay - as long as all mutating >>>> actions on the constantpool are being guarded with this locking. >>>> >>>> But I'm concerned that you are using a bit in _misc_flags for this >>>> mutable state. It isn't clear to me when the other bits in _misc_flags >>>> might be set but I'm assuming only during initial class parsing, or >>>> some other single-threaded use? Putting a mutable bit into such a flag >>>> set is fragile and can only be done once. >>> >>> I was uneasy about this too. Most of the _misc_flags are set during >>> initialization but there are a couple that are set while the vm is >>> running. I moved _is_being_redefined to a bool sized gap just about >>> the _misc_flags, which makes me more confident of the state of this >>> field when doing locking. >>> >>> Retesting this small change with StressRedefine in a loop. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> >>> > > From daniel.daugherty at oracle.com Tue May 24 23:23:05 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 May 2016 17:23:05 -0600 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <570F53B1.90809@oracle.com> References: <570F53B1.90809@oracle.com> Message-ID: <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> > Testing: > Altered the nsk.jvmti co-located test nsk/jvmti/ClassFileLoadHook/classfloadhk002 > to enable the can_generate_early_class_hook_events and checked that new CFLH events > are posted in the primordial phase and also they are not posted otherwise. Sorry for looping back on this... I've been re-reading this thread off and on for a while now... I'm okay with this part of the testing statement: > checked that new CFLH events are posted in the primordial phase but this part bothers me: > and also they are not posted otherwise I'm not sure what that last part means exactly. I think it might be saying that there are certain CFLH events that the test expects to be posted in the primordial phase and the test verifies that those CFLH events are posted in the primordial phase and not in the next phase (the start phase). I'm hoping that the testable assertion is more clear than the above text. One other possible issue: if the primordial phase is still single threaded, then there is no race between a thread doing this early class loading (and posting of the CFLH events) and the thread that is changing the JVM/TI phase from "primordial phase" to "start phase". However, if the primordial phase is now multi-threaded, then there might be a race between the thread posting the CFLH event and JVM/TI phase switch... Dan On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw-related fix for: > https://bugs.openjdk.java.net/browse/JDK-8153749 > > > Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ > > > > Summary: > > This is a Jigsaw related enhancement. > Some agents need to get a CFLH event for classes loaded in the > primordial phase. > This is not possible in JDK 9 because existing agents may > instrument code in the > primordial or start phase before the module system has completed > initialization. > > We introduce a new capability: can_generate_early_class_hook_events. > If this capability and can_generate_all_class_hook_events are > enabled then > the CFLH event could be posted for classes loaded in the primordial > phase. > We leave can_generate_early_vmstart as is, no changes. > > This enhancement needs a CCC request filed. > I will file it once the JVMTI spec changes are reviewed. > > > Testing: > Altered the nsk.jvmti co-located test > nsk/jvmti/ClassFileLoadHook/classfloadhk002 > to enable the can_generate_early_class_hook_events and checked that > new CFLH events > are posted in the primordial phase and also they are not posted > otherwise. > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Wed May 25 00:03:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 17:03:18 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> Message-ID: <5744EBC6.9070105@oracle.com> On 5/24/16 16:23, Daniel D. Daugherty wrote: > > Testing: > > Altered the nsk.jvmti co-located test > nsk/jvmti/ClassFileLoadHook/classfloadhk002 > > to enable the can_generate_early_class_hook_events and checked > that new CFLH events > > are posted in the primordial phase and also they are not posted > otherwise. > > Sorry for looping back on this... > > I've been re-reading this thread off and on for a while now... > > I'm okay with this part of the testing statement: > > > checked that new CFLH events are posted in the primordial phase > > but this part bothers me: > > > and also they are not posted otherwise > > I'm not sure what that last part means exactly. I think it might > be saying that there are certain CFLH events that the test expects > to be posted in the primordial phase and the test verifies that > those CFLH events are posted in the primordial phase and not in > the next phase (the start phase). I'm hoping that the testable > assertion is more clear than the above text. Dan, sorry that my statement above is not clear. The 'otherwise' means the same test but unaltered. Unaltered test does not enable new capability and so, the CFLH events should not be posted in the primordial phase. > > One other possible issue: if the primordial phase is still > single threaded, then there is no race between a thread doing > this early class loading (and posting of the CFLH events) and > the thread that is changing the JVM/TI phase from "primordial > phase" to "start phase". However, if the primordial phase is > now multi-threaded, then there might be a race between the > thread posting the CFLH event and JVM/TI phase switch... This is interesting observation, thanks. Why do you think the primordial thread is multi-threaded now? We have this kind of race problem in general, especially with the JVM/TI phase switch to the DEAD phase. The phase can be switched even in the middle of the event post. I'm currently looking at several bugs related to JVMTI_ERROR_WRONG_PHASE(112). This problem needs a good solution, at least to make the nightly testing stable. Thanks, Serguei > > Dan > > > On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw-related fix for: >> https://bugs.openjdk.java.net/browse/JDK-8153749 >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >> >> >> >> Summary: >> >> This is a Jigsaw related enhancement. >> Some agents need to get a CFLH event for classes loaded in the >> primordial phase. >> This is not possible in JDK 9 because existing agents may >> instrument code in the >> primordial or start phase before the module system has completed >> initialization. >> >> We introduce a new capability: can_generate_early_class_hook_events. >> If this capability and can_generate_all_class_hook_events are >> enabled then >> the CFLH event could be posted for classes loaded in the >> primordial phase. >> We leave can_generate_early_vmstart as is, no changes. >> >> This enhancement needs a CCC request filed. >> I will file it once the JVMTI spec changes are reviewed. >> >> >> Testing: >> Altered the nsk.jvmti co-located test >> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >> to enable the can_generate_early_class_hook_events and checked >> that new CFLH events >> are posted in the primordial phase and also they are not posted >> otherwise. >> >> >> Thanks, >> Serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed May 25 00:24:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 May 2016 18:24:59 -0600 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <5744EBC6.9070105@oracle.com> References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> <5744EBC6.9070105@oracle.com> Message-ID: On 5/24/16 6:03 PM, serguei.spitsyn at oracle.com wrote: > On 5/24/16 16:23, Daniel D. Daugherty wrote: >> > Testing: >> > Altered the nsk.jvmti co-located test >> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >> > to enable the can_generate_early_class_hook_events and checked >> that new CFLH events >> > are posted in the primordial phase and also they are not posted >> otherwise. >> >> Sorry for looping back on this... >> >> I've been re-reading this thread off and on for a while now... >> >> I'm okay with this part of the testing statement: >> >> > checked that new CFLH events are posted in the primordial phase >> >> but this part bothers me: >> >> > and also they are not posted otherwise >> >> I'm not sure what that last part means exactly. I think it might >> be saying that there are certain CFLH events that the test expects >> to be posted in the primordial phase and the test verifies that >> those CFLH events are posted in the primordial phase and not in >> the next phase (the start phase). I'm hoping that the testable >> assertion is more clear than the above text. > > Dan, sorry that my statement above is not clear. > The 'otherwise' means the same test but unaltered. > Unaltered test does not enable new capability and so, the CFLH events > should not be posted in the primordial phase. Got it. I'm good with a test to verify that the older JVM/TI behavior works as expected along with a test for the newer behavior. > >> >> One other possible issue: if the primordial phase is still >> single threaded, then there is no race between a thread doing >> this early class loading (and posting of the CFLH events) and >> the thread that is changing the JVM/TI phase from "primordial >> phase" to "start phase". However, if the primordial phase is >> now multi-threaded, then there might be a race between the >> thread posting the CFLH event and JVM/TI phase switch... > > This is interesting observation, thanks. > Why do you think the primordial thread is multi-threaded now? I haven't been paying close attention to Jigsaw so I'm not sure if primordial phase is multi-threaded or not... > We have this kind of race problem in general, especially > with the JVM/TI phase switch to the DEAD phase. > The phase can be switched even in the middle of the event post. > I'm currently looking at several bugs related to > JVMTI_ERROR_WRONG_PHASE(112). > This problem needs a good solution, at least to make the nightly > testing stable. Yes, I'm well aware of that problem. I believe I've made a number of comments on various JVMTI_ERROR_WRONG_PHASE bugs over the years. It's going to need some sort of handshake to solve it. Much like the suspend/resume dance that we do on thread exit... We'll have to brainstorm on how to make things more robust... Dan > > > Thanks, > Serguei > > >> >> Dan >> >> >> On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw-related fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8153749 >>> >>> >>> Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >>> >>> >>> Jdk webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >>> >>> >>> >>> Summary: >>> >>> This is a Jigsaw related enhancement. >>> Some agents need to get a CFLH event for classes loaded in the >>> primordial phase. >>> This is not possible in JDK 9 because existing agents may >>> instrument code in the >>> primordial or start phase before the module system has completed >>> initialization. >>> >>> We introduce a new capability: can_generate_early_class_hook_events. >>> If this capability and can_generate_all_class_hook_events are >>> enabled then >>> the CFLH event could be posted for classes loaded in the >>> primordial phase. >>> We leave can_generate_early_vmstart as is, no changes. >>> >>> This enhancement needs a CCC request filed. >>> I will file it once the JVMTI spec changes are reviewed. >>> >>> >>> Testing: >>> Altered the nsk.jvmti co-located test >>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>> to enable the can_generate_early_class_hook_events and checked >>> that new CFLH events >>> are posted in the primordial phase and also they are not posted >>> otherwise. >>> >>> >>> Thanks, >>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed May 25 01:09:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 18:09:20 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> <5744EBC6.9070105@oracle.com> Message-ID: <5744FB40.1020708@oracle.com> On 5/24/16 17:24, Daniel D. Daugherty wrote: > On 5/24/16 6:03 PM, serguei.spitsyn at oracle.com wrote: >> On 5/24/16 16:23, Daniel D. Daugherty wrote: >>> > Testing: >>> > Altered the nsk.jvmti co-located test >>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>> > to enable the can_generate_early_class_hook_events and checked >>> that new CFLH events >>> > are posted in the primordial phase and also they are not posted >>> otherwise. >>> >>> Sorry for looping back on this... >>> >>> I've been re-reading this thread off and on for a while now... >>> >>> I'm okay with this part of the testing statement: >>> >>> > checked that new CFLH events are posted in the primordial phase >>> >>> but this part bothers me: >>> >>> > and also they are not posted otherwise >>> >>> I'm not sure what that last part means exactly. I think it might >>> be saying that there are certain CFLH events that the test expects >>> to be posted in the primordial phase and the test verifies that >>> those CFLH events are posted in the primordial phase and not in >>> the next phase (the start phase). I'm hoping that the testable >>> assertion is more clear than the above text. >> >> Dan, sorry that my statement above is not clear. >> The 'otherwise' means the same test but unaltered. >> Unaltered test does not enable new capability and so, the CFLH events >> should not be posted in the primordial phase. > > Got it. I'm good with a test to verify that the older JVM/TI > behavior works as expected along with a test for the newer > behavior. > > >> >>> >>> One other possible issue: if the primordial phase is still >>> single threaded, then there is no race between a thread doing >>> this early class loading (and posting of the CFLH events) and >>> the thread that is changing the JVM/TI phase from "primordial >>> phase" to "start phase". However, if the primordial phase is >>> now multi-threaded, then there might be a race between the >>> thread posting the CFLH event and JVM/TI phase switch... >> >> This is interesting observation, thanks. >> Why do you think the primordial thread is multi-threaded now? > > I haven't been paying close attention to Jigsaw so I'm not sure > if primordial phase is multi-threaded or not... I can be wrong but ... My current understanding is that it is still single-threaded as I did not see any discussions or related changes in the code. > > >> We have this kind of race problem in general, especially >> with the JVM/TI phase switch to the DEAD phase. >> The phase can be switched even in the middle of the event post. >> I'm currently looking at several bugs related to >> JVMTI_ERROR_WRONG_PHASE(112). >> This problem needs a good solution, at least to make the nightly >> testing stable. > > Yes, I'm well aware of that problem. I believe I've made a number > of comments on various JVMTI_ERROR_WRONG_PHASE bugs over the years. > It's going to need some sort of handshake to solve it. Much like > the suspend/resume dance that we do on thread exit... > > We'll have to brainstorm on how to make things more robust... Great, thanks! I've already started thinking on this. :) Thanks, Serguei > > Dan > > >> >> >> Thanks, >> Serguei >> >> >>> >>> Dan >>> >>> >>> On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the Jigsaw-related fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8153749 >>>> >>>> >>>> Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >>>> >>>> >>>> Jdk webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> This is a Jigsaw related enhancement. >>>> Some agents need to get a CFLH event for classes loaded in the >>>> primordial phase. >>>> This is not possible in JDK 9 because existing agents may >>>> instrument code in the >>>> primordial or start phase before the module system has completed >>>> initialization. >>>> >>>> We introduce a new capability: >>>> can_generate_early_class_hook_events. >>>> If this capability and can_generate_all_class_hook_events are >>>> enabled then >>>> the CFLH event could be posted for classes loaded in the >>>> primordial phase. >>>> We leave can_generate_early_vmstart as is, no changes. >>>> >>>> This enhancement needs a CCC request filed. >>>> I will file it once the JVMTI spec changes are reviewed. >>>> >>>> >>>> Testing: >>>> Altered the nsk.jvmti co-located test >>>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>>> to enable the can_generate_early_class_hook_events and checked >>>> that new CFLH events >>>> are posted in the primordial phase and also they are not posted >>>> otherwise. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 25 05:05:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 15:05:58 +1000 Subject: (S) RFR: 8154589: assert(k != NULL) failed: preloaded klass not initialized Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8154589 webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/ We sometimes see tests failing with a VM assertion failure that a klass was not loaded (the actual assertion message is wrong): # assert(k != NULL) failed: preloaded klass not initialized Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570, free space=1013k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937 V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const char*,const char*)+0x55f V [libjvm.so+0x28937e5] void ConcurrentLocksDump::dump_at_safepoint()+0x43d V [libjvm.so+0x287ab7e] void Threads::print_on(outputStream*,bool,bool,bool)+0xcce V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5 In a few of the VMOperation doit_prologue methods we have this logic to ensure the AOS class is loaded: java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current()); but we don't check if the class actually was successfully loaded! We may have an exception pending due to OOME for example. Because the prologue returns true, the VMOp is posted for the VMThread to execute and when doit() accesses the class that was presumed loaded by the prologue we get NULL and hit the assertion. Simple fix is to just return false if an exception is pending. Testing: jprt, tmtools tests (in progress) Thanks, David From serguei.spitsyn at oracle.com Wed May 25 05:41:19 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 22:41:19 -0700 Subject: (S) RFR: 8154589: assert(k != NULL) failed: preloaded klass not initialized In-Reply-To: References: Message-ID: <57453AFF.4060508@oracle.com> David, It looks good. Thanks, Serguei On 5/24/16 22:05, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8154589 > > webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/ > > We sometimes see tests failing with a VM assertion failure that a > klass was not loaded (the actual assertion message is wrong): > > # assert(k != NULL) failed: preloaded klass not initialized > > Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570, > free space=1013k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937 > V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f > V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const > char*,const char*)+0x55f > V [libjvm.so+0x28937e5] void > ConcurrentLocksDump::dump_at_safepoint()+0x43d > V [libjvm.so+0x287ab7e] void > Threads::print_on(outputStream*,bool,bool,bool)+0xcce > V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b > V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5 > > > In a few of the VMOperation doit_prologue methods we have this logic > to ensure the AOS class is loaded: > > java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current()); > > > but we don't check if the class actually was successfully loaded! We > may have an exception pending due to OOME for example. Because the > prologue returns true, the VMOp is posted for the VMThread to execute > and when doit() accesses the class that was presumed loaded by the > prologue we get NULL and hit the assertion. > > Simple fix is to just return false if an exception is pending. > > Testing: jprt, tmtools tests (in progress) > > Thanks, > David From david.holmes at oracle.com Wed May 25 05:42:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 15:42:38 +1000 Subject: (S) RFR: 8154589: assert(k != NULL) failed: preloaded klass not initialized In-Reply-To: <57453AFF.4060508@oracle.com> References: <57453AFF.4060508@oracle.com> Message-ID: <8aae0fec-4145-0666-e3de-ea8005d2a048@oracle.com> Thanks Serguei! David On 25/05/2016 3:41 PM, serguei.spitsyn at oracle.com wrote: > David, > > It looks good. > > Thanks, > Serguei > > > On 5/24/16 22:05, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154589 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/ >> >> We sometimes see tests failing with a VM assertion failure that a >> klass was not loaded (the actual assertion message is wrong): >> >> # assert(k != NULL) failed: preloaded klass not initialized >> >> Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570, >> free space=1013k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937 >> V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f >> V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const >> char*,const char*)+0x55f >> V [libjvm.so+0x28937e5] void >> ConcurrentLocksDump::dump_at_safepoint()+0x43d >> V [libjvm.so+0x287ab7e] void >> Threads::print_on(outputStream*,bool,bool,bool)+0xcce >> V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b >> V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5 >> >> >> In a few of the VMOperation doit_prologue methods we have this logic >> to ensure the AOS class is loaded: >> >> java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current()); >> >> >> but we don't check if the class actually was successfully loaded! We >> may have an exception pending due to OOME for example. Because the >> prologue returns true, the VMOp is posted for the VMThread to execute >> and when doit() accesses the class that was presumed loaded by the >> prologue we get NULL and hit the assertion. >> >> Simple fix is to just return false if an exception is pending. >> >> Testing: jprt, tmtools tests (in progress) >> >> Thanks, >> David > From david.holmes at oracle.com Wed May 25 08:32:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 18:32:03 +1000 Subject: (S) RFR: 8154589: assert(k != NULL) failed: preloaded klass not initialized In-Reply-To: References: Message-ID: <4e19f254-2bfa-bb3c-c0a5-b77b7330b5c5@oracle.com> On 25/05/2016 3:05 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8154589 > > webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/ > > We sometimes see tests failing with a VM assertion failure that a klass > was not loaded (the actual assertion message is wrong): > > # assert(k != NULL) failed: preloaded klass not initialized > > Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570, > free space=1013k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937 > V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f > V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const > char*,const char*)+0x55f > V [libjvm.so+0x28937e5] void ConcurrentLocksDump::dump_at_safepoint()+0x43d > V [libjvm.so+0x287ab7e] void > Threads::print_on(outputStream*,bool,bool,bool)+0xcce > V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b > V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5 > > > In a few of the VMOperation doit_prologue methods we have this logic to > ensure the AOS class is loaded: > > java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current()); > > > but we don't check if the class actually was successfully loaded! We may > have an exception pending due to OOME for example. Because the prologue > returns true, the VMOp is posted for the VMThread to execute and when > doit() accesses the class that was presumed loaded by the prologue we > get NULL and hit the assertion. > > Simple fix is to just return false if an exception is pending. > > Testing: jprt, tmtools tests (in progress) Strike the tmtools part - they don't even seem to run the test that was failing any more. David > Thanks, > David From yasuenag at gmail.com Wed May 25 11:58:25 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 25 May 2016 20:58:25 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <1c38c514-88b6-5252-f3ca-21852bd86559@gmail.com> References: <56FA6EC9.90107@gmail.com> <5703DA35.2070408@oracle.com> <570485B0.70200@gmail.com> <570E3989.1090305@gmail.com> <570E3E5D.9030801@oracle.com> <570E4832.9040701@gmail.com> <571772BE.3030403@gmail.com> <57177463.8060003@oracle.com> <572C8C81.9010903@oracle.com> <2d5c92ad-6891-1c7c-0c7c-eb68c79b6cac@gmail.com> <1c38c514-88b6-5252-f3ca-21852bd86559@gmail.com> Message-ID: Hi Dmitry, >>> I understand the problem, but I'm concerned of storing pointers to >>> invalid memory region just for coredump. Sorry! The latest webrev [1] holds pointers for PerfMemory in _saved_* fields. These pointers are valid because they are not unmap'ed. I think that it is a bug not to parse PerfMemory in coredump. SA tools should be able to handle data in coredump. Can we fix this issue? Thanks, Yasumasa [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ On 2016/05/06 22:39, Yasumasa Suenaga wrote: > Dmitry, > >>> The solution might be in another areas, e.g. print value of performance >>> counters to hs_err.log on crash. >> >> If so, we have to use native debugger. >> For Java developers and troubleshooters, I want to support this feature >> with JDK tool. > > If we encounter native stack overflow error, we cannot get hs_err log. > I posted a bug report for this issue as JDK-7109520, but it was rejected. > > In all crash case, we might collect core image. > If I collect it, I want to check performance counter in it. > > Thus I want to merge this patch to JDK 9. > Is it difficult? > > > Thanks, > > Yasumasa > > > On 2016/05/06 21:42, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> On 2016/05/06 21:22, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> I understand the problem, but I'm concerned of storing pointers to >>> invalid memory region just for coredump. Sorry! >> >> I do not think that it is NOT invalid memory in webrev.02 . >> PerfMemory is mmap'ed, and it is not unmap'ed. >> >> In addition, webrev.02 adds several pointers to store addresses which are >> related to PerfMemory. >> It is not disruptive against current memory management which is related to >> PerfMemory. >> >> Coredump will include all virtual memory and thread contexts. >> If pointers ( _saved_* in webrev.02) are invalid, it is not affect JVM behavior, >> but JSnap will fail. >> (This pointer is referred from JSnap only.) >> >> >>> The solution might be in another areas, e.g. print value of performance >>> counters to hs_err.log on crash. >> >> If so, we have to use native debugger. >> For Java developers and troubleshooters, I want to support this feature >> with JDK tool. >> >> >> Thanks, >> >> Yasumasa >> >> >>> -Dmitry >>> >>> >>> On 2016-05-06 14:42, Yasumasa Suenaga wrote: >>>> PING: Have you ever reviewed it? >>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>> >>>> I've sent review request to parse core image with JSnap. >>>> If you have unclear point about this change, please tell me. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/20 21:21, Dmitry Samersoff wrote: >>>>> Yasumasa, >>>>> >>>>> I need some more time to check what is happening with performance >>>>> counters and what side effect this fix can have. >>>>> >>>>> Sorry about it. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2016-04-20 15:14, Yasumasa Suenaga wrote: >>>>>> PING: Could you review it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>>>> >>>>>> This changes is based on jdk9/hs-rt. >>>>>> But I confirmed this patch works fine on jdk9/hs . >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/13 22:22, Yasumasa Suenaga wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> Thank you for your comment. >>>>>>> I uploaded new webrev. Could you review again? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/13 21:41, Dmitry Samersoff wrote: >>>>>>>> Yasumasa, >>>>>>>> >>>>>>>> Yes. It's better. >>>>>>>> >>>>>>>> Please place all _saved_* declarations together and add a comment >>>>>>>> explaining what is the purpose of this variables. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2016-04-13 15:20, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could you review and sponsor it? >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>>>> >>>>>>>>> If it is not accepted, I think that we can add new field to >>>>>>>>> PerfMemory >>>>>>>>> for using in JSnap: >>>>>>>>> ----------------------- >>>>>>>>> diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp >>>>>>>>> --- a/src/share/vm/runtime/perfMemory.cpp Tue Apr 12 09:08:48 >>>>>>>>> 2016 +0000 >>>>>>>>> +++ b/src/share/vm/runtime/perfMemory.cpp Wed Apr 13 14:18:15 >>>>>>>>> 2016 +0900 >>>>>>>>> @@ -45,11 +45,16 @@ >>>>>>>>> UINT_CHARS + 1; >>>>>>>>> >>>>>>>>> char* PerfMemory::_start = NULL; >>>>>>>>> +char* PerfMemory::_saved_start = NULL; >>>>>>>>> char* PerfMemory::_end = NULL; >>>>>>>>> +char* PerfMemory::_saved_end = NULL; >>>>>>>>> char* PerfMemory::_top = NULL; >>>>>>>>> +char* PerfMemory::_saved_top = NULL; >>>>>>>>> size_t PerfMemory::_capacity = 0; >>>>>>>>> +size_t PerfMemory::_saved_capacity = 0; >>>>>>>>> jint PerfMemory::_initialized = false; >>>>>>>>> PerfDataPrologue* PerfMemory::_prologue = NULL; >>>>>>>>> +PerfDataPrologue* PerfMemory::_saved_prologue = NULL; >>>>>>>>> >>>>>>>>> void perfMemory_init() { >>>>>>>>> >>>>>>>>> @@ -103,6 +108,8 @@ >>>>>>>>> >>>>>>>>> // allocate PerfData memory region >>>>>>>>> create_memory_region(capacity); >>>>>>>>> + _saved_start = _start; >>>>>>>>> + _saved_capacity = _capacity; >>>>>>>>> >>>>>>>>> if (_start == NULL) { >>>>>>>>> >>>>>>>>> @@ -132,8 +139,11 @@ >>>>>>>>> } >>>>>>>>> >>>>>>>>> _prologue = (PerfDataPrologue *)_start; >>>>>>>>> + _saved_prologue = _prologue; >>>>>>>>> _end = _start + _capacity; >>>>>>>>> + _saved_end = _end; >>>>>>>>> _top = _start + sizeof(PerfDataPrologue); >>>>>>>>> + _saved_top = _top; >>>>>>>>> } >>>>>>>>> >>>>>>>>> assert(_prologue != NULL, "prologue pointer must be >>>>>>>>> initialized"); >>>>>>>>> ----------------------- >>>>>>>>> >>>>>>>>> If it is better, I will upload a webrev. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/06 12:42, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> Thanks for your comment. >>>>>>>>>> >>>>>>>>>> I uploaded a new webrev. Could you review again? >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ >>>>>>>>>> >>>>>>>>>> On 2016/04/06 0:31, Dmitry Samersoff wrote: >>>>>>>>>>> Yasumasa, >>>>>>>>>>> >>>>>>>>>>> 1. It's better to change JSnap code to produce meaningful error >>>>>>>>>>> message >>>>>>>>>>> instead of NPE. >>>>>>>>>> >>>>>>>>>> I added null check and set message to PerfMemory.java . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 2. We should check that no other consumer of perf counters rely on >>>>>>>>>>> the >>>>>>>>>>> fact it's NULL after call to destroy(). I'm not sure that this >>>>>>>>>>> part of >>>>>>>>>>> the fix is not dangerous. >>>>>>>>>> >>>>>>>>>> I added new flag (_destroyed) in PerfMemory class. >>>>>>>>>> This flag set true at PerfMemory::destroy(). >>>>>>>>>> >>>>>>>>>> _start, _end, and more field which I removed from destroy() are >>>>>>>>>> private member of >>>>>>>>>> PerfMemory. I implemented that the getter functions of them check >>>>>>>>>> _destroyed flag, >>>>>>>>>> and returns same value before this change. >>>>>>>>>> >>>>>>>>>> So I think this change does not affect other place. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> On 2016-03-29 15:02, Yasumasa Suenaga wrote: >>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/03/22 21:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> 2016/03/14 23:39 "Yasumasa Suenaga" >>>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> When I use `jhsdb jsnap` to get PerfCounter from core >>>>>>>>>>>>> images, I >>>>>>>>>>>>> encountered NPE: >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> Exception in thread "main" java.lang.NullPointerException >>>>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >>>>>>>>>>>>> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >>>>>>>>>>>>> at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) >>>>>>>>>>>>> at >>>>>>>>>>>>> sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> >>>>>>>>>>>>> PerfMemory::destroy() clears all members which are used in >>>>>>>>>>>>> JSnap. >>>>>>>>>>>>> Thus NPE is occurred. >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded webrev for this issue. >>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> I cannot access JPRT. >>>>>>>>>>>>> So I need a Sponsor. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>> >>> From david.holmes at oracle.com Wed May 25 21:17:37 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 May 2016 07:17:37 +1000 Subject: (S) RFR: 8154589: assert(k != NULL) failed: preloaded klass not initialized In-Reply-To: <4e19f254-2bfa-bb3c-c0a5-b77b7330b5c5@oracle.com> References: <4e19f254-2bfa-bb3c-c0a5-b77b7330b5c5@oracle.com> Message-ID: <33847f97-05d3-7fc7-96a8-6c58c25be37e@oracle.com> Can I get a second review please. Thanks, David On 25/05/2016 6:32 PM, David Holmes wrote: > On 25/05/2016 3:05 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154589 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/ >> >> We sometimes see tests failing with a VM assertion failure that a klass >> was not loaded (the actual assertion message is wrong): >> >> # assert(k != NULL) failed: preloaded klass not initialized >> >> Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570, >> free space=1013k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937 >> V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f >> V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const >> char*,const char*)+0x55f >> V [libjvm.so+0x28937e5] void >> ConcurrentLocksDump::dump_at_safepoint()+0x43d >> V [libjvm.so+0x287ab7e] void >> Threads::print_on(outputStream*,bool,bool,bool)+0xcce >> V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b >> V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5 >> >> >> In a few of the VMOperation doit_prologue methods we have this logic to >> ensure the AOS class is loaded: >> >> java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current()); >> >> >> >> but we don't check if the class actually was successfully loaded! We may >> have an exception pending due to OOME for example. Because the prologue >> returns true, the VMOp is posted for the VMThread to execute and when >> doit() accesses the class that was presumed loaded by the prologue we >> get NULL and hit the assertion. >> >> Simple fix is to just return false if an exception is pending. >> >> Testing: jprt, tmtools tests (in progress) > > Strike the tmtools part - they don't even seem to run the test that was > failing any more. > > David > > >> Thanks, >> David From dmitry.samersoff at oracle.com Thu May 26 12:12:11 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 26 May 2016 15:12:11 +0300 Subject: RFR(S): JDK-8152950 BasicLauncherTest.java fails due to type error Message-ID: <5746E81B.6080902@oracle.com> Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8152950/webrev.03/ This fix cleanup the test and improve error handling in CLHSDB launcher. The root of the problem is that in modular world nashhorn can't access module internal packages ever if they are public. (see details in bug report). Complete fix requires significant efforts and it will be done under separate CR (JDK-8157947). -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From j.bachorik at gmail.com Thu May 26 16:52:08 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Thu, 26 May 2016 18:52:08 +0200 Subject: RFR(S): JDK-8152950 BasicLauncherTest.java fails due to type error In-Reply-To: <5746E81B.6080902@oracle.com> References: <5746E81B.6080902@oracle.com> Message-ID: Hi Dmitry, # http://cr.openjdk.java.net/~dsamersoff/JDK-8152950/webrev.03/hotspot_webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html L1752 - wording 'some commands is not available' -> 'some commands will not be available' # http://cr.openjdk.java.net/~dsamersoff/JDK-8152950/webrev.03/jdk_webrev/test/sun/tools/jhsdb/BasicLauncherTest.java.sdiff.html L100 - I believe it should not say 'Test FAILED'; maybe just 'FAILED'? Other than that the changes look good. Cheers, -JB- On Thu, May 26, 2016 at 2:12 PM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8152950/webrev.03/ > > This fix cleanup the test and improve error handling in CLHSDB launcher. > > The root of the problem is that in modular world nashhorn can't access > module internal packages ever if they are public. (see details in bug > report). > > Complete fix requires significant efforts and it will be done under > separate CR (JDK-8157947). > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Fri May 27 09:33:09 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 27 May 2016 02:33:09 -0700 (PDT) Subject: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose Message-ID: <39209eae-b854-4de3-b326-147b9d734b43@default> Greetings, Please review this small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8158033 Webrev: http://cr.openjdk.java.net/~mgronlun/8158033/webrev/ Description: The intent when putting in the notify_tracing() hook into debug.cpp (report_java_out_of_memory()) was to intercept a state believed to be a VM termination state, especially when OOME is thrown. Since it is totally valid that Java code catches OOME, and this location actually goes back to Java, this is the wrong location for this hook. In addition, the hook should not be typed for OOME only, but generic for any exit condition (normal / OOME / crash). This should instead have been put into java.cpp (before_exit()) and in VMError.cpp (report_vm_die()). Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 27 11:51:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 May 2016 21:51:46 +1000 Subject: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose In-Reply-To: <39209eae-b854-4de3-b326-147b9d734b43@default> References: <39209eae-b854-4de3-b326-147b9d734b43@default> Message-ID: Hi Markus, On 27/05/2016 7:33 PM, Markus Gronlund wrote: > Greetings, > > Please review this small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158033 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8158033/webrev/ > > Description: > > The intent when putting in the notify_tracing() hook into debug.cpp > (report_java_out_of_memory()) was to intercept a state believed to be a > VM termination state, especially when OOME is thrown. Since it is > totally valid that Java code catches OOME, and this location actually > goes back to Java, this is the wrong location for this hook. > > In addition, the hook should not be typed for OOME only, but generic for > any exit condition (normal / OOME / crash). > This should instead have been put into java.cpp (before_exit()) and in > VMError.cpp (report_vm_die()). In src/share/vm/runtime/java.cpp why did you move the existing event code? What determined that TRACE_VM_EXIT should happen at that particular point? I also wonder what TRACE_VM_ERROR might do because in the vmError code it is called in a signal-handling context and so is very limited in what it can legitimately do without potentially messing up the error reporting. Thanks, David > > > Thanks > > Markus > From coleen.phillimore at oracle.com Fri May 27 14:56:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 May 2016 10:56:41 -0400 Subject: RFR (M) 8155951: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool In-Reply-To: <825cdf65-3b47-ad4a-f921-d05a47b3cb12@oracle.com> References: <3feed94a-5122-bdaf-926b-32cc49901e13@oracle.com> <74dbcc5e-7de2-2675-0623-fb8f0e5d459a@oracle.com> <082eb574-6db8-1d76-9f8a-4579fd31a1b5@oracle.com> <825cdf65-3b47-ad4a-f921-d05a47b3cb12@oracle.com> Message-ID: <3a33e40c-f571-b21a-86ef-2a07f4faaaa2@oracle.com> Thanks, Dan. Coleen On 5/24/16 6:46 PM, Daniel D. Daugherty wrote: > Finally caught up on this thread. > > The change looks great. I don't see any locking issues > with this fix. > > Dan > > > On 5/16/16 3:42 PM, Coleen Phillimore wrote: >> >> Thank you, David! >> Coleen >> >> On 5/16/16 4:59 PM, David Holmes wrote: >>> Looks good! >>> >>> Thanks, >>> David >>> >>> On 17/05/2016 2:28 AM, Coleen Phillimore wrote: >>>> >>>> David, Thank you for looking at this change. >>>> >>>> On 5/15/16 9:51 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 13/05/2016 4:14 AM, Coleen Phillimore wrote: >>>>>> 8151066: assert(0 <= i && i < length()) failed: index out of bounds >>>>>> Summary: lock classes for redefinition because constant pool merging >>>>>> isn't thread safe, use method constant pool because constant pool >>>>>> merging doesn't make equivalent cpCaches because of invokedynamic >>>>>> >>>>>> I had to make these changes together. See bugs for more details. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8155951 >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8151066 >>>>> >>>>> In general the locking approach seems okay - as long as all mutating >>>>> actions on the constantpool are being guarded with this locking. >>>>> >>>>> But I'm concerned that you are using a bit in _misc_flags for this >>>>> mutable state. It isn't clear to me when the other bits in >>>>> _misc_flags >>>>> might be set but I'm assuming only during initial class parsing, or >>>>> some other single-threaded use? Putting a mutable bit into such a >>>>> flag >>>>> set is fragile and can only be done once. >>>> >>>> I was uneasy about this too. Most of the _misc_flags are set during >>>> initialization but there are a couple that are set while the vm is >>>> running. I moved _is_being_redefined to a bool sized gap just about >>>> the _misc_flags, which makes me more confident of the state of this >>>> field when doing locking. >>>> >>>> Retesting this small change with StressRedefine in a loop. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8155951.02/webrev >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Tested with rbt nightly test and 24 hours with StressRedefine test. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> >>>> >> >> > From markus.gronlund at oracle.com Fri May 27 16:11:13 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 27 May 2016 09:11:13 -0700 (PDT) Subject: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose In-Reply-To: References: <39209eae-b854-4de3-b326-147b9d734b43@default> Message-ID: <9351f0b7-be7b-4a10-96b8-8b90105b4c31@default> Hi David, Thanks for taking a look, pls see below. Thanks again Markus -----Original Message----- From: David Holmes Sent: den 27 maj 2016 13:52 To: Markus Gronlund; serviceability-dev at openjdk.java.net Subject: Re: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose Hi Markus, On 27/05/2016 7:33 PM, Markus Gronlund wrote: > Greetings, > > Please review this small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158033 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8158033/webrev/ > > Description: > > The intent when putting in the notify_tracing() hook into debug.cpp > (report_java_out_of_memory()) was to intercept a state believed to be > a VM termination state, especially when OOME is thrown. Since it is > totally valid that Java code catches OOME, and this location actually > goes back to Java, this is the wrong location for this hook. > > In addition, the hook should not be typed for OOME only, but generic > for any exit condition (normal / OOME / crash). > This should instead have been put into java.cpp (before_exit()) and in > VMError.cpp (report_vm_die()). In src/share/vm/runtime/java.cpp why did you move the existing event code? What determined that TRACE_VM_EXIT should happen at that particular point? [MG] The reason I put in the TRACE_VM_EXIT (and moved up the event with it) here is because I would like the call to happen before the task that stops the WatcherThread. This is in order to have the "is_error_reported()" functionality still in place when calling TRACE_VM_EXIT. As this will be called when the VM is an unknown / corrupted state (crashing), I would like to have the timeout abort mechanism in place should TRACE_VM_EXIT run into anything that does not return properly (hangs). As for moving the event site, if TRACE_VM_EXIT deconstructs the tracing framework, it makes sense to have the event generated before this point. Aside, today, the current event site is located "too late" to be of real value. I also wonder what TRACE_VM_ERROR might do because in the vmError code it is called in a signal-handling context and so is very limited in what it can legitimately do without potentially messing up the error reporting. [MG] Yes this is sensitive I agree. I have put TRACE_VM_ERROR at a place where it will be able to handle reentrancy into the signal handler correctly. This is also tested by having the TRACE_VM_EXIT logic crash. In addition, TRACE_VM_ERROR will be made non-reentrant on initial call. Thanks again Markus Thanks, David > > > Thanks > > Markus > From robbin.ehn at oracle.com Mon May 30 14:52:04 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 30 May 2016 16:52:04 +0200 Subject: RFR: 8158150: LogConfiguration::describe output can get truncated Message-ID: Hi all, The log configuration string for an output can be longer than O_BUFLEN. The maximum size increase for each new tag set. Webrev: http://cr.openjdk.java.net/~rehn/8158150/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158150 Tested with internal vm tests and jcmd VM.log list Thanks! /Robbin From david.holmes at oracle.com Mon May 30 23:53:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 May 2016 09:53:40 +1000 Subject: RFR: 8158150: LogConfiguration::describe output can get truncated In-Reply-To: References: Message-ID: <6b020521-6bbd-7e31-b857-27241a2a5403@oracle.com> Looks good! Thanks, David On 31/05/2016 12:52 AM, Robbin Ehn wrote: > Hi all, > > The log configuration string for an output can be longer than O_BUFLEN. > The maximum size increase for each new tag set. > > Webrev: http://cr.openjdk.java.net/~rehn/8158150/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158150 > > Tested with internal vm tests and jcmd VM.log list > > Thanks! > > /Robbin From kim.barrett at oracle.com Tue May 31 00:06:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 May 2016 20:06:34 -0400 Subject: RFR: 8158150: LogConfiguration::describe output can get truncated In-Reply-To: References: Message-ID: > On May 30, 2016, at 10:52 AM, Robbin Ehn wrote: > > Hi all, > > The log configuration string for an output can be longer than O_BUFLEN. > The maximum size increase for each new tag set. > > Webrev: http://cr.openjdk.java.net/~rehn/8158150/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158150 > > Tested with internal vm tests and jcmd VM.log list Looks good. From aleksey.shipilev at oracle.com Tue May 31 07:40:50 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 31 May 2016 10:40:50 +0300 Subject: RFR (S) 8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size Message-ID: <574D4002.8070102@oracle.com> Hi, Please review a tiny fix in GetObjectSize: https://bugs.openjdk.java.net/browse/JDK-8075030 http://cr.openjdk.java.net/~shade/8075030/webrev.01/ I think this is a leftover from Metaspace work. For some reason, JvmtiEnv::GetObjectSize has a special case for java.lang.Class: it returns the Klass* size, not the java.lang.Class instance size. This is incorrect: Klass* is indeed referenced from java.lang.Class.metadata field, but the instance size itself does not depend on metadata size. This confuses Instrumentation.getObjectSize users. Testing: new test; RBT, :hotspot_compiler, :hotspot_gc, :hotspot_runtime, :hotspot_serviceability, :hotspot_misc, :jdk_management, :jdk_instrument, :jdk_jmx, :jdk_jdi, :svc_tools. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From robbin.ehn at oracle.com Tue May 31 10:38:01 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 31 May 2016 12:38:01 +0200 Subject: RFR: 8158150: LogConfiguration::describe output can get truncated In-Reply-To: <6b020521-6bbd-7e31-b857-27241a2a5403@oracle.com> References: <6b020521-6bbd-7e31-b857-27241a2a5403@oracle.com> Message-ID: <53449743-ba56-4ec1-81c1-3439f03b2b4c@oracle.com> Thanks David! /Robbin On 05/31/2016 01:53 AM, David Holmes wrote: > Looks good! > > Thanks, > David > > On 31/05/2016 12:52 AM, Robbin Ehn wrote: >> Hi all, >> >> The log configuration string for an output can be longer than O_BUFLEN. >> The maximum size increase for each new tag set. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8158150/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158150 >> >> Tested with internal vm tests and jcmd VM.log list >> >> Thanks! >> >> /Robbin From robbin.ehn at oracle.com Tue May 31 10:38:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 31 May 2016 12:38:17 +0200 Subject: RFR: 8158150: LogConfiguration::describe output can get truncated In-Reply-To: References: Message-ID: <9d0a35ab-79e0-ee17-536b-c349b16048b4@oracle.com> Thanks Kim! /Robbin On 05/31/2016 02:06 AM, Kim Barrett wrote: >> On May 30, 2016, at 10:52 AM, Robbin Ehn wrote: >> >> Hi all, >> >> The log configuration string for an output can be longer than O_BUFLEN. >> The maximum size increase for each new tag set. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8158150/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158150 >> >> Tested with internal vm tests and jcmd VM.log list > > Looks good. > From yasuenag at gmail.com Tue May 31 13:58:55 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 31 May 2016 22:58:55 +0900 Subject: PING: RFR: JDK-8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd In-Reply-To: <573B569C.7090007@oracle.com> References: <338c77df-c120-7876-5ab8-215f9c112879@gmail.com> <2D85894C-CD83-4C96-B545-82564BC938A3@oracle.com> <68f48c77-325f-2fe4-cd4f-9c843c51bd29@gmail.com> <573AF190.3000707@oracle.com> <60639382-bbab-0211-46c9-ac194c360f2a@gmail.com> <573B569C.7090007@oracle.com> Message-ID: <9dd7f531-fdcc-4834-88cd-8f2c0b681659@gmail.com> Hi all, JDK-8155936 has been reviewed. But Gerard and I think we should add more test for this feature whether setting a boolean flag to ?true? and ?false? works as expected. So I uploaded new webrev again. Changes from webrev.01 (reviewed) is for SetVMFlagTest.java only. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.02/ Thanks, Yasumasa On 2016/05/18 2:36, Dmitry Samersoff wrote: > Yasumasa, > > Looks good for me. > > -Dmitry > > On 2016-05-17 17:31, Yasumasa Suenaga wrote: >> Hi Dmitry, >> >> Thank you for your comment. >> I've fixed them in new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.01/ >> >> >> Yasumasa >> >> >> On 2016/05/17 19:25, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> 1. Please use strcasecmp for true/false >>> >>> 2. You may save one strcmp call by replacing it to >>> (*arg == '0' && *(arg+1) == 0) >>> >>> -Dmitry >>> >>> >>> On 2016-05-17 13:15, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> We need a reviewer. >>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/06 1:18, Gerard Ziemski wrote: >>>>> I?m including serviceability mailing list. >>>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8155936v >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>> >>>>> >>>>> cheers >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> From: Yasumasa Suenaga >>>>>> Subject: Re: RFR: JDK-8155936: Boolean value should be set 1/0 or >>>>>> true/false via VM.set_flag jcmd >>>>>> Date: May 4, 2016 at 9:34:15 AM CDT >>>>>> To: "hotspot-runtime-dev at openjdk.java.net" >>>>>> >>>>>> Cc: Gerard Ziemski >>>>>> >>>>>> Hi all, >>>>>> >>>>>> We still need a second Reviewer. >>>>>> Could you review? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/04 9:32, Yasumasa Suenaga wrote: >>>>>>> Hi Gerard, >>>>>>> >>>>>>>> Reviewed and I will sponsor it. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>>> >>>>>>> I do not change in jdk repos. >>>>>>> My change affects jinfo, however jtreg test for jinfo passed. >>>>>>> >>>>>>> I ran jtreg with two directories: >>>>>>> >>>>>>> - hotspot/test/serviceability/dcmd/vm >>>>>>> - jdk/test/sun/tools/jinfo >>>>>>> >>>>>>> They work fine. >>>>>>> (JInfoRunningProcessFlagTest is failed. But it is listed in >>>>>>> ProblemList.) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/05/04 3:18, Gerard Ziemski wrote: >>>>>>>> hi Yasumasa, >>>>>>>> >>>>>>>> Thank you for the fix, I like it - the very first time I tried >>>>>>>> using jcmd to set a boolean value I tried using ?true?, so this >>>>>>>> will make jcmd easier to use. >>>>>>>> >>>>>>>> Reviewed and I will sponsor it. >>>>>>>> >>>>>>>> Just one question: there is no existing JDK issue covering this >>>>>>>> yet, is there? Can you file one please if none exists yet? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>>> On May 3, 2016, at 9:22 AM, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This review request relates to [1]. >>>>>>>>> >>>>>>>>> We can change a part of -XX option via VM.set_flag jcmd. >>>>>>>>> This jcmd requires 1 or 0 as boolean value. >>>>>>>>> However, we can set 0 or not (NOT 1). >>>>>>>>> >>>>>>>>> In jinfo, we can set boolean value with 1/0 or +/-. >>>>>>>>> So I think it is useful if VM.set_flag accept boolean value in >>>>>>>>> true/false. >>>>>>>>> >>>>>>>>> I uploaded a webrev for this issue. >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8155936/webrev.00/ >>>>>>>>> >>>>>>>>> I cannot access JPRT. >>>>>>>>> So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019192.html >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>> >>> > > From erik.gahlin at oracle.com Tue May 31 19:47:11 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 31 May 2016 21:47:11 +0200 Subject: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose In-Reply-To: <39209eae-b854-4de3-b326-147b9d734b43@default> References: <39209eae-b854-4de3-b326-147b9d734b43@default> Message-ID: <574DEA3F.9020308@oracle.com> Looks good! Not a (R)eviewer Erik On 2016-05-27 11:33, Markus Gronlund wrote: > > Greetings, > > Please review this small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158033 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8158033/webrev/ > > > Description: > > The intent when putting in the notify_tracing() hook into debug.cpp > (report_java_out_of_memory()) was to intercept a state believed to be > a VM termination state, especially when OOME is thrown. Since it is > totally valid that Java code catches OOME, and this location actually > goes back to Java, this is the wrong location for this hook. > > In addition, the hook should not be typed for OOME only, but generic > for any exit condition (normal / OOME / crash). > This should instead have been put into java.cpp (before_exit()) and in > VMError.cpp (report_vm_die()). > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: