From david.holmes at oracle.com Wed Jun 1 04:03:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Jun 2016 14:03:05 +1000 Subject: RFR(XS): 8158033: notify_tracing() misplaced for intended purpose In-Reply-To: <9351f0b7-be7b-4a10-96b8-8b90105b4c31@default> References: <39209eae-b854-4de3-b326-147b9d734b43@default> <9351f0b7-be7b-4a10-96b8-8b90105b4c31@default> Message-ID: <3aaa6264-31de-debd-ec9a-facc31c9d10d@oracle.com> Thanks for the additional info. I guess we will see how this behaves as time progresses. Reviewed. David On 28/05/2016 2:11 AM, Markus Gronlund wrote: > 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 serguei.spitsyn at oracle.com Wed Jun 1 06:41:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 31 May 2016 23:41:00 -0700 Subject: RFR (S) 8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size In-Reply-To: <574D4002.8070102@oracle.com> References: <574D4002.8070102@oracle.com> Message-ID: <574E837C.7020006@oracle.com> Hi Aleksey, I guess, at least, this needs a CCC request. I'm uncomfortable to support the change without knowing the history behind the original implementation. Does anyone know the reasons why current implementation was chosen in the first place? Are there any tools that depend on the current behavior? Thanks, Serguei On 5/31/16 00:40, Aleksey Shipilev wrote: > 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 > From robbin.ehn at oracle.com Wed Jun 1 10:16:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 1 Jun 2016 12:16:51 +0200 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly Message-ID: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> Hi all, There were some ripple effects, so to get everything working as intended the patch grow slightly. Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 Both a lot of manual testing, the new tests and jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. Thanks! /Robbin From aleksey.shipilev at oracle.com Wed Jun 1 13:49:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 1 Jun 2016 16:49:31 +0300 Subject: RFR (S) 8075030: JvmtiEnv::GetObjectSize reports incorrect java.lang.Class instance size In-Reply-To: <574E837C.7020006@oracle.com> References: <574D4002.8070102@oracle.com> <574E837C.7020006@oracle.com> Message-ID: <574EE7EB.6000100@oracle.com> On 06/01/2016 09:41 AM, serguei.spitsyn at oracle.com wrote: > I guess, at least, this needs a CCC request. Why? This changes behavior within the spec. > I'm uncomfortable to support the change without knowing the history > behind the original implementation. Does anyone know the reasons why > current implementation was chosen in the first place? Stefan Karlsson forwarded me a discussion back from 2011, which says: --------- 8< ----------------------------------------------------------- > For the permgen removal project I'm reworking how the sizes of = metadata are calculated, and stumbled upon this code. > For "normal" objects it calculates the size and are done. But, for > non-primitive java.lang.Class instances (mirrors), it uses the size of > the Klass instead. Does anyone have a reasonable explanation why this > is done? My guess would be that it's attempting to provide a more abstractly = accurate value, though it's still way off. [...] So we can return whatever we want but we need to be consistent. There are other places where the klassOop is swapped for the Class in jvmtiTagMap.cpp and the size reported so it will need to be consistent with whatever GetObjectSize does. I'd maintain the current size reporting behaviour if possible. --------- 8< ----------------------------------------------------------- But I looked around and saw no discrepancies. The tests are also fine. This block history predates OpenJDK. Metaspace work left it untouched because it had bigger fish to fry. But at this point I believe we don't have to drag this debt around anymore. > Are there any tools that depend on the current behavior? I don't think so. Specification itself allows for returning a size estimate, so strictly speaking relying on the reported size is not safe. However, I know at least one tool which acts all surprised when the reported instance size is way off, and it looks like Class instances are overlapping with subsequent objects. Thanks, -Aleksey > Thanks, > Serguei > > On 5/31/16 00:40, Aleksey Shipilev wrote: >> 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 dmitry.samersoff at oracle.com Wed Jun 1 17:59:36 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 1 Jun 2016 17:59:36 +0000 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> Message-ID: <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> Robbin, ProcessArgumentMatcher.java:61 What is the reason of keeping singlePid as a string. It might be better to convert it to Long at the argument processing time and then deal with Long. Arguments.java: null seems more natural to me than "0" JInfo.java: 54 value of flag is not obvious to me, because optionCount do exactly the same. Update: it's the open question how we should proceed multiple -flag and -flags arguments. e.g. command line jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA results different output for the same process. I didn't find any documentation specified it, So I would prefer to disable the combination like one above. At least for now. 74 missed space MonitoredVmUtil.java: 119 Could you change tmp to something more descriptive? Or ever better move the code guessing lastFileSparator to a separate function for better readability. -Dmitry On 2016-06-01 10:16, Robbin Ehn wrote: > Hi all, > > There were some ripple effects, so to get everything working as intended > the patch grow slightly. > > Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 > > Both a lot of manual testing, the new tests and > jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. > > Thanks! > > /Robbin From robbin.ehn at oracle.com Thu Jun 2 09:41:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 2 Jun 2016 11:41:17 +0200 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> Message-ID: <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> Hi Dmitry, thanks for looking at this. On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: > Robbin, > > ProcessArgumentMatcher.java:61 > > What is the reason of keeping singlePid as a string. It might be > better to convert it to Long at the argument processing time and then > deal with Long. VirtualMachineDescriptor returns pid as string, see ProcessArgumentMatcher.java:116 So I'll prefer to keep it as a string. Rest should be fixed, also contains fixes after input from Staffan (thanks). Inc: http://cr.openjdk.java.net/~rehn/8156537/02-01/webrev/ Full: http://cr.openjdk.java.net/~rehn/8156537/02/webrev/ /Robbin > > Arguments.java: > > null seems more natural to me than "0" > > JInfo.java: > > 54 value of flag is not obvious to me, because optionCount do exactly > the same. > > Update: it's the open question how we should proceed multiple -flag > and -flags arguments. > > e.g. command line > > jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA > > results different output for the same process. > > I didn't find any documentation specified it, So I would prefer to > disable the combination like one above. At least for now. > > 74 missed space > > MonitoredVmUtil.java: > > 119 Could you change tmp to something more descriptive? Or ever > better move the code guessing lastFileSparator to a separate function > for better readability. > > -Dmitry > > On 2016-06-01 10:16, Robbin Ehn wrote: >> Hi all, >> >> There were some ripple effects, so to get everything working as intended >> the patch grow slightly. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 >> >> Both a lot of manual testing, the new tests and >> jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. >> >> Thanks! >> >> /Robbin > From dmitry.samersoff at oracle.com Thu Jun 2 13:48:17 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 2 Jun 2016 13:48:17 +0000 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> Message-ID: Robbin, The fix looks good for me. -Dmitry On 2016-06-02 09:41, Robbin Ehn wrote: > Hi Dmitry, thanks for looking at this. > > On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: >> Robbin, >> >> ProcessArgumentMatcher.java:61 >> >> What is the reason of keeping singlePid as a string. It might be >> better to convert it to Long at the argument processing time and then >> deal with Long. > > VirtualMachineDescriptor returns pid as string, see > ProcessArgumentMatcher.java:116 > So I'll prefer to keep it as a string. > > Rest should be fixed, also contains fixes after input from Staffan > (thanks). > > Inc: http://cr.openjdk.java.net/~rehn/8156537/02-01/webrev/ > Full: http://cr.openjdk.java.net/~rehn/8156537/02/webrev/ > > /Robbin > >> >> Arguments.java: >> >> null seems more natural to me than "0" >> >> JInfo.java: >> >> 54 value of flag is not obvious to me, because optionCount do exactly >> the same. >> >> Update: it's the open question how we should proceed multiple -flag >> and -flags arguments. >> >> e.g. command line >> >> jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA >> >> results different output for the same process. >> >> I didn't find any documentation specified it, So I would prefer to >> disable the combination like one above. At least for now. >> >> 74 missed space >> >> MonitoredVmUtil.java: >> >> 119 Could you change tmp to something more descriptive? Or ever >> better move the code guessing lastFileSparator to a separate function >> for better readability. >> >> -Dmitry >> >> On 2016-06-01 10:16, Robbin Ehn wrote: >>> Hi all, >>> >>> There were some ripple effects, so to get everything working as intended >>> the patch grow slightly. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 >>> >>> Both a lot of manual testing, the new tests and >>> jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. >>> >>> Thanks! >>> >>> /Robbin >> From robbin.ehn at oracle.com Thu Jun 2 10:56:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 2 Jun 2016 12:56:00 +0200 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> Message-ID: <29feec24-6023-81ce-92d2-d59eb8a03ea6@oracle.com> Thanks Dmitry! /Robbin On 06/02/2016 03:48 PM, Dmitry Samersoff wrote: > Robbin, > > The fix looks good for me. > > -Dmitry > > On 2016-06-02 09:41, Robbin Ehn wrote: >> Hi Dmitry, thanks for looking at this. >> >> On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: >>> Robbin, >>> >>> ProcessArgumentMatcher.java:61 >>> >>> What is the reason of keeping singlePid as a string. It might be >>> better to convert it to Long at the argument processing time and then >>> deal with Long. >> >> VirtualMachineDescriptor returns pid as string, see >> ProcessArgumentMatcher.java:116 >> So I'll prefer to keep it as a string. >> >> Rest should be fixed, also contains fixes after input from Staffan >> (thanks). >> >> Inc: http://cr.openjdk.java.net/~rehn/8156537/02-01/webrev/ >> Full: http://cr.openjdk.java.net/~rehn/8156537/02/webrev/ >> >> /Robbin >> >>> >>> Arguments.java: >>> >>> null seems more natural to me than "0" >>> >>> JInfo.java: >>> >>> 54 value of flag is not obvious to me, because optionCount do exactly >>> the same. >>> >>> Update: it's the open question how we should proceed multiple -flag >>> and -flags arguments. >>> >>> e.g. command line >>> >>> jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA >>> >>> results different output for the same process. >>> >>> I didn't find any documentation specified it, So I would prefer to >>> disable the combination like one above. At least for now. >>> >>> 74 missed space >>> >>> MonitoredVmUtil.java: >>> >>> 119 Could you change tmp to something more descriptive? Or ever >>> better move the code guessing lastFileSparator to a separate function >>> for better readability. >>> >>> -Dmitry >>> >>> On 2016-06-01 10:16, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> There were some ripple effects, so to get everything working as intended >>>> the patch grow slightly. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 >>>> >>>> Both a lot of manual testing, the new tests and >>>> jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. >>>> >>>> Thanks! >>>> >>>> /Robbin >>> > From staffan.larsen at oracle.com Fri Jun 3 07:20:59 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 3 Jun 2016 09:20:59 +0200 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> Message-ID: <6E213EFC-DD9D-488B-9013-8EB3D36C89C9@oracle.com> Looks good! Thanks, /Staffan > On 2 juni 2016, at 11:41, Robbin Ehn wrote: > > Hi Dmitry, thanks for looking at this. > > On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: >> Robbin, >> >> ProcessArgumentMatcher.java:61 >> >> What is the reason of keeping singlePid as a string. It might be >> better to convert it to Long at the argument processing time and then >> deal with Long. > > VirtualMachineDescriptor returns pid as string, see ProcessArgumentMatcher.java:116 > So I'll prefer to keep it as a string. > > Rest should be fixed, also contains fixes after input from Staffan (thanks). > > Inc: http://cr.openjdk.java.net/~rehn/8156537/02-01/webrev/ > Full: http://cr.openjdk.java.net/~rehn/8156537/02/webrev/ > > /Robbin > >> >> Arguments.java: >> >> null seems more natural to me than "0" >> >> JInfo.java: >> >> 54 value of flag is not obvious to me, because optionCount do exactly >> the same. >> >> Update: it's the open question how we should proceed multiple -flag >> and -flags arguments. >> >> e.g. command line >> >> jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA >> >> results different output for the same process. >> >> I didn't find any documentation specified it, So I would prefer to >> disable the combination like one above. At least for now. >> >> 74 missed space >> >> MonitoredVmUtil.java: >> >> 119 Could you change tmp to something more descriptive? Or ever >> better move the code guessing lastFileSparator to a separate function >> for better readability. >> >> -Dmitry >> >> On 2016-06-01 10:16, Robbin Ehn wrote: >>> Hi all, >>> >>> There were some ripple effects, so to get everything working as intended >>> the patch grow slightly. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 >>> >>> Both a lot of manual testing, the new tests and >>> jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. >>> >>> Thanks! >>> >>> /Robbin >> From robbin.ehn at oracle.com Fri Jun 3 07:36:38 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 3 Jun 2016 09:36:38 +0200 Subject: RFR: 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly In-Reply-To: <6E213EFC-DD9D-488B-9013-8EB3D36C89C9@oracle.com> References: <912dca51-f23c-88c8-3d23-8ad71f413585@oracle.com> <68f9c73e-d183-ac6f-8886-273cec8854db@oracle.com> <62c4f6b4-1b94-e903-0796-8eebb17880a1@oracle.com> <6E213EFC-DD9D-488B-9013-8EB3D36C89C9@oracle.com> Message-ID: <3dd4a76a-f771-de82-d581-892d9a2fcab8@oracle.com> Thanks Staffan! /Robbin On 06/03/2016 09:20 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 2 juni 2016, at 11:41, Robbin Ehn wrote: >> >> Hi Dmitry, thanks for looking at this. >> >> On 06/01/2016 07:59 PM, Dmitry Samersoff wrote: >>> Robbin, >>> >>> ProcessArgumentMatcher.java:61 >>> >>> What is the reason of keeping singlePid as a string. It might be >>> better to convert it to Long at the argument processing time and then >>> deal with Long. >> >> VirtualMachineDescriptor returns pid as string, see ProcessArgumentMatcher.java:116 >> So I'll prefer to keep it as a string. >> >> Rest should be fixed, also contains fixes after input from Staffan (thanks). >> >> Inc: http://cr.openjdk.java.net/~rehn/8156537/02-01/webrev/ >> Full: http://cr.openjdk.java.net/~rehn/8156537/02/webrev/ >> >> /Robbin >> >>> >>> Arguments.java: >>> >>> null seems more natural to me than "0" >>> >>> JInfo.java: >>> >>> 54 value of flag is not obvious to me, because optionCount do exactly >>> the same. >>> >>> Update: it's the open question how we should proceed multiple -flag >>> and -flags arguments. >>> >>> e.g. command line >>> >>> jinfo -flags -flag MinHeapFreeRatio=1 pidA pidA >>> >>> results different output for the same process. >>> >>> I didn't find any documentation specified it, So I would prefer to >>> disable the combination like one above. At least for now. >>> >>> 74 missed space >>> >>> MonitoredVmUtil.java: >>> >>> 119 Could you change tmp to something more descriptive? Or ever >>> better move the code guessing lastFileSparator to a separate function >>> for better readability. >>> >>> -Dmitry >>> >>> On 2016-06-01 10:16, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> There were some ripple effects, so to get everything working as intended >>>> the patch grow slightly. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8156537/01/webrev/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156537 >>>> >>>> Both a lot of manual testing, the new tests and >>>> jdk/test/sun/tools/,jdk/test/tools/ and some other which uses e.g. jcmd. >>>> >>>> Thanks! >>>> >>>> /Robbin >>> > From kirill.zhaldybin at oracle.com Wed Jun 8 18:26:23 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Wed, 8 Jun 2016 21:26:23 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <572CD172.7030700@oracle.com> References: <572CD172.7030700@oracle.com> Message-ID: <5758634F.2070107@oracle.com> Dear all, After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we decided to provide separate error message for the case if method exists but signature or parametes are wrong but throw the same NoSuchMethodError exception. Could you please review this fix for 8156226? New WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ CR: https://bugs.openjdk.java.net/browse/JDK-8156226 Thank you. Regards, Kirill On 06.05.2016 20:16, Kirill Zhaldybin wrote: > 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 mandy.chung at oracle.com Wed Jun 8 18:25:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jun 2016 11:25:54 -0700 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <5758634F.2070107@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> Message-ID: <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> > On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin wrote: > > Dear all, > > After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we decided to provide separate error message for the case if method exists but signature or parametes are wrong but throw the same NoSuchMethodError exception. > > Could you please review this fix for 8156226? > > New WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ This looks okay. It?d be useful for the case line 269 to include the signature as well. Mandy From david.holmes at oracle.com Thu Jun 9 00:33:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jun 2016 10:33:01 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <5758634F.2070107@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> Message-ID: Hi Kirill, On 9/06/2016 4:26 AM, Kirill Zhaldybin wrote: > Dear all, > > After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we > decided to provide separate error message for the case if method exists > but signature or parametes are wrong but throw the same > NoSuchMethodError exception. > > Could you please review this fix for 8156226? > > New WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ As I said previously I have doubts about the entire block of code as the checking is not comprehensive. That aside an augmented message seems a good improvement but I'm wondering: a) how does it look (not sure what Arrays.toString(signature) will print) ? b) why do we not report what may be wrong with params? Thanks, David ----- > CR: https://bugs.openjdk.java.net/browse/JDK-8156226 > > Thank you. > > Regards, Kirill > > On 06.05.2016 20:16, Kirill Zhaldybin wrote: >> 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 david.holmes at oracle.com Thu Jun 9 01:10:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jun 2016 11:10:34 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> Message-ID: On 9/06/2016 10:33 AM, David Holmes wrote: > Hi Kirill, > > On 9/06/2016 4:26 AM, Kirill Zhaldybin wrote: >> Dear all, >> >> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we >> decided to provide separate error message for the case if method exists >> but signature or parametes are wrong but throw the same >> NoSuchMethodError exception. >> >> Could you please review this fix for 8156226? >> >> New WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ > > As I said previously I have doubts about the entire block of code as the > checking is not comprehensive. > > That aside an augmented message seems a good improvement but I'm wondering: > > a) how does it look (not sure what Arrays.toString(signature) will print) ? > b) why do we not report what may be wrong with params? Ignore that. Without doing full element by element checking of signature and params you can't give an accurate error message. What is there is better than nothing. Thanks, David > Thanks, > David > ----- > >> CR: https://bugs.openjdk.java.net/browse/JDK-8156226 >> >> Thank you. >> >> Regards, Kirill >> >> On 06.05.2016 20:16, Kirill Zhaldybin wrote: >>> 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 Thu Jun 9 12:09:59 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Thu, 9 Jun 2016 15:09:59 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> Message-ID: <57595C97.8030004@oracle.com> Mandy, Thank you for reviewing the fix! I added signature to another error message as you advised. Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ Could you please let me know your opinion? Regards, Kirill On 08.06.2016 21:25, Mandy Chung wrote: > >> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin wrote: >> >> Dear all, >> >> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we decided to provide separate error message for the case if method exists but signature or parametes are wrong but throw the same NoSuchMethodError exception. >> >> Could you please review this fix for 8156226? >> >> New WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ > > This looks okay. It?d be useful for the case line 269 to include the signature as well. > > Mandy > From kirill.zhaldybin at oracle.com Thu Jun 9 12:10:40 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Thu, 9 Jun 2016 15:10:40 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> Message-ID: <57595CC0.3070403@oracle.com> David, Thank you for reviewing the fix! Regards, Kirill On 09.06.2016 04:10, David Holmes wrote: > On 9/06/2016 10:33 AM, David Holmes wrote: >> Hi Kirill, >> >> On 9/06/2016 4:26 AM, Kirill Zhaldybin wrote: >>> Dear all, >>> >>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain we >>> decided to provide separate error message for the case if method exists >>> but signature or parametes are wrong but throw the same >>> NoSuchMethodError exception. >>> >>> Could you please review this fix for 8156226? >>> >>> New WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >> >> As I said previously I have doubts about the entire block of code as the >> checking is not comprehensive. >> >> That aside an augmented message seems a good improvement but I'm >> wondering: >> >> a) how does it look (not sure what Arrays.toString(signature) will >> print) ? >> b) why do we not report what may be wrong with params? > > Ignore that. Without doing full element by element checking of signature > and params you can't give an accurate error message. What is there is > better than nothing. > > Thanks, > David > >> Thanks, >> David >> ----- >> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8156226 >>> >>> Thank you. >>> >>> Regards, Kirill >>> >>> On 06.05.2016 20:16, Kirill Zhaldybin wrote: >>>> 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 mandy.chung at oracle.com Thu Jun 9 15:08:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 9 Jun 2016 08:08:36 -0700 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <57595C97.8030004@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> Message-ID: <2EB2F6BD-346B-46DA-87A7-D66F1F36A336@oracle.com> > On Jun 9, 2016, at 5:09 AM, Kirill Zhaldybin wrote: > > Mandy, > > Thank you for reviewing the fix! > > I added signature to another error message as you advised. > Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ Looks okay. Mandy From robbin.ehn at oracle.com Fri Jun 10 07:27:07 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 10 Jun 2016 09:27:07 +0200 Subject: RFR: 8072440: serviceability/dcmd/ tests timeout Message-ID: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> Hi all, I can not reproduce running the tests mutiple times on mutiple platforms. And I can not see anything particular in test code. So I'm removing the @ignore flag for these. Bug: https://bugs.openjdk.java.net/browse/JDK-8072440 Webrev: http://cr.openjdk.java.net/~rehn/8072440/webrev/ Thanks! /Robbin diff -r 25b6767b6c1d test/serviceability/dcmd/framework/HelpTest.java --- a/test/serviceability/dcmd/framework/HelpTest.java Wed Jun 08 16:07:49 2016 +0200 +++ b/test/serviceability/dcmd/framework/HelpTest.java Fri Jun 10 09:24:57 2016 +0200 @@ -39,3 +39,2 @@ * jdk.jvmstat/sun.jvmstat.monitor - * @ignore 8072440 * @build jdk.test.lib.* diff -r 25b6767b6c1d test/serviceability/dcmd/framework/InvalidCommandTest.java --- a/test/serviceability/dcmd/framework/InvalidCommandTest.java Wed Jun 08 16:07:49 2016 +0200 +++ b/test/serviceability/dcmd/framework/InvalidCommandTest.java Fri Jun 10 09:24:57 2016 +0200 @@ -39,3 +39,2 @@ * jdk.jvmstat/sun.jvmstat.monitor - * @ignore 8072440 * @build jdk.test.lib.* diff -r 25b6767b6c1d test/serviceability/dcmd/framework/VMVersionTest.java --- a/test/serviceability/dcmd/framework/VMVersionTest.java Wed Jun 08 16:07:49 2016 +0200 +++ b/test/serviceability/dcmd/framework/VMVersionTest.java Fri Jun 10 09:24:57 2016 +0200 @@ -40,3 +40,2 @@ * jdk.jvmstat/sun.jvmstat.monitor - * @ignore 8072440 * @build jdk.test.lib.* From daniel.fuchs at oracle.com Fri Jun 10 08:00:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Jun 2016 09:00:21 +0100 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <57595C97.8030004@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> Message-ID: <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> Hi Kirill, I think you might get a NullPointerException in Arrays.toString(signature) if signature == null, so you should probably guard against that. best regards, -- daniel On 09/06/16 13:09, Kirill Zhaldybin wrote: > Mandy, > > Thank you for reviewing the fix! > > I added signature to another error message as you advised. > Here are a new WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ > > Could you please let me know your opinion? > > Regards, Kirill > > On 08.06.2016 21:25, Mandy Chung wrote: >> >>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>> wrote: >>> >>> Dear all, >>> >>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>> we decided to provide separate error message for the case if method >>> exists but signature or parametes are wrong but throw the same >>> NoSuchMethodError exception. >>> >>> Could you please review this fix for 8156226? >>> >>> New WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >> >> This looks okay. It?d be useful for the case line 269 to include the >> signature as well. >> >> Mandy >> > From daniel.fuchs at oracle.com Fri Jun 10 08:07:07 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Jun 2016 09:07:07 +0100 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> Message-ID: On 10/06/16 09:00, Daniel Fuchs wrote: > Hi Kirill, > > I think you might get a NullPointerException in > Arrays.toString(signature) if signature == null, > so you should probably guard against that. Forget that. I should have checked the code before replying ;-( Arrays.toString will return "null" if the array passed as parameter is null. So what you have looks good to me! best regards, -- daniel > > best regards, > > -- daniel > > On 09/06/16 13:09, Kirill Zhaldybin wrote: >> Mandy, >> >> Thank you for reviewing the fix! >> >> I added signature to another error message as you advised. >> Here are a new WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >> >> Could you please let me know your opinion? >> >> Regards, Kirill >> >> On 08.06.2016 21:25, Mandy Chung wrote: >>> >>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>> wrote: >>>> >>>> Dear all, >>>> >>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>> we decided to provide separate error message for the case if method >>>> exists but signature or parametes are wrong but throw the same >>>> NoSuchMethodError exception. >>>> >>>> Could you please review this fix for 8156226? >>>> >>>> New WebRev: >>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>> >>> This looks okay. It?d be useful for the case line 269 to include the >>> signature as well. >>> >>> Mandy >>> >> > From david.holmes at oracle.com Fri Jun 10 09:30:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jun 2016 19:30:09 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> Message-ID: <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> On 10/06/2016 6:00 PM, Daniel Fuchs wrote: > Hi Kirill, > > I think you might get a NullPointerException in > Arrays.toString(signature) if signature == null, > so you should probably guard against that. Yes that addition to line 269 needs more attention as it is not guarded the way the previous variant is. Not sure what a zero-length array might produce either - for both you would want the representation of an "empty" signature. David > best regards, > > -- daniel > > On 09/06/16 13:09, Kirill Zhaldybin wrote: >> Mandy, >> >> Thank you for reviewing the fix! >> >> I added signature to another error message as you advised. >> Here are a new WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >> >> Could you please let me know your opinion? >> >> Regards, Kirill >> >> On 08.06.2016 21:25, Mandy Chung wrote: >>> >>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>> wrote: >>>> >>>> Dear all, >>>> >>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>> we decided to provide separate error message for the case if method >>>> exists but signature or parametes are wrong but throw the same >>>> NoSuchMethodError exception. >>>> >>>> Could you please review this fix for 8156226? >>>> >>>> New WebRev: >>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>> >>> This looks okay. It?d be useful for the case line 269 to include the >>> signature as well. >>> >>> Mandy >>> >> > From kirill.zhaldybin at oracle.com Fri Jun 10 16:23:55 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Fri, 10 Jun 2016 19:23:55 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> Message-ID: <575AE99B.5000109@oracle.com> David, Daniel, Mandy, I changed the fix to provide "nicer" message in case if signature is null. Here are a new WebRev: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.06/ Could you please let me know your opinion? Thank you. Regards, Kirill On 10.06.2016 12:30, David Holmes wrote: > On 10/06/2016 6:00 PM, Daniel Fuchs wrote: >> Hi Kirill, >> >> I think you might get a NullPointerException in >> Arrays.toString(signature) if signature == null, >> so you should probably guard against that. > > Yes that addition to line 269 needs more attention as it is not guarded > the way the previous variant is. Not sure what a zero-length array might > produce either - for both you would want the representation of an > "empty" signature. > > David > >> best regards, >> >> -- daniel >> >> On 09/06/16 13:09, Kirill Zhaldybin wrote: >>> Mandy, >>> >>> Thank you for reviewing the fix! >>> >>> I added signature to another error message as you advised. >>> Here are a new WebRev: >>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >>> >>> Could you please let me know your opinion? >>> >>> Regards, Kirill >>> >>> On 08.06.2016 21:25, Mandy Chung wrote: >>>> >>>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>>> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>>> we decided to provide separate error message for the case if method >>>>> exists but signature or parametes are wrong but throw the same >>>>> NoSuchMethodError exception. >>>>> >>>>> Could you please review this fix for 8156226? >>>>> >>>>> New WebRev: >>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>>> >>>> This looks okay. It?d be useful for the case line 269 to include the >>>> signature as well. >>>> >>>> Mandy >>>> >>> >> From daniel.fuchs at oracle.com Fri Jun 10 16:21:06 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Jun 2016 17:21:06 +0100 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <575AE99B.5000109@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> Message-ID: <40785296-15a2-36c3-eb2c-65c699730858@oracle.com> On 10/06/16 17:23, Kirill Zhaldybin wrote: > David, Daniel, Mandy, > > I changed the fix to provide "nicer" message in case if signature is null. > > Here are a new WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.06/ Looks good to me. -- daniel > > Could you please let me know your opinion? > > Thank you. > > Regards, Kirill > > On 10.06.2016 12:30, David Holmes wrote: >> On 10/06/2016 6:00 PM, Daniel Fuchs wrote: >>> Hi Kirill, >>> >>> I think you might get a NullPointerException in >>> Arrays.toString(signature) if signature == null, >>> so you should probably guard against that. >> >> Yes that addition to line 269 needs more attention as it is not guarded >> the way the previous variant is. Not sure what a zero-length array might >> produce either - for both you would want the representation of an >> "empty" signature. >> >> David >> >>> best regards, >>> >>> -- daniel >>> >>> On 09/06/16 13:09, Kirill Zhaldybin wrote: >>>> Mandy, >>>> >>>> Thank you for reviewing the fix! >>>> >>>> I added signature to another error message as you advised. >>>> Here are a new WebRev: >>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >>>> >>>> Could you please let me know your opinion? >>>> >>>> Regards, Kirill >>>> >>>> On 08.06.2016 21:25, Mandy Chung wrote: >>>>> >>>>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>>>> wrote: >>>>>> >>>>>> Dear all, >>>>>> >>>>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>>>> we decided to provide separate error message for the case if method >>>>>> exists but signature or parametes are wrong but throw the same >>>>>> NoSuchMethodError exception. >>>>>> >>>>>> Could you please review this fix for 8156226? >>>>>> >>>>>> New WebRev: >>>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>>>> >>>>> This looks okay. It?d be useful for the case line 269 to include the >>>>> signature as well. >>>>> >>>>> Mandy >>>>> >>>> >>> > From staffan.larsen at oracle.com Fri Jun 10 19:25:01 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Jun 2016 21:25:01 +0200 Subject: RFR: 8072440: serviceability/dcmd/ tests timeout In-Reply-To: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> References: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> Message-ID: <16FC4C09-0252-4FEF-86BE-0C91DE10A1BD@oracle.com> Looks good! Thanks, /Staffan > On 10 juni 2016, at 09:27, Robbin Ehn wrote: > > Hi all, > > I can not reproduce running the tests mutiple times on mutiple platforms. > And I can not see anything particular in test code. > So I'm removing the @ignore flag for these. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072440 > Webrev: http://cr.openjdk.java.net/~rehn/8072440/webrev/ > > Thanks! > > /Robbin > > diff -r 25b6767b6c1d test/serviceability/dcmd/framework/HelpTest.java > --- a/test/serviceability/dcmd/framework/HelpTest.java Wed Jun 08 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/HelpTest.java Fri Jun 10 09:24:57 2016 +0200 > @@ -39,3 +39,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > diff -r 25b6767b6c1d test/serviceability/dcmd/framework/InvalidCommandTest.java > --- a/test/serviceability/dcmd/framework/InvalidCommandTest.java Wed Jun 08 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/InvalidCommandTest.java Fri Jun 10 09:24:57 2016 +0200 > @@ -39,3 +39,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > diff -r 25b6767b6c1d test/serviceability/dcmd/framework/VMVersionTest.java > --- a/test/serviceability/dcmd/framework/VMVersionTest.java Wed Jun 08 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/VMVersionTest.java Fri Jun 10 09:24:57 2016 +0200 > @@ -40,3 +40,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > From david.holmes at oracle.com Sat Jun 11 00:41:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Jun 2016 10:41:27 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <575AE99B.5000109@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> Message-ID: <53c51e7f-a8b5-2120-173c-8913ff4c7775@oracle.com> On 11/06/2016 2:23 AM, Kirill Zhaldybin wrote: > David, Daniel, Mandy, > > I changed the fix to provide "nicer" message in case if signature is null. > > Here are a new WebRev: > http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.06/ > > Could you please let me know your opinion? Better, but I still wonder what Arrays.toString prints for an empty array? Thanks, David > Thank you. > > Regards, Kirill > > On 10.06.2016 12:30, David Holmes wrote: >> On 10/06/2016 6:00 PM, Daniel Fuchs wrote: >>> Hi Kirill, >>> >>> I think you might get a NullPointerException in >>> Arrays.toString(signature) if signature == null, >>> so you should probably guard against that. >> >> Yes that addition to line 269 needs more attention as it is not guarded >> the way the previous variant is. Not sure what a zero-length array might >> produce either - for both you would want the representation of an >> "empty" signature. >> >> David >> >>> best regards, >>> >>> -- daniel >>> >>> On 09/06/16 13:09, Kirill Zhaldybin wrote: >>>> Mandy, >>>> >>>> Thank you for reviewing the fix! >>>> >>>> I added signature to another error message as you advised. >>>> Here are a new WebRev: >>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >>>> >>>> Could you please let me know your opinion? >>>> >>>> Regards, Kirill >>>> >>>> On 08.06.2016 21:25, Mandy Chung wrote: >>>>> >>>>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>>>> wrote: >>>>>> >>>>>> Dear all, >>>>>> >>>>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>>>> we decided to provide separate error message for the case if method >>>>>> exists but signature or parametes are wrong but throw the same >>>>>> NoSuchMethodError exception. >>>>>> >>>>>> Could you please review this fix for 8156226? >>>>>> >>>>>> New WebRev: >>>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>>>> >>>>> This looks okay. It?d be useful for the case line 269 to include the >>>>> signature as well. >>>>> >>>>> Mandy >>>>> >>>> >>> > From daniel.fuchs at oracle.com Sat Jun 11 08:12:47 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 11 Jun 2016 09:12:47 +0100 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <53c51e7f-a8b5-2120-173c-8913ff4c7775@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> <53c51e7f-a8b5-2120-173c-8913ff4c7775@oracle.com> Message-ID: <212723b8-6377-7820-ff36-9f53fc3bdb81@oracle.com> On 11/06/16 01:41, David Holmes wrote: > Better, but I still wonder what Arrays.toString prints for an empty array? It prints "[]" - like Collections.emptyList().toString(): System.out.println("null: " + Arrays.toString((Object[])null)); System.out.println("new Object[0]: " + Arrays.toString(new Object[0])); System.out.println("Arrays.asList(new Object[0]): " + Arrays.asList(new Object[0])); > null: null > new Object[0]: [] > Arrays.asList(new Object[0]): [] cheers, -- daniel From yasuenag at gmail.com Sat Jun 11 12:30:34 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 11 Jun 2016 21:30:34 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <9e5350d9-3eca-9384-46d5-0e3f52fd821c@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> Message-ID: <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> PING: Could you review it? We need a second reviewer. >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ This change is small fix, and it helps us to confirm current FileLogOutput configuration. So I want to merge it to jdk 9. Thanks, Yasumasa On 2016/05/17 19:17, Yasumasa Suenaga wrote: > 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 david.holmes at oracle.com Sat Jun 11 21:44:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Jun 2016 07:44:31 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> Message-ID: <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> Hi Yasumasa, Sorry but this API seems poorly fitting to me. First print_option_string seems the wrong name given that the base class, LogOutput, has no notion of having an "option string". It seems to be a supposedly generic "print other stuff" function that only one class actually needs to implement. Secondly it inverts the style of the API used for everything else - we have getters for all the other "properties" which are then printed by the describe_current_configuration method. But this is instead a "print" function where we ask the target to print itself. Mixing the two styles seems messy. It probably would have been better to have had a print-style API from the start - then adding the options would have been a trivial extension for those output classes with options. In addition the change you made to describe_current_configuration is not at all general purpose - you wanted a given format (print between the config string and the decorators) for this one class and so you added the code to support that format. But that format may not make sense for other classes that might have "extra stuff" to print. Is there some reason the option string could not simply become part of the existing configuration string? It seems to me that for a LogFile these "options" really are part of the configuration. Thanks, David PS. The two hpp files would need their copyright years updated to "2015, 2016,". On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: > PING: Could you review it? > We need a second reviewer. > >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ > > This change is small fix, and it helps us to confirm current > FileLogOutput configuration. > So I want to merge it to jdk 9. > > > Thanks, > > Yasumasa > > > On 2016/05/17 19:17, Yasumasa Suenaga wrote: >> 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 yasuenag at gmail.com Sun Jun 12 13:10:58 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 12 Jun 2016 22:10:58 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@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> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> Message-ID: <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Hi David, Thank you for your comment. > Is there some reason the option string could not simply become part of the existing configuration string? My first proposal keeps option string at LogOutput and its child class (See webrev.01). Marcus commented that option string should be generated from current configuration. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ Thanks, Yasumasa On 2016/06/12 6:44, David Holmes wrote: > Hi Yasumasa, > > Sorry but this API seems poorly fitting to me. First print_option_string seems the wrong name given that the base class, LogOutput, has no notion of having an "option string". It seems to be a supposedly generic "print other stuff" function that only one class actually needs to implement. > > Secondly it inverts the style of the API used for everything else - we have getters for all the other "properties" which are then printed by the describe_current_configuration method. But this is instead a "print" function where we ask the target to print itself. Mixing the two styles seems messy. It probably would have been better to have had a print-style API from the start - then adding the options would have been a trivial extension for those output classes with options. > > In addition the change you made to describe_current_configuration is not at all general purpose - you wanted a given format (print between the config string and the decorators) for this one class and so you added the code to support that format. But that format may not make sense for other classes that might have "extra stuff" to print. > > Is there some reason the option string could not simply become part of the existing configuration string? It seems to me that for a LogFile these "options" really are part of the configuration. > > Thanks, > David > > PS. The two hpp files would need their copyright years updated to "2015, 2016,". > > On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >> PING: Could you review it? >> We need a second reviewer. >> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >> >> This change is small fix, and it helps us to confirm current >> FileLogOutput configuration. >> So I want to merge it to jdk 9. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>> 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 yasuenag at gmail.com Sun Jun 12 13:12:34 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 12 Jun 2016 22:12:34 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <65bee8ba-6fb5-d647-b143-827b4a76e0d9@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: <519febb7-a544-89e6-239a-2746e25b2687@gmail.com> > Marcus commented that option string should be generated from current configuration. Please this email: http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-May/019598.htm On 2016/06/12 22:10, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > >> Is there some reason the option string could not simply become part of the existing configuration string? > > My first proposal keeps option string at LogOutput and its child class (See webrev.01). > Marcus commented that option string should be generated from current configuration. > > I uploaded new webrev. > Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ > > > Thanks, > > Yasumasa > > > On 2016/06/12 6:44, David Holmes wrote: >> Hi Yasumasa, >> >> Sorry but this API seems poorly fitting to me. First print_option_string seems the wrong name given that the base class, LogOutput, has no notion of having an "option string". It seems to be a supposedly generic "print other stuff" function that only one class actually needs to implement. >> >> Secondly it inverts the style of the API used for everything else - we have getters for all the other "properties" which are then printed by the describe_current_configuration method. But this is instead a "print" function where we ask the target to print itself. Mixing the two styles seems messy. It probably would have been better to have had a print-style API from the start - then adding the options would have been a trivial extension for those output classes with options. >> >> In addition the change you made to describe_current_configuration is not at all general purpose - you wanted a given format (print between the config string and the decorators) for this one class and so you added the code to support that format. But that format may not make sense for other classes that might have "extra stuff" to print. >> >> Is there some reason the option string could not simply become part of the existing configuration string? It seems to me that for a LogFile these "options" really are part of the configuration. >> >> Thanks, >> David >> >> PS. The two hpp files would need their copyright years updated to "2015, 2016,". >> >> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> We need a second reviewer. >>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>> >>> This change is small fix, and it helps us to confirm current >>> FileLogOutput configuration. >>> So I want to merge it to jdk 9. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>> 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 david.holmes at oracle.com Sun Jun 12 23:14:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2016 09:14:08 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <65bee8ba-6fb5-d647-b143-827b4a76e0d9@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > >> Is there some reason the option string could not simply become part of >> the existing configuration string? > > My first proposal keeps option string at LogOutput and its child class > (See webrev.01). > Marcus commented that option string should be generated from current > configuration. > > I uploaded new webrev. > Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ Sorry but I repeat my question - why is the option information not simply part of the config_string? Thanks, David > > Thanks, > > Yasumasa > > > On 2016/06/12 6:44, David Holmes wrote: >> Hi Yasumasa, >> >> Sorry but this API seems poorly fitting to me. First >> print_option_string seems the wrong name given that the base class, >> LogOutput, has no notion of having an "option string". It seems to be >> a supposedly generic "print other stuff" function that only one class >> actually needs to implement. >> >> Secondly it inverts the style of the API used for everything else - we >> have getters for all the other "properties" which are then printed by >> the describe_current_configuration method. But this is instead a >> "print" function where we ask the target to print itself. Mixing the >> two styles seems messy. It probably would have been better to have had >> a print-style API from the start - then adding the options would have >> been a trivial extension for those output classes with options. >> >> In addition the change you made to describe_current_configuration is >> not at all general purpose - you wanted a given format (print between >> the config string and the decorators) for this one class and so you >> added the code to support that format. But that format may not make >> sense for other classes that might have "extra stuff" to print. >> >> Is there some reason the option string could not simply become part of >> the existing configuration string? It seems to me that for a LogFile >> these "options" really are part of the configuration. >> >> Thanks, >> David >> >> PS. The two hpp files would need their copyright years updated to >> "2015, 2016,". >> >> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> We need a second reviewer. >>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>> >>> This change is small fix, and it helps us to confirm current >>> FileLogOutput configuration. >>> So I want to merge it to jdk 9. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>> 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 yasuenag at gmail.com Sun Jun 12 23:30:31 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 Jun 2016 08:30:31 +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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: Hi David, I think "config_string" is different from "option_string". -Xlog format (from -Xlog:help message): -Xlog[:[what][:[output][:[decorators][:output-options]]]] config_string: "what" (ex. gc=trace) option_string: "output-options" (ex. filecount=5) Currently, LogOutput handles tags and loglevels only as config_string. It does not contain output options. Thanks, Yasumasa On 2016/06/13 8:14, David Holmes wrote: > On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for your comment. >> >>> Is there some reason the option string could not simply become part of >>> the existing configuration string? >> >> My first proposal keeps option string at LogOutput and its child class >> (See webrev.01). >> Marcus commented that option string should be generated from current >> configuration. >> >> I uploaded new webrev. >> Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ > > Sorry but I repeat my question - why is the option information not simply part of the config_string? > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/12 6:44, David Holmes wrote: >>> Hi Yasumasa, >>> >>> Sorry but this API seems poorly fitting to me. First >>> print_option_string seems the wrong name given that the base class, >>> LogOutput, has no notion of having an "option string". It seems to be >>> a supposedly generic "print other stuff" function that only one class >>> actually needs to implement. >>> >>> Secondly it inverts the style of the API used for everything else - we >>> have getters for all the other "properties" which are then printed by >>> the describe_current_configuration method. But this is instead a >>> "print" function where we ask the target to print itself. Mixing the >>> two styles seems messy. It probably would have been better to have had >>> a print-style API from the start - then adding the options would have >>> been a trivial extension for those output classes with options. >>> >>> In addition the change you made to describe_current_configuration is >>> not at all general purpose - you wanted a given format (print between >>> the config string and the decorators) for this one class and so you >>> added the code to support that format. But that format may not make >>> sense for other classes that might have "extra stuff" to print. >>> >>> Is there some reason the option string could not simply become part of >>> the existing configuration string? It seems to me that for a LogFile >>> these "options" really are part of the configuration. >>> >>> Thanks, >>> David >>> >>> PS. The two hpp files would need their copyright years updated to >>> "2015, 2016,". >>> >>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> We need a second reviewer. >>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>> >>>> This change is small fix, and it helps us to confirm current >>>> FileLogOutput configuration. >>>> So I want to merge it to jdk 9. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>> 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 david.holmes at oracle.com Mon Jun 13 00:05:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2016 10:05:48 +1000 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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: Hi Yasumasa, On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: > Hi David, > > I think "config_string" is different from "option_string". > > -Xlog format (from -Xlog:help message): > -Xlog[:[what][:[output][:[decorators][:output-options]]]] > > config_string: "what" (ex. gc=trace) > option_string: "output-options" (ex. filecount=5) > > Currently, LogOutput handles tags and loglevels only as config_string. > It does not contain output options. Okay I'm starting to see the bigger picture here. In terms of the overall logging configuration we might have, for example: gc=trace -> stdout runtime=info -> fileA compiler=trace -> fileB where the LHS is (part of) the configuration, and the RHS is the output. So for each output we set its "configuration" to the associated LHS. So options are a distinct property of outputs and so should have been a first class entity in LogOutput all along. Okay so looking at your v4 I have two comments: First, hard-wiring OPTIONS_LEN. I don't know what the possible options are so don't know if 100 is adequate. Second, if the logging syntax is: -Xlog[:[what][:[output][:[decorators][:output-options]]]] then shouldn't the configuration be printed in the same order/format? Thanks, David > > Thanks, > > Yasumasa > > > On 2016/06/13 8:14, David Holmes wrote: >> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> Thank you for your comment. >>> >>>> Is there some reason the option string could not simply become part of >>>> the existing configuration string? >>> >>> My first proposal keeps option string at LogOutput and its child class >>> (See webrev.01). >>> Marcus commented that option string should be generated from current >>> configuration. >>> >>> I uploaded new webrev. >>> Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >> >> Sorry but I repeat my question - why is the option information not >> simply part of the config_string? >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/12 6:44, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> Sorry but this API seems poorly fitting to me. First >>>> print_option_string seems the wrong name given that the base class, >>>> LogOutput, has no notion of having an "option string". It seems to be >>>> a supposedly generic "print other stuff" function that only one class >>>> actually needs to implement. >>>> >>>> Secondly it inverts the style of the API used for everything else - we >>>> have getters for all the other "properties" which are then printed by >>>> the describe_current_configuration method. But this is instead a >>>> "print" function where we ask the target to print itself. Mixing the >>>> two styles seems messy. It probably would have been better to have had >>>> a print-style API from the start - then adding the options would have >>>> been a trivial extension for those output classes with options. >>>> >>>> In addition the change you made to describe_current_configuration is >>>> not at all general purpose - you wanted a given format (print between >>>> the config string and the decorators) for this one class and so you >>>> added the code to support that format. But that format may not make >>>> sense for other classes that might have "extra stuff" to print. >>>> >>>> Is there some reason the option string could not simply become part of >>>> the existing configuration string? It seems to me that for a LogFile >>>> these "options" really are part of the configuration. >>>> >>>> Thanks, >>>> David >>>> >>>> PS. The two hpp files would need their copyright years updated to >>>> "2015, 2016,". >>>> >>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>> PING: Could you review it? >>>>> We need a second reviewer. >>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>> >>>>> This change is small fix, and it helps us to confirm current >>>>> FileLogOutput configuration. >>>>> So I want to merge it to jdk 9. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>> 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 david.holmes at oracle.com Mon Jun 13 00:21:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2016 10:21:41 +1000 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <212723b8-6377-7820-ff36-9f53fc3bdb81@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> <53c51e7f-a8b5-2120-173c-8913ff4c7775@oracle.com> <212723b8-6377-7820-ff36-9f53fc3bdb81@oracle.com> Message-ID: <4d7a4a24-0481-82b3-9e70-a8c0f0030ddb@oracle.com> On 11/06/2016 6:12 PM, Daniel Fuchs wrote: > On 11/06/16 01:41, David Holmes wrote: >> Better, but I still wonder what Arrays.toString prints for an empty >> array? > > It prints "[]" - like Collections.emptyList().toString(): Thanks Daniel. Okay no further comments from me. David ----- > System.out.println("null: " > + Arrays.toString((Object[])null)); > System.out.println("new Object[0]: " > + Arrays.toString(new Object[0])); > System.out.println("Arrays.asList(new Object[0]): " > + Arrays.asList(new Object[0])); > >> null: null >> new Object[0]: [] >> Arrays.asList(new Object[0]): [] > > cheers, > > -- daniel From yasuenag at gmail.com Mon Jun 13 03:45:10 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 13 Jun 2016 12:45:10 +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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: Hi David, Thank you for your comment. > So options are a distinct property of outputs and so should have been a first class entity in LogOutput all along. I agree to you. But I think we need to discuss about it with logging folks. I uploaded a new webrev. It removes fixed buffer length and changes the order of output. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ Thanks, Yasumasa On 2016/06/13 9:05, David Holmes wrote: > Hi Yasumasa, > > On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> I think "config_string" is different from "option_string". >> >> -Xlog format (from -Xlog:help message): >> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >> >> config_string: "what" (ex. gc=trace) >> option_string: "output-options" (ex. filecount=5) >> >> Currently, LogOutput handles tags and loglevels only as config_string. >> It does not contain output options. > > Okay I'm starting to see the bigger picture here. In terms of the overall logging configuration we might have, for example: > > gc=trace -> stdout > runtime=info -> fileA > compiler=trace -> fileB > > where the LHS is (part of) the configuration, and the RHS is the output. So for each output we set its "configuration" to the associated LHS. > > So options are a distinct property of outputs and so should have been a first class entity in LogOutput all along. > > Okay so looking at your v4 I have two comments: > > First, hard-wiring OPTIONS_LEN. I don't know what the possible options are so don't know if 100 is adequate. > > Second, if the logging syntax is: > > -Xlog[:[what][:[output][:[decorators][:output-options]]]] > > then shouldn't the configuration be printed in the same order/format? > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 8:14, David Holmes wrote: >>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> Thank you for your comment. >>>> >>>>> Is there some reason the option string could not simply become part of >>>>> the existing configuration string? >>>> >>>> My first proposal keeps option string at LogOutput and its child class >>>> (See webrev.01). >>>> Marcus commented that option string should be generated from current >>>> configuration. >>>> >>>> I uploaded new webrev. >>>> Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>> >>> Sorry but I repeat my question - why is the option information not >>> simply part of the config_string? >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/12 6:44, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Sorry but this API seems poorly fitting to me. First >>>>> print_option_string seems the wrong name given that the base class, >>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>> a supposedly generic "print other stuff" function that only one class >>>>> actually needs to implement. >>>>> >>>>> Secondly it inverts the style of the API used for everything else - we >>>>> have getters for all the other "properties" which are then printed by >>>>> the describe_current_configuration method. But this is instead a >>>>> "print" function where we ask the target to print itself. Mixing the >>>>> two styles seems messy. It probably would have been better to have had >>>>> a print-style API from the start - then adding the options would have >>>>> been a trivial extension for those output classes with options. >>>>> >>>>> In addition the change you made to describe_current_configuration is >>>>> not at all general purpose - you wanted a given format (print between >>>>> the config string and the decorators) for this one class and so you >>>>> added the code to support that format. But that format may not make >>>>> sense for other classes that might have "extra stuff" to print. >>>>> >>>>> Is there some reason the option string could not simply become part of >>>>> the existing configuration string? It seems to me that for a LogFile >>>>> these "options" really are part of the configuration. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> PS. The two hpp files would need their copyright years updated to >>>>> "2015, 2016,". >>>>> >>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>> PING: Could you review it? >>>>>> We need a second reviewer. >>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>> >>>>>> This change is small fix, and it helps us to confirm current >>>>>> FileLogOutput configuration. >>>>>> So I want to merge it to jdk 9. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>> 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 david.holmes at oracle.com Mon Jun 13 04:24:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2016 14:24:00 +1000 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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: Hi Yasumasa, On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > >> So options are a distinct property of outputs and so should have been >> a first class entity in LogOutput all along. > > I agree to you. > But I think we need to discuss about it with logging folks. > > I uploaded a new webrev. It removes fixed buffer length and changes the > order of output. > Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? Lets wait for other feedback before going further. Thanks, David > > Thanks, > > Yasumasa > > > On 2016/06/13 9:05, David Holmes wrote: >> Hi Yasumasa, >> >> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> I think "config_string" is different from "option_string". >>> >>> -Xlog format (from -Xlog:help message): >>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>> >>> config_string: "what" (ex. gc=trace) >>> option_string: "output-options" (ex. filecount=5) >>> >>> Currently, LogOutput handles tags and loglevels only as config_string. >>> It does not contain output options. >> >> Okay I'm starting to see the bigger picture here. In terms of the >> overall logging configuration we might have, for example: >> >> gc=trace -> stdout >> runtime=info -> fileA >> compiler=trace -> fileB >> >> where the LHS is (part of) the configuration, and the RHS is the >> output. So for each output we set its "configuration" to the >> associated LHS. >> >> So options are a distinct property of outputs and so should have been >> a first class entity in LogOutput all along. >> >> Okay so looking at your v4 I have two comments: >> >> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >> are so don't know if 100 is adequate. >> >> Second, if the logging syntax is: >> >> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >> >> then shouldn't the configuration be printed in the same order/format? >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/13 8:14, David Holmes wrote: >>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> Thank you for your comment. >>>>> >>>>>> Is there some reason the option string could not simply become >>>>>> part of >>>>>> the existing configuration string? >>>>> >>>>> My first proposal keeps option string at LogOutput and its child class >>>>> (See webrev.01). >>>>> Marcus commented that option string should be generated from current >>>>> configuration. >>>>> >>>>> I uploaded new webrev. >>>>> Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>> >>>> Sorry but I repeat my question - why is the option information not >>>> simply part of the config_string? >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Sorry but this API seems poorly fitting to me. First >>>>>> print_option_string seems the wrong name given that the base class, >>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>> a supposedly generic "print other stuff" function that only one class >>>>>> actually needs to implement. >>>>>> >>>>>> Secondly it inverts the style of the API used for everything else >>>>>> - we >>>>>> have getters for all the other "properties" which are then printed by >>>>>> the describe_current_configuration method. But this is instead a >>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>> two styles seems messy. It probably would have been better to have >>>>>> had >>>>>> a print-style API from the start - then adding the options would have >>>>>> been a trivial extension for those output classes with options. >>>>>> >>>>>> In addition the change you made to describe_current_configuration is >>>>>> not at all general purpose - you wanted a given format (print between >>>>>> the config string and the decorators) for this one class and so you >>>>>> added the code to support that format. But that format may not make >>>>>> sense for other classes that might have "extra stuff" to print. >>>>>> >>>>>> Is there some reason the option string could not simply become >>>>>> part of >>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>> these "options" really are part of the configuration. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> PS. The two hpp files would need their copyright years updated to >>>>>> "2015, 2016,". >>>>>> >>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review it? >>>>>>> We need a second reviewer. >>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>> >>>>>>> This change is small fix, and it helps us to confirm current >>>>>>> FileLogOutput configuration. >>>>>>> So I want to merge it to jdk 9. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>> 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 robbin.ehn at oracle.com Mon Jun 13 05:00:55 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 13 Jun 2016 07:00:55 +0200 Subject: RFR: 8072440: serviceability/dcmd/ tests timeout In-Reply-To: <16FC4C09-0252-4FEF-86BE-0C91DE10A1BD@oracle.com> References: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> <16FC4C09-0252-4FEF-86BE-0C91DE10A1BD@oracle.com> Message-ID: <022ebd34-0ee7-25e4-5b92-797789e22973@oracle.com> Thanks Staffan! /Robbin On 06/10/2016 09:25 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 10 juni 2016, at 09:27, Robbin Ehn wrote: >> >> Hi all, >> >> I can not reproduce running the tests mutiple times on mutiple platforms. >> And I can not see anything particular in test code. >> So I'm removing the @ignore flag for these. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072440 >> Webrev: http://cr.openjdk.java.net/~rehn/8072440/webrev/ >> >> Thanks! >> >> /Robbin >> >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/HelpTest.java >> --- a/test/serviceability/dcmd/framework/HelpTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/HelpTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -39,3 +39,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/InvalidCommandTest.java >> --- a/test/serviceability/dcmd/framework/InvalidCommandTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/InvalidCommandTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -39,3 +39,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/VMVersionTest.java >> --- a/test/serviceability/dcmd/framework/VMVersionTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/VMVersionTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -40,3 +40,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> > From marcus.larsson at oracle.com Mon Jun 13 07:36:38 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 13 Jun 2016 09:36:38 +0200 Subject: RFR: 8072440: serviceability/dcmd/ tests timeout In-Reply-To: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> References: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> Message-ID: <4fca6868-e58b-dcfc-d531-005513dfbb88@oracle.com> Looks good to me! Thanks, Marcus On 2016-06-10 09:27, Robbin Ehn wrote: > Hi all, > > I can not reproduce running the tests mutiple times on mutiple platforms. > And I can not see anything particular in test code. > So I'm removing the @ignore flag for these. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072440 > Webrev: http://cr.openjdk.java.net/~rehn/8072440/webrev/ > > Thanks! > > /Robbin > > diff -r 25b6767b6c1d test/serviceability/dcmd/framework/HelpTest.java > --- a/test/serviceability/dcmd/framework/HelpTest.java Wed Jun 08 > 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/HelpTest.java Fri Jun 10 > 09:24:57 2016 +0200 > @@ -39,3 +39,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > diff -r 25b6767b6c1d > test/serviceability/dcmd/framework/InvalidCommandTest.java > --- a/test/serviceability/dcmd/framework/InvalidCommandTest.java Wed > Jun 08 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/InvalidCommandTest.java Fri > Jun 10 09:24:57 2016 +0200 > @@ -39,3 +39,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > diff -r 25b6767b6c1d > test/serviceability/dcmd/framework/VMVersionTest.java > --- a/test/serviceability/dcmd/framework/VMVersionTest.java Wed Jun > 08 16:07:49 2016 +0200 > +++ b/test/serviceability/dcmd/framework/VMVersionTest.java Fri Jun > 10 09:24:57 2016 +0200 > @@ -40,3 +40,2 @@ > * jdk.jvmstat/sun.jvmstat.monitor > - * @ignore 8072440 > * @build jdk.test.lib.* > From robbin.ehn at oracle.com Mon Jun 13 07:37:09 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 13 Jun 2016 09:37:09 +0200 Subject: RFR: 8072440: serviceability/dcmd/ tests timeout In-Reply-To: <4fca6868-e58b-dcfc-d531-005513dfbb88@oracle.com> References: <6194ffac-84a0-ebf8-a689-8a5351d811df@oracle.com> <4fca6868-e58b-dcfc-d531-005513dfbb88@oracle.com> Message-ID: <31bcc264-9cb1-4c0f-bf6c-5579bea67902@oracle.com> Thanks Marcus! /Robbin On 06/13/2016 09:36 AM, Marcus Larsson wrote: > Looks good to me! > > Thanks, > Marcus > > > On 2016-06-10 09:27, Robbin Ehn wrote: >> Hi all, >> >> I can not reproduce running the tests mutiple times on mutiple platforms. >> And I can not see anything particular in test code. >> So I'm removing the @ignore flag for these. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072440 >> Webrev: http://cr.openjdk.java.net/~rehn/8072440/webrev/ >> >> Thanks! >> >> /Robbin >> >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/HelpTest.java >> --- a/test/serviceability/dcmd/framework/HelpTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/HelpTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -39,3 +39,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/InvalidCommandTest.java >> --- a/test/serviceability/dcmd/framework/InvalidCommandTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/InvalidCommandTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -39,3 +39,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> diff -r 25b6767b6c1d test/serviceability/dcmd/framework/VMVersionTest.java >> --- a/test/serviceability/dcmd/framework/VMVersionTest.java Wed Jun 08 16:07:49 2016 +0200 >> +++ b/test/serviceability/dcmd/framework/VMVersionTest.java Fri Jun 10 09:24:57 2016 +0200 >> @@ -40,3 +40,2 @@ >> * jdk.jvmstat/sun.jvmstat.monitor >> - * @ignore 8072440 >> * @build jdk.test.lib.* >> > From staffan.larsen at oracle.com Mon Jun 13 07:57:51 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jun 2016 09:57:51 +0200 Subject: RFR: JDK-8159155 Loading the class "sun.tools.jconsole.OutputViewer" shows a modal dialog Message-ID: <7D1BA99D-8603-4BD0-B0C5-ACFF9047E951@oracle.com> Please review the small diff below - see the bug for details. This change will cause OutputViewer to misbehave if init() is called more than once. But since this is an internal class in jconsole, that restriction is not a problem bug: https://bugs.openjdk.java.net/browse/JDK-8159155 Thanks, /Staffan diff --git a/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java b/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java --- a/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java +++ b/src/jdk.jconsole/share/classes/sun/tools/jconsole/OutputViewer.java @@ -42,14 +42,11 @@ private static JFrame frame; private static JTextArea ta; - static { + public static void init() { System.setOut(PipeListener.create("System.out")); System.setErr(PipeListener.create("System.err")); } - // Dummy to cause class to be loaded - public static void init() { } - private static void append(String s) { if (frame == null) { // FIXME: The frame title should be a localized string. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 13 08:11:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jun 2016 09:11:48 +0100 Subject: RFR: JDK-8159155 Loading the class "sun.tools.jconsole.OutputViewer" shows a modal dialog In-Reply-To: <7D1BA99D-8603-4BD0-B0C5-ACFF9047E951@oracle.com> References: <7D1BA99D-8603-4BD0-B0C5-ACFF9047E951@oracle.com> Message-ID: <60b0f587-6b48-f836-9e4a-e4b05222cb47@oracle.com> On 13/06/2016 08:57, Staffan Larsen wrote: > Please review the small diff below - see the bug for details. This > change will cause OutputViewer to misbehave if init() is called more > than once. But since this is an internal class in jconsole, that > restriction is not a problem > > bug: https://bugs.openjdk.java.net/browse/JDK-8159155 > > Thanks, > /Staffan Not a review comment but a question :-) We have many classes with initializers and I'm curious why this one has been singled out. I would assume that java.desktop has many classes with initializers that load UI libraries for example. -Alan From staffan.larsen at oracle.com Mon Jun 13 08:14:26 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jun 2016 10:14:26 +0200 Subject: RFR: JDK-8159155 Loading the class "sun.tools.jconsole.OutputViewer" shows a modal dialog In-Reply-To: <60b0f587-6b48-f836-9e4a-e4b05222cb47@oracle.com> References: <7D1BA99D-8603-4BD0-B0C5-ACFF9047E951@oracle.com> <60b0f587-6b48-f836-9e4a-e4b05222cb47@oracle.com> Message-ID: <3CCF740A-4F6A-42B5-AB66-7CC2B8AF3AC6@oracle.com> > On 13 juni 2016, at 10:11, Alan Bateman wrote: > > On 13/06/2016 08:57, Staffan Larsen wrote: > >> Please review the small diff below - see the bug for details. This change will cause OutputViewer to misbehave if init() is called more than once. But since this is an internal class in jconsole, that restriction is not a problem >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159155 >> >> Thanks, >> /Staffan > Not a review comment but a question :-) We have many classes with initializers and I'm curious why this one has been singled out. I would assume that java.desktop has many classes with initializers that load UI libraries for example. I don?t know the answer to that question. Perhaps the filer of the bug can answer? /Staffan From kirill.zhaldybin at oracle.com Tue Jun 14 21:13:13 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldbybin) Date: Wed, 15 Jun 2016 00:13:13 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <40785296-15a2-36c3-eb2c-65c699730858@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> <40785296-15a2-36c3-eb2c-65c699730858@oracle.com> Message-ID: <57607369.4090302@oracle.com> Daniel, Thank you for review! Regards, Kirill On 06/10/2016 07:21 PM, Daniel Fuchs wrote: > On 10/06/16 17:23, Kirill Zhaldybin wrote: >> David, Daniel, Mandy, >> >> I changed the fix to provide "nicer" message in case if signature is >> null. >> >> Here are a new WebRev: >> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.06/ > > Looks good to me. > > -- daniel > >> >> Could you please let me know your opinion? >> >> Thank you. >> >> Regards, Kirill >> >> On 10.06.2016 12:30, David Holmes wrote: >>> On 10/06/2016 6:00 PM, Daniel Fuchs wrote: >>>> Hi Kirill, >>>> >>>> I think you might get a NullPointerException in >>>> Arrays.toString(signature) if signature == null, >>>> so you should probably guard against that. >>> >>> Yes that addition to line 269 needs more attention as it is not guarded >>> the way the previous variant is. Not sure what a zero-length array >>> might >>> produce either - for both you would want the representation of an >>> "empty" signature. >>> >>> David >>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 09/06/16 13:09, Kirill Zhaldybin wrote: >>>>> Mandy, >>>>> >>>>> Thank you for reviewing the fix! >>>>> >>>>> I added signature to another error message as you advised. >>>>> Here are a new WebRev: >>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.05/ >>>>> >>>>> Could you please let me know your opinion? >>>>> >>>>> Regards, Kirill >>>>> >>>>> On 08.06.2016 21:25, Mandy Chung wrote: >>>>>> >>>>>>> On Jun 8, 2016, at 11:26 AM, Kirill Zhaldybin >>>>>>> wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> After discussion with Mandy Chung, Daniel Fuchs and Frederic Parain >>>>>>> we decided to provide separate error message for the case if method >>>>>>> exists but signature or parametes are wrong but throw the same >>>>>>> NoSuchMethodError exception. >>>>>>> >>>>>>> Could you please review this fix for 8156226? >>>>>>> >>>>>>> New WebRev: >>>>>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8156226/webrev.04/ >>>>>> >>>>>> This looks okay. It?d be useful for the case line 269 to include >>>>>> the >>>>>> signature as well. >>>>>> >>>>>> Mandy >>>>>> >>>>> >>>> >> > From kirill.zhaldybin at oracle.com Tue Jun 14 21:13:28 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldbybin) Date: Wed, 15 Jun 2016 00:13:28 +0300 Subject: RFR(XXS): 8156226: DiagnosticCommandImpl::invoke throws NoSuchMethodException even if the method actually exists but parameters are wrong In-Reply-To: <4d7a4a24-0481-82b3-9e70-a8c0f0030ddb@oracle.com> References: <572CD172.7030700@oracle.com> <5758634F.2070107@oracle.com> <0B6E588C-0982-450C-B7A6-01CB55902890@oracle.com> <57595C97.8030004@oracle.com> <51086073-b9da-1b10-e905-c102e9b76555@oracle.com> <2ac295f5-8e97-1ef7-672e-728cf2dd0ccf@oracle.com> <575AE99B.5000109@oracle.com> <53c51e7f-a8b5-2120-173c-8913ff4c7775@oracle.com> <212723b8-6377-7820-ff36-9f53fc3bdb81@oracle.com> <4d7a4a24-0481-82b3-9e70-a8c0f0030ddb@oracle.com> Message-ID: <57607378.7020301@oracle.com> David, Thank you for review! Regards, Kirill On 06/13/2016 03:21 AM, David Holmes wrote: > > > On 11/06/2016 6:12 PM, Daniel Fuchs wrote: >> On 11/06/16 01:41, David Holmes wrote: >>> Better, but I still wonder what Arrays.toString prints for an empty >>> array? >> >> It prints "[]" - like Collections.emptyList().toString(): > > Thanks Daniel. > > Okay no further comments from me. > > David > ----- > >> System.out.println("null: " >> + Arrays.toString((Object[])null)); >> System.out.println("new Object[0]: " >> + Arrays.toString(new Object[0])); >> System.out.println("Arrays.asList(new Object[0]): " >> + Arrays.asList(new Object[0])); >> >>> null: null >>> new Object[0]: [] >>> Arrays.asList(new Object[0]): [] >> >> cheers, >> >> -- daniel From ioi.lam at oracle.com Wed Jun 15 22:14:50 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 15 Jun 2016 15:14:50 -0700 Subject: RFR(S) 8154820 - JDWP: -agentlib:jdwp=help assertion error In-Reply-To: <5761D14D.9020207@oracle.com> References: <5761D14D.9020207@oracle.com> Message-ID: <5761D35A.9030302@oracle.com> Oops. Please ignore my last mail. This one uses the correct mailing lists. - Ioi ============================================= On 6/15/16 3:06 PM, Ioi Lam wrote: Please review a small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8154820 Desc: JDWP: -agentlib:jdwp=help assertion error Fix: http://cr.openjdk.java.net/~iklam/jdk9/8154820_jdwp_help_exit.v02/ The were two issues: [1] MAXPATHLEN is really small on Windows (~256), so MAX_MESSAGE_LEN was around 1024, but the jdwp help message is about 1600 bytes. The fix would expand it to abut 2500 bytes which is more than enough. [2] The meaning of the "outputMaxLen" parameter to the utf8ToPlatform() and utf8FromPlatform() functions was ambiguous. The assert UTF_ASSERT(outputMaxLen > len); suggest that the trailing zero is included in the buffer size, so at most outputMaxLenbytes are written. However, the implementation actually would write outputMaxLen+1 bytes in the worst case. Luckily, this does not seem to be a problem as all calls to utf8ToPlatform/utf8FromPlatform allocate way more space than needed. The only exception was vprint_message, which chose to pass outputMaxLen := sizeof(buf) -1 So in the worst case, the VM would exit due to the above UTF_ASSERT, but we would not silently write one byte past the end of the buffer. The fix is: [a] Clarify the meaning of the outputMaxLen parameter [b] Make sure we don't write past the end of the buffer [c] Fix vprint_message() to pass in the correct size of the buffer to include space for the trailing zero. Thanks Ioi From serguei.spitsyn at oracle.com Thu Jun 16 00:31:50 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jun 2016 17:31:50 -0700 Subject: RFR(S) 8154820 - JDWP: -agentlib:jdwp=help assertion error In-Reply-To: <5761D35A.9030302@oracle.com> References: <5761D14D.9020207@oracle.com> <5761D35A.9030302@oracle.com> Message-ID: <5761F376.4080909@oracle.com> Hi Ioi, The fix looks good. Thank you for taking care about it! Thanks, Serguei On 6/15/16 15:14, Ioi Lam wrote: > Oops. Please ignore my last mail. This one uses the correct mailing > lists. > > - Ioi > > ============================================= > On 6/15/16 3:06 PM, Ioi Lam wrote: > > Please review a small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154820 > Desc: JDWP: -agentlib:jdwp=help assertion error > Fix: http://cr.openjdk.java.net/~iklam/jdk9/8154820_jdwp_help_exit.v02/ > > > The were two issues: > > [1] MAXPATHLEN is really small on Windows (~256), so MAX_MESSAGE_LEN > was around 1024, but the jdwp help message is about 1600 bytes. > The fix would expand it to abut 2500 bytes which is more than enough. > > [2] The meaning of the "outputMaxLen" parameter to the utf8ToPlatform() > and utf8FromPlatform() functions was ambiguous. The assert > > UTF_ASSERT(outputMaxLen > len); > > suggest that the trailing zero is included in the buffer size, so > at most outputMaxLenbytes are written. > > However, the implementation actually would write outputMaxLen+1 bytes > in the worst case. > > Luckily, this does not seem to be a problem as all calls to > utf8ToPlatform/utf8FromPlatform allocate way more space than > needed. The only exception was vprint_message, which chose to pass > > outputMaxLen := sizeof(buf) -1 > > So in the worst case, the VM would exit due to the above > UTF_ASSERT, but > we would not silently write one byte past the end of the buffer. > > The fix is: > [a] Clarify the meaning of the outputMaxLen parameter > [b] Make sure we don't write past the end of the buffer > [c] Fix vprint_message() to pass in the correct size of the > buffer to include space for the trailing zero. > > Thanks > Ioi From david.holmes at oracle.com Thu Jun 16 02:59:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jun 2016 12:59:12 +1000 Subject: RFR(S) 8154820 - JDWP: -agentlib:jdwp=help assertion error In-Reply-To: <5761D35A.9030302@oracle.com> References: <5761D14D.9020207@oracle.com> <5761D35A.9030302@oracle.com> Message-ID: <2e2d3ab4-98de-6608-2b9b-e6fd4faa796f@oracle.com> Hi Ioi, On 16/06/2016 8:14 AM, Ioi Lam wrote: > Oops. Please ignore my last mail. This one uses the correct mailing lists. > > - Ioi > > ============================================= > On 6/15/16 3:06 PM, Ioi Lam wrote: > > Please review a small fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154820 > Desc: JDWP: -agentlib:jdwp=help assertion error > Fix: http://cr.openjdk.java.net/~iklam/jdk9/8154820_jdwp_help_exit.v02/ Changes look good! I find this code generally seems to confuse lengths and indices. There is another usage in ./jdk.jdwp.agent/share/native/libjdwp/transport.c that seems suspect: /* Convert this string to UTF8 */ len = (int)strlen(msg); maxlen = len+len/2+2; /* Should allow for plenty of room */ utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); if (utf8msg != NULL) { (void)utf8FromPlatform(msg, len, utf8msg, maxlen); utf8msg[maxlen] = 0; } This should be passing in maxlen+1 as the actual buffer length. Thanks, David > > The were two issues: > > [1] MAXPATHLEN is really small on Windows (~256), so MAX_MESSAGE_LEN > was around 1024, but the jdwp help message is about 1600 bytes. > The fix would expand it to abut 2500 bytes which is more than enough. > > [2] The meaning of the "outputMaxLen" parameter to the utf8ToPlatform() > and utf8FromPlatform() functions was ambiguous. The assert > > UTF_ASSERT(outputMaxLen > len); > > suggest that the trailing zero is included in the buffer size, so > at most outputMaxLenbytes are written. > > However, the implementation actually would write outputMaxLen+1 bytes > in the worst case. > > Luckily, this does not seem to be a problem as all calls to > utf8ToPlatform/utf8FromPlatform allocate way more space than > needed. The only exception was vprint_message, which chose to pass > > outputMaxLen := sizeof(buf) -1 > > So in the worst case, the VM would exit due to the above UTF_ASSERT, > but > we would not silently write one byte past the end of the buffer. > > The fix is: > [a] Clarify the meaning of the outputMaxLen parameter > [b] Make sure we don't write past the end of the buffer > [c] Fix vprint_message() to pass in the correct size of the > buffer to include space for the trailing zero. > > Thanks > Ioi From ioi.lam at oracle.com Thu Jun 16 07:33:22 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 16 Jun 2016 00:33:22 -0700 Subject: RFR(S) 8154820 - JDWP: -agentlib:jdwp=help assertion error In-Reply-To: <2e2d3ab4-98de-6608-2b9b-e6fd4faa796f@oracle.com> References: <5761D14D.9020207@oracle.com> <5761D35A.9030302@oracle.com> <2e2d3ab4-98de-6608-2b9b-e6fd4faa796f@oracle.com> Message-ID: <57625642.1070109@oracle.com> On 6/15/16 7:59 PM, David Holmes wrote: > Hi Ioi, > > On 16/06/2016 8:14 AM, Ioi Lam wrote: >> Oops. Please ignore my last mail. This one uses the correct mailing >> lists. >> >> - Ioi >> >> ============================================= >> On 6/15/16 3:06 PM, Ioi Lam wrote: >> >> Please review a small fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154820 >> Desc: JDWP: -agentlib:jdwp=help assertion error >> Fix: http://cr.openjdk.java.net/~iklam/jdk9/8154820_jdwp_help_exit.v02/ > > Changes look good! > > I find this code generally seems to confuse lengths and indices. There > is another usage in > > ./jdk.jdwp.agent/share/native/libjdwp/transport.c > > that seems suspect: > > /* Convert this string to UTF8 */ > len = (int)strlen(msg); > maxlen = len+len/2+2; /* Should allow for plenty of room */ > utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); > if (utf8msg != NULL) { > (void)utf8FromPlatform(msg, len, utf8msg, maxlen); > utf8msg[maxlen] = 0; > } > > This should be passing in maxlen+1 as the actual buffer length. > Hi David, Thanks for pointing that out. I've added the following change and I'm rerunning the tests now. $ hg diff transport.c diff -r dfcdb0a45822 src/jdk.jdwp.agent/share/native/libjdwp/transport.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/transport.c Mon Jun 13 09:03:32 2016 -0400 +++ b/src/jdk.jdwp.agent/share/native/libjdwp/transport.c Thu Jun 16 00:31:19 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 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 @@ -67,7 +67,7 @@ maxlen = len+len/2+2; /* Should allow for plenty of room */ utf8msg = (jbyte*)jvmtiAllocate(maxlen+1); if (utf8msg != NULL) { - (void)utf8FromPlatform(msg, len, utf8msg, maxlen); + (void)utf8FromPlatform(msg, len, utf8msg, maxlen+1); utf8msg[maxlen] = 0; } } > Thanks, > David > >> >> The were two issues: >> >> [1] MAXPATHLEN is really small on Windows (~256), so MAX_MESSAGE_LEN >> was around 1024, but the jdwp help message is about 1600 bytes. >> The fix would expand it to abut 2500 bytes which is more than >> enough. >> >> [2] The meaning of the "outputMaxLen" parameter to the utf8ToPlatform() >> and utf8FromPlatform() functions was ambiguous. The assert >> >> UTF_ASSERT(outputMaxLen > len); >> >> suggest that the trailing zero is included in the buffer size, so >> at most outputMaxLenbytes are written. >> >> However, the implementation actually would write outputMaxLen+1 >> bytes >> in the worst case. >> >> Luckily, this does not seem to be a problem as all calls to >> utf8ToPlatform/utf8FromPlatform allocate way more space than >> needed. The only exception was vprint_message, which chose to pass >> >> outputMaxLen := sizeof(buf) -1 >> >> So in the worst case, the VM would exit due to the above UTF_ASSERT, >> but >> we would not silently write one byte past the end of the buffer. >> >> The fix is: >> [a] Clarify the meaning of the outputMaxLen parameter >> [b] Make sure we don't write past the end of the buffer >> [c] Fix vprint_message() to pass in the correct size of the >> buffer to include space for the trailing zero. >> >> Thanks >> Ioi From fairoz.matte at oracle.com Fri Jun 17 09:32:08 2016 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 17 Jun 2016 02:32:08 -0700 (PDT) Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info messages into err stream In-Reply-To: <96de6da4-ea44-4250-95fe-38a95ebbcea3@default> References: <96de6da4-ea44-4250-95fe-38a95ebbcea3@default> Message-ID: <2915f839-bd74-4bf8-bd6c-13d065f5708a@default> Hi, Please review the backport of bug: "JDK-6626412: jstack using SA prints some info messages into err stream" Webrev: http://cr.openjdk.java.net/~shshahma/6626412/webrev/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6626412 jdk9 changeset:http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5280822ddfcd Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013056.html Thanks, Fairoz From daniel.daugherty at oracle.com Fri Jun 17 23:22:25 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 17 Jun 2016 17:22:25 -0600 Subject: CFV: New Serviceability Group Member: Staffan Larsen Message-ID: I hereby nominate Staffan Larsen to Membership in the Serviceability Group. Staffan is a Reviewer in the jdk9 and jdk8u Projects, a member of the Serviceability team, and has so far committed > 145 changesets. He is the Serviceability architect since 2011, has been working on HotSpot for more than five years. Before joining the HotSpot team he worked with the JRockit JVM from 1999. Votes are due by 18:00, Fri, July 1, 2016 PDT. Only current Members of the Serviceability Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Daniel Daugherty [1] http://openjdk.java.net/census#serviceability [2] http://openjdk.java.net/groups/#member-vote From serguei.spitsyn at oracle.com Fri Jun 17 23:24:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jun 2016 16:24:33 -0700 Subject: CFV: New Serviceability Group Member: Staffan Larsen In-Reply-To: References: Message-ID: <576486B1.5020002@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Fri Jun 17 23:39:19 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jun 2016 16:39:19 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: References: Message-ID: <57648A27.3060905@oracle.com> Hi Alexander, I'm curious if the jtreg 4.2 is out and this test can be pushed now? I'd want to use the same pattern to write the Jigsaw related JVMTI tests. Thanks, Serguei On 5/5/16 04:25, Alexander Kulyakhtin wrote: > 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 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 daniel.daugherty at oracle.com Fri Jun 17 23:47:05 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 17 Jun 2016 17:47:05 -0600 Subject: CFV: New Serviceability Group Member: Staffan Larsen In-Reply-To: References: Message-ID: Vote: yes! Dan On 6/17/16 5:22 PM, Daniel D. Daugherty wrote: > I hereby nominate Staffan Larsen to Membership in the Serviceability > Group. > > Staffan is a Reviewer in the jdk9 and jdk8u Projects, a member of the > Serviceability team, and has so far committed > 145 changesets. He is the > Serviceability architect since 2011, has been working on HotSpot for > more than five years. Before joining the HotSpot team he worked with > the JRockit JVM from 1999. > > Votes are due by 18:00, Fri, July 1, 2016 PDT. > > Only current Members of the Serviceability Group [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Daniel Daugherty > > [1] http://openjdk.java.net/census#serviceability > [2] http://openjdk.java.net/groups/#member-vote > > From christian.tornqvist at oracle.com Sun Jun 19 00:33:45 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Sat, 18 Jun 2016 20:33:45 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <57648A27.3060905@oracle.com> References: <57648A27.3060905@oracle.com> Message-ID: Hi Serguei, We?re currently using jtreg 4.2 b02, so you should be able to do this. Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Friday, June 17, 2016 7:39 PM To: Alexander Kulyakhtin Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, I'm curious if the jtreg 4.2 is out and this test can be pushed now? I'd want to use the same pattern to write the Jigsaw related JVMTI tests. Thanks, Serguei On 5/5/16 04:25, Alexander Kulyakhtin wrote: 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 serguei.spitsyn at oracle.com Sun Jun 19 07:09:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 19 Jun 2016 00:09:44 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: References: <57648A27.3060905@oracle.com> Message-ID: <57664538.3090901@oracle.com> Hi Christian, Thank you for the reply! Serguei On 6/18/16 17:33, Christian Tornqvist wrote: > > Hi Serguei, > > We?re currently using jtreg 4.2 b02, so you should be able to do this. > > Thanks, > > Christian > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of > *serguei.spitsyn at oracle.com > *Sent:* Friday, June 17, 2016 7:39 PM > *To:* Alexander Kulyakhtin > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > Hi Alexander, > > I'm curious if the jtreg 4.2 is out and this test can be pushed now? > I'd want to use the same pattern to write the Jigsaw related JVMTI tests. > > Thanks, > Serguei > > > On 5/5/16 04:25, Alexander Kulyakhtin wrote: > > 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 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 alexander.kulyakhtin at oracle.com Mon Jun 20 11:45:41 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Mon, 20 Jun 2016 04:45:41 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <93581183-ba47-4ecf-9d66-8eb1768931b4@default> Hi Sergey, I believe the jtreg 4.2 is unreleased yet as shown here https://bugs.openjdk.java.net/projects/CODETOOLS/versions/15800 As the fix does require jtreg 4.2, so I have not yet pushed the changes. The fix is working fine with the jtreg nightly builds. Therefore, you, probably, can reuse the code of the fix as long as you are using a jtreg nightly build. Best regards, Alexander ----- Original Message ----- 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: Saturday, June 18, 2016 2:39:08 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, I'm curious if the jtreg 4.2 is out and this test can be pushed now? I'd want to use the same pattern to write the Jigsaw related JVMTI tests. Thanks, Serguei On 5/5/16 04:25, Alexander Kulyakhtin wrote: 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 alexander.kulyakhtin at oracle.com Mon Jun 20 11:48:32 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Mon, 20 Jun 2016 04:48:32 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <14d3eb9d-5cb9-40d3-96d6-534d0b48a58f@default> Hi Christian, Sergey, Thank you for the clarification. I did not realize the 4.2 is already being used. Sergey, do you want me to push the fix now or would you be pushing the fix yourself, since there may be any changes you have in mind? Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: christian.tornqvist at oracle.com, alexander.kulyakhtin at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Sunday, June 19, 2016 10:09:33 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Christian, Thank you for the reply! Serguei On 6/18/16 17:33, Christian Tornqvist wrote: Hi Serguei, We?re currently using jtreg 4.2 b02, so you should be able to do this. Thanks, Christian From: serviceability-dev [ mailto:serviceability-dev-bounces at openjdk.java.net ] On Behalf Of serguei.spitsyn at oracle.com Sent: Friday, June 17, 2016 7:39 PM To: Alexander Kulyakhtin Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, I'm curious if the jtreg 4.2 is out and this test can be pushed now? I'd want to use the same pattern to write the Jigsaw related JVMTI tests. Thanks, Serguei On 5/5/16 04:25, Alexander Kulyakhtin wrote: 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 Mon Jun 20 12:40:58 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 20 Jun 2016 21:40:58 +0900 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> <572C8C81.9010903@oracle.com> <2d5c92ad-6891-1c7c-0c7c-eb68c79b6cac@gmail.com> <1c38c514-88b6-5252-f3ca-21852bd86559@gmail.com> Message-ID: PING: What do you think about this change? Point of troubleshooting, I want to fix this issue. Thanks, Yasumasa On 2016/05/25 20:58, Yasumasa Suenaga wrote: > 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 serguei.spitsyn at oracle.com Tue Jun 21 07:46:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 00:46:32 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <57664538.3090901@oracle.com> References: <57648A27.3060905@oracle.com> <57664538.3090901@oracle.com> Message-ID: <5768F0D8.8040102@oracle.com> Hi Christian and Alexander, Not sure if my code is correct but I can not pass through the following agent library load error: Error occurred during initialization of VM Could not find agent library GetModuleByPkgTest1 on the library path, with error: libGetModuleByPkgTest1.so: cannot open shared object file: No such file or directory I'm using the following shell script to run my test: #!/bin/sh IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images JAVA_HOME=$IMAGES/jdk export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native # /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \ /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \ -J-Dtest.java.opts='-Xmixed -server' \ -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \ /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java The jtreg lines are: % cat -50 test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java /* * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ /** * @test * @summary Verifies the JVMTI GetModuleByPackageName API * @compile GetModuleByPkgTest1.java * @run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 */ . . . Please, let me know if you see anything wrong in my testing environment. Below is the full .jtr log. Thanks, Serguei cat ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr #Test Results (version 2) #Tue Jun 21 00:33:26 PDT 2016 #checksum:265f9695e52dbedb #-----testdescription----- $file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java $root=/var/tmp/sspitsyn/jdk9/hotspot/test keywords=othervm run=USER_SPECIFIED compile GetModuleByPkgTest1.java\nUSER_SPECIFIED main/othervm -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n source=GetModuleByPkgTest1.java title=Verifies the JVMTI GetModuleByPackageName API #-----environment----- #-----testresult----- description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java elapsed=2061 0\:00\:02.061 end=Tue Jun 21 00\:33\:26 PDT 2016 environment=regtest execStatus=Failed. Unexpected exit from test [exit code\: 1] hostname=sc11137378.us.oracle.com javatestOS=Linux 3.2.0-55-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.2 fcs b02 script=com.sun.javatest.regtest.RegressionScript sections=script_messages compile build main start=Tue Jun 21 00\:33\:24 PDT 2016 test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk user.name=sspitsyn work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName #section:script_messages ----------messages:(5/324)---------- JDK under test: /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk java version "9-internal" Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-06-09-145126.sspitsyn.jdk9) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode) #section:compile ----------messages:(4/233)---------- command: compile /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java reason: User specified action: run compile GetModuleByPkgTest1.java Mode: othervm elapsed time (seconds): 1.7 ----------configuration:(4/227)---------- javac compilation environment class path: /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName ----------rerun:(21/1677)*---------- DISPLAY=localhost:11.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac \\ -J'-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.compiler.opts= \\ -J-Dtest.java.opts= \\ -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dtest.timeout.factor=1.0 \\ -d /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -sourcepath /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -classpath /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:build ----------messages:(3/104)---------- command: build GetModuleByPkgTest1 reason: Named class compiled on demand elapsed time (seconds): 0.002 result: Passed. All files up to date #section:main ----------messages:(4/228)---------- command: main -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 reason: User specified action: run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 Mode: othervm [/othervm specified] elapsed time (seconds): 0.017 ----------configuration:(0/0)---------- ----------System.out:(2/210)---------- Error occurred during initialization of VM Could not find agent library GetModuleByPkgTest1 on the library path, with error: libGetModuleByPkgTest1.so: cannot open shared object file: No such file or directory ----------System.err:(0/0)---------- ----------rerun:(21/1756)*---------- DISPLAY=localhost:11.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar \\ /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java \\ -Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ -Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dtest.timeout.factor=1.0 \\ '-Dtest.java.opts=-Xmixed -server' \\ -agentlib:GetModuleByPkgTest1 \\ com.sun.javatest.regtest.agent.MainWrapper /var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.d/main.0.jta result: Failed. Unexpected exit from test [exit code: 1] test result: Failed. Unexpected exit from test [exit code: 1] Thanks, Serguei On 6/19/16 00:09, serguei.spitsyn at oracle.com wrote: > Hi Christian, > > Thank you for the reply! > Serguei > > > On 6/18/16 17:33, Christian Tornqvist wrote: >> >> Hi Serguei, >> >> We?re currently using jtreg 4.2 b02, so you should be able to do this. >> >> Thanks, >> >> Christian >> >> *From:*serviceability-dev >> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >> *serguei.spitsyn at oracle.com >> *Sent:* Friday, June 17, 2016 7:39 PM >> *To:* Alexander Kulyakhtin >> *Cc:* serviceability-dev at openjdk.java.net >> *Subject:* Re: RFR:8153978:New test to verify the modules info as >> returned by the JVMTI >> >> Hi Alexander, >> >> I'm curious if the jtreg 4.2 is out and this test can be pushed now? >> I'd want to use the same pattern to write the Jigsaw related JVMTI tests. >> >> Thanks, >> Serguei >> >> >> On 5/5/16 04:25, Alexander Kulyakhtin wrote: >> >> 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 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 serguei.spitsyn at oracle.com Tue Jun 21 08:54:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 01:54:41 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <5768F0D8.8040102@oracle.com> References: <57648A27.3060905@oracle.com> <57664538.3090901@oracle.com> <5768F0D8.8040102@oracle.com> Message-ID: <576900D1.5050502@oracle.com> Ok, I've found how to work around my problem below. The flag -nativepath needs to be passed to the jtreg: -nativepath:/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/test/hotspot/jtreg/native Thanks, Serguei On 6/21/16 00:46, serguei.spitsyn at oracle.com wrote: > Hi Christian and Alexander, > > Not sure if my code is correct but I can not pass through the > following agent library load error: > > Error occurred during initialization of VM > Could not find agent library GetModuleByPkgTest1 on the library > path, with error: libGetModuleByPkgTest1.so: cannot open shared object > file: No such file or directory > > > I'm using the following shell script to run my test: > > #!/bin/sh > > IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images > JAVA_HOME=$IMAGES/jdk > export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native > > # /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \ > > /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \ > -J-Dtest.java.opts='-Xmixed -server' \ > -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \ > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > > > > The jtreg lines are: > > % cat -50 > test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > /* > * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > */ > > /** > * @test > * @summary Verifies the JVMTI GetModuleByPackageName API > * @compile GetModuleByPkgTest1.java > * @run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 > */ > . . . > > Please, let me know if you see anything wrong in my testing environment. > Below is the full .jtr log. > > Thanks, > Serguei > > cat > ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr > #Test Results (version 2) > #Tue Jun 21 00:33:26 PDT 2016 > #checksum:265f9695e52dbedb > #-----testdescription----- > $file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > $root=/var/tmp/sspitsyn/jdk9/hotspot/test > keywords=othervm > run=USER_SPECIFIED compile GetModuleByPkgTest1.java\nUSER_SPECIFIED > main/othervm -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n > source=GetModuleByPkgTest1.java > title=Verifies the JVMTI GetModuleByPackageName API > > #-----environment----- > > #-----testresult----- > description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > elapsed=2061 0\:00\:02.061 > end=Tue Jun 21 00\:33\:26 PDT 2016 > environment=regtest > execStatus=Failed. Unexpected exit from test [exit code\: 1] > hostname=sc11137378.us.oracle.com > javatestOS=Linux 3.2.0-55-generic (amd64) > javatestVersion=4.4 > jtregVersion=jtreg 4.2 fcs b02 > script=com.sun.javatest.regtest.RegressionScript > sections=script_messages compile build main > start=Tue Jun 21 00\:33\:24 PDT 2016 > test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > user.name=sspitsyn > work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName > > #section:script_messages > ----------messages:(5/324)---------- > JDK under test: > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-06-09-145126.sspitsyn.jdk9) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode) > > > #section:compile > ----------messages:(4/233)---------- > command: compile > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > reason: User specified action: run compile GetModuleByPkgTest1.java > Mode: othervm > elapsed time (seconds): 1.7 > ----------configuration:(4/227)---------- > javac compilation environment > class path: > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > > /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > > > ----------rerun:(21/1677)*---------- > DISPLAY=localhost:11.0 \\ > HOME=/home/sspitsyn \\ > JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ > LANG=en_US.UTF-8 \\ > PATH=/bin:/usr/bin \\ > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac > \\ > -J'-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.compiler.opts= \\ > -J-Dtest.java.opts= \\ > -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -J-Dtest.timeout.factor=1.0 \\ > -d > /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -sourcepath > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -classpath > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > ----------System.out:(0/0)---------- > ----------System.err:(0/0)---------- > result: Passed. Compilation successful > > #section:build > ----------messages:(3/104)---------- > command: build GetModuleByPkgTest1 > reason: Named class compiled on demand > elapsed time (seconds): 0.002 > result: Passed. All files up to date > > #section:main > ----------messages:(4/228)---------- > command: main -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 > reason: User specified action: run main/othervm > -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.017 > ----------configuration:(0/0)---------- > ----------System.out:(2/210)---------- > Error occurred during initialization of VM > Could not find agent library GetModuleByPkgTest1 on the library path, > with error: libGetModuleByPkgTest1.so: cannot open shared object file: > No such file or directory > ----------System.err:(0/0)---------- > ----------rerun:(21/1756)*---------- > DISPLAY=localhost:11.0 \\ > HOME=/home/sspitsyn \\ > JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ > LANG=en_US.UTF-8 \\ > PATH=/bin:/usr/bin \\ > CLASSPATH=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar > \\ > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > \\ > -Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ > -Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ > -Dtest.compiler.opts= \\ > -Dtest.java.opts= \\ > -Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -Dtest.timeout.factor=1.0 \\ > '-Dtest.java.opts=-Xmixed -server' \\ > -agentlib:GetModuleByPkgTest1 \\ > com.sun.javatest.regtest.agent.MainWrapper > /var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.d/main.0.jta > result: Failed. Unexpected exit from test [exit code: 1] > > > test result: Failed. Unexpected exit from test [exit code: 1] > > Thanks, > Serguei > > > On 6/19/16 00:09, serguei.spitsyn at oracle.com wrote: >> Hi Christian, >> >> Thank you for the reply! >> Serguei >> >> >> On 6/18/16 17:33, Christian Tornqvist wrote: >>> >>> Hi Serguei, >>> >>> We?re currently using jtreg 4.2 b02, so you should be able to do this. >>> >>> Thanks, >>> >>> Christian >>> >>> *From:*serviceability-dev >>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >>> *serguei.spitsyn at oracle.com >>> *Sent:* Friday, June 17, 2016 7:39 PM >>> *To:* Alexander Kulyakhtin >>> *Cc:* serviceability-dev at openjdk.java.net >>> *Subject:* Re: RFR:8153978:New test to verify the modules info as >>> returned by the JVMTI >>> >>> Hi Alexander, >>> >>> I'm curious if the jtreg 4.2 is out and this test can be pushed now? >>> I'd want to use the same pattern to write the Jigsaw related JVMTI >>> tests. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/5/16 04:25, Alexander Kulyakhtin wrote: >>> >>> 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 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 fairoz.matte at oracle.com Tue Jun 21 09:01:52 2016 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Tue, 21 Jun 2016 02:01:52 -0700 (PDT) Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info messages into err stream In-Reply-To: <2915f839-bd74-4bf8-bd6c-13d065f5708a@default> References: <96de6da4-ea44-4250-95fe-38a95ebbcea3@default> <2915f839-bd74-4bf8-bd6c-13d065f5708a@default> Message-ID: <5d265210-ed8b-44a4-89e5-60686b50edcb@default> PING.... Someone could please review this, It is back port to 7. Only modification is changing info messages from err string - PrintStream err = System.err; + PrintStream out = System.out; And respective err to out in single file Thanks, Fairoz > -----Original Message----- > From: Fairoz Matte > Sent: Friday, June 17, 2016 3:02 PM > To: serviceability-dev at openjdk.java.net > Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info > messages into err stream > > Hi, > > Please review the backport of bug: "JDK-6626412: jstack using SA prints > some info messages into err stream" > > Webrev: http://cr.openjdk.java.net/~shshahma/6626412/webrev/ > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6626412 > > jdk9 > changeset:http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5280822ddfcd > > Review thread: http://mail.openjdk.java.net/pipermail/serviceability- > dev/2013-November/013056.html > > Thanks, > Fairoz From serguei.spitsyn at oracle.com Tue Jun 21 09:39:26 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 02:39:26 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <576900D1.5050502@oracle.com> References: <57648A27.3060905@oracle.com> <57664538.3090901@oracle.com> <5768F0D8.8040102@oracle.com> <576900D1.5050502@oracle.com> Message-ID: <57690B4E.1060503@oracle.com> On 6/21/16 01:54, serguei.spitsyn at oracle.com wrote: > Ok, I've found how to work around my problem below. > > The flag -nativepath needs to be passed to the jtreg: > -nativepath:/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/test/hotspot/jtreg/native Question: Is this flag passed when the jtreg tests are run in the nightly? Do I have to adjust anything in order to make new test with the native agent to pass in nightly? Thanks, Serguei > > Thanks, > Serguei > > > On 6/21/16 00:46, serguei.spitsyn at oracle.com wrote: >> Hi Christian and Alexander, >> >> Not sure if my code is correct but I can not pass through the >> following agent library load error: >> >> Error occurred during initialization of VM >> Could not find agent library GetModuleByPkgTest1 on the library >> path, with error: libGetModuleByPkgTest1.so: cannot open shared >> object file: No such file or directory >> >> >> I'm using the following shell script to run my test: >> >> #!/bin/sh >> >> IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images >> JAVA_HOME=$IMAGES/jdk >> export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native >> >> # /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \ >> >> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \ >> -J-Dtest.java.opts='-Xmixed -server' \ >> -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \ >> /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> >> >> >> The jtreg lines are: >> >> % cat -50 >> test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> /* >> * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. >> */ >> >> /** >> * @test >> * @summary Verifies the JVMTI GetModuleByPackageName API >> * @compile GetModuleByPkgTest1.java >> * @run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 >> */ >> . . . >> >> Please, let me know if you see anything wrong in my testing environment. >> Below is the full .jtr log. >> >> Thanks, >> Serguei >> >> cat >> ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr >> #Test Results (version 2) >> #Tue Jun 21 00:33:26 PDT 2016 >> #checksum:265f9695e52dbedb >> #-----testdescription----- >> $file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> $root=/var/tmp/sspitsyn/jdk9/hotspot/test >> keywords=othervm >> run=USER_SPECIFIED compile GetModuleByPkgTest1.java\nUSER_SPECIFIED >> main/othervm -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n >> source=GetModuleByPkgTest1.java >> title=Verifies the JVMTI GetModuleByPackageName API >> >> #-----environment----- >> >> #-----testresult----- >> description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> elapsed=2061 0\:00\:02.061 >> end=Tue Jun 21 00\:33\:26 PDT 2016 >> environment=regtest >> execStatus=Failed. Unexpected exit from test [exit code\: 1] >> hostname=sc11137378.us.oracle.com >> javatestOS=Linux 3.2.0-55-generic (amd64) >> javatestVersion=4.4 >> jtregVersion=jtreg 4.2 fcs b02 >> script=com.sun.javatest.regtest.RegressionScript >> sections=script_messages compile build main >> start=Tue Jun 21 00\:33\:24 PDT 2016 >> test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> user.name=sspitsyn >> work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName >> >> #section:script_messages >> ----------messages:(5/324)---------- >> JDK under test: >> /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> java version "9-internal" >> Java(TM) SE Runtime Environment (fastdebug build >> 9-internal+0-2016-06-09-145126.sspitsyn.jdk9) >> Java HotSpot(TM) 64-Bit Server VM (fastdebug build >> 9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode) >> >> >> #section:compile >> ----------messages:(4/233)---------- >> command: compile >> /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> reason: User specified action: run compile GetModuleByPkgTest1.java >> Mode: othervm >> elapsed time (seconds): 1.7 >> ----------configuration:(4/227)---------- >> javac compilation environment >> class path: >> /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> >> /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> >> >> ----------rerun:(21/1677)*---------- >> DISPLAY=localhost:11.0 \\ >> HOME=/home/sspitsyn \\ >> JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ >> LANG=en_US.UTF-8 \\ >> PATH=/bin:/usr/bin \\ >> /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac >> \\ >> -J'-Dtest.java.opts=-Xmixed -server' \\ >> -J-Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> \\ >> -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> \\ >> -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> \\ >> -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> \\ >> -J-Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ >> -J-Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ >> -J-Dtest.compiler.opts= \\ >> -J-Dtest.java.opts= \\ >> -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> \\ >> -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> \\ >> -J-Dtest.timeout.factor=1.0 \\ >> -d >> /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> \\ >> -sourcepath >> /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> \\ >> -classpath >> /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java >> ----------System.out:(0/0)---------- >> ----------System.err:(0/0)---------- >> result: Passed. Compilation successful >> >> #section:build >> ----------messages:(3/104)---------- >> command: build GetModuleByPkgTest1 >> reason: Named class compiled on demand >> elapsed time (seconds): 0.002 >> result: Passed. All files up to date >> >> #section:main >> ----------messages:(4/228)---------- >> command: main -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 >> reason: User specified action: run main/othervm >> -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 0.017 >> ----------configuration:(0/0)---------- >> ----------System.out:(2/210)---------- >> Error occurred during initialization of VM >> Could not find agent library GetModuleByPkgTest1 on the library path, >> with error: libGetModuleByPkgTest1.so: cannot open shared object >> file: No such file or directory >> ----------System.err:(0/0)---------- >> ----------rerun:(21/1756)*---------- >> DISPLAY=localhost:11.0 \\ >> HOME=/home/sspitsyn \\ >> JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ >> LANG=en_US.UTF-8 \\ >> PATH=/bin:/usr/bin \\ >> CLASSPATH=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar >> \\ >> /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java >> \\ >> -Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> \\ >> -Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName >> \\ >> -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> \\ >> -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName >> \\ >> -Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ >> -Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ >> -Dtest.compiler.opts= \\ >> -Dtest.java.opts= \\ >> -Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> \\ >> -Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk >> \\ >> -Dtest.timeout.factor=1.0 \\ >> '-Dtest.java.opts=-Xmixed -server' \\ >> -agentlib:GetModuleByPkgTest1 \\ >> com.sun.javatest.regtest.agent.MainWrapper >> /var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.d/main.0.jta >> result: Failed. Unexpected exit from test [exit code: 1] >> >> >> test result: Failed. Unexpected exit from test [exit code: 1] >> >> Thanks, >> Serguei >> >> >> On 6/19/16 00:09, serguei.spitsyn at oracle.com wrote: >>> Hi Christian, >>> >>> Thank you for the reply! >>> Serguei >>> >>> >>> On 6/18/16 17:33, Christian Tornqvist wrote: >>>> >>>> Hi Serguei, >>>> >>>> We?re currently using jtreg 4.2 b02, so you should be able to do this. >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> *From:*serviceability-dev >>>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of >>>> *serguei.spitsyn at oracle.com >>>> *Sent:* Friday, June 17, 2016 7:39 PM >>>> *To:* Alexander Kulyakhtin >>>> *Cc:* serviceability-dev at openjdk.java.net >>>> *Subject:* Re: RFR:8153978:New test to verify the modules info as >>>> returned by the JVMTI >>>> >>>> Hi Alexander, >>>> >>>> I'm curious if the jtreg 4.2 is out and this test can be pushed now? >>>> I'd want to use the same pattern to write the Jigsaw related JVMTI >>>> tests. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/5/16 04:25, Alexander Kulyakhtin wrote: >>>> >>>> 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 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 serguei.spitsyn at oracle.com Tue Jun 21 09:54:03 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 02:54:03 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName Message-ID: <57690EBB.2010007@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Summary: JVM TI agents that instrument code in named modules need the Module at class load time. One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. The alternative option is a JVM TI function that maps a classloader + package name to a module. We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. This fix is to introduce new JVMTI function GetModuleByPackageName. It includes new jtreg test with native JVMTI agent. A CCC is fast-tracked and getting an approval is in progress. Testing: Run newly developed jtreg test. Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 21 10:23:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jun 2016 11:23:47 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > Serguei - can you put the patches on cr.openjdk.java.net? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 21 10:48:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 03:48:39 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> Message-ID: <57691B87.20104@oracle.com> On 6/21/16 03:23, Alan Bateman wrote: > > > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> > Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 21 10:49:55 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 03:49:55 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576914BE.1030309@redhat.com> References: <57690EBB.2010007@oracle.com> <576914BE.1030309@redhat.com> Message-ID: <57691BD3.2000406@oracle.com> Hi Andrew, Please, find the public webrevs in my reply to Alan. Thanks, Serguei On 6/21/16 03:19, Andrew Dinn wrote: > On 21/06/16 10:54, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > I don't seem to be able to access those webrevs: > > > Server not found > > Firefox can't find the server at javaweb.sfbay.sun.com. > . . . > > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From alexander.kulyakhtin at oracle.com Tue Jun 21 10:59:03 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 21 Jun 2016 03:59:03 -0700 (PDT) Subject: RFR: 8159959: Quarantine the test java/lang/management/MemoryMXBean/Pending.java Message-ID: <6f4e4d19-35bc-4eb1-b3a6-28daa76a57ae@default> Hi, Could I, please, have a review of this trivial change (quarantining 1 test): CR: https://bugs.openjdk.java.net/browse/JDK-8159959 "Quarantine java/lang/management/MemoryMXBean/Pending.java" Webrev: http://cr.openjdk.java.net/~akulyakh/8159959/test/ProblemList.txt.udiff.html Best regards, Alexander From Alan.Bateman at oracle.com Tue Jun 21 11:56:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jun 2016 12:56:01 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: On 21/06/2016 11:48, serguei.spitsyn at oracle.com wrote: > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the jtreg > format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > The spec generally looks good, just two small points: 1. "java.lang.ClassLoader" would be better than "java/lang/ClassLoader" when describing the class_loader parameter. 2. For the package name then it might be clearer to say that the package name is in internal form and then include the example of "java/lang" in parenthesis. One comment on the test is that it looks like check_system_loader doesn't test any packages that are defined to a module. check_bootstrap_loader does have tests for named modules for the null loader case. Just wondering if we need more here. You might have spotted this already but the header comment on the tests needs to be the GPL header. -Alan From christian.tornqvist at oracle.com Tue Jun 21 11:56:29 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Jun 2016 07:56:29 -0400 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: Hi Serguei, I?ve only looked at the test code so far, here are some comments: * You?re not allowed to call System.exit in a jtreg test. If something fails, you need to throw an exception. * Instead of a run() method you could simply collapse all this into the main method like this: assertEQ(check(), 0); * Would it make sense to throw exceptions with useful error messages from the JNI code instead of returning failed status codes? Our error matching system would work a lot better with unique error messages. Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 6:49 AM To: Alan Bateman ; serviceability-dev at openjdk.java.net; Christian T?rnqvist ; Alexander Kulyakhtin ; hotspot-dev at openjdk.java.net Developers Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName On 6/21/16 03:23, Alan Bateman wrote: On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Tue Jun 21 12:11:14 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Jun 2016 08:11:14 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <57690B4E.1060503@oracle.com> References: <57648A27.3060905@oracle.com> <57664538.3090901@oracle.com> <5768F0D8.8040102@oracle.com> <576900D1.5050502@oracle.com> <57690B4E.1060503@oracle.com> Message-ID: Hi Serguei, Yes, this is path is set in the make files/scripts that run jtreg. Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 5:39 AM To: Christian Tornqvist ; 'Alexander Kulyakhtin' Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 6/21/16 01:54, serguei.spitsyn at oracle.com wrote: Ok, I've found how to work around my problem below. The flag -nativepath needs to be passed to the jtreg: -nativepath:/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/test/hotspot/jtreg/native Question: Is this flag passed when the jtreg tests are run in the nightly? Do I have to adjust anything in order to make new test with the native agent to pass in nightly? Thanks, Serguei Thanks, Serguei On 6/21/16 00:46, serguei.spitsyn at oracle.com wrote: Hi Christian and Alexander, Not sure if my code is correct but I can not pass through the following agent library load error: Error occurred during initialization of VM Could not find agent library GetModuleByPkgTest1 on the library path, with error: libGetModuleByPkgTest1.so: cannot open shared object file: No such file or directory I'm using the following shell script to run my test: #!/bin/sh IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images JAVA_HOME=$IMAGES/jdk export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native # /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \ /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \ -J-Dtest.java.opts='-Xmixed -server' \ -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \ /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java The jtreg lines are: % cat -50 test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java /* * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ /** * @test * @summary Verifies the JVMTI GetModuleByPackageName API * @compile GetModuleByPkgTest1.java * @run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 */ . . . Please, let me know if you see anything wrong in my testing environment. Below is the full .jtr log. Thanks, Serguei cat ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr #Test Results (version 2) #Tue Jun 21 00:33:26 PDT 2016 #checksum:265f9695e52dbedb #-----testdescription----- $file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java $root=/var/tmp/sspitsyn/jdk9/hotspot/test keywords=othervm run=USER_SPECIFIED compile GetModuleByPkgTest1.java\nUSER_SPECIFIED main/othervm -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n source=GetModuleByPkgTest1.java title=Verifies the JVMTI GetModuleByPackageName API #-----environment----- #-----testresult----- description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java elapsed=2061 0\:00\:02.061 end=Tue Jun 21 00\:33\:26 PDT 2016 environment=regtest execStatus=Failed. Unexpected exit from test [exit code\: 1] hostname=sc11137378.us.oracle.com javatestOS=Linux 3.2.0-55-generic (amd64) javatestVersion=4.4 jtregVersion=jtreg 4.2 fcs b02 script=com.sun.javatest.regtest.RegressionScript sections=script_messages compile build main start=Tue Jun 21 00\:33\:24 PDT 2016 test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk user.name=sspitsyn work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName #section:script_messages ----------messages:(5/324)---------- JDK under test: /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk java version "9-internal" Java(TM) SE Runtime Environment (fastdebug build 9-internal+0-2016-06-09-145126.sspitsyn.jdk9) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode) #section:compile ----------messages:(4/233)---------- command: compile /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java reason: User specified action: run compile GetModuleByPkgTest1.java Mode: othervm elapsed time (seconds): 1.7 ----------configuration:(4/227)---------- javac compilation environment class path: /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName ----------rerun:(21/1677)*---------- DISPLAY=localhost:11.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac \\ -J'-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -J-Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ -J-Dtest.compiler.opts= \\ -J-Dtest.java.opts= \\ -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -J-Dtest.timeout.factor=1.0 \\ -d /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -sourcepath /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -classpath /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:build ----------messages:(3/104)---------- command: build GetModuleByPkgTest1 reason: Named class compiled on demand elapsed time (seconds): 0.002 result: Passed. All files up to date #section:main ----------messages:(4/228)---------- command: main -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 reason: User specified action: run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 Mode: othervm [/othervm specified] elapsed time (seconds): 0.017 ----------configuration:(0/0)---------- ----------System.out:(2/210)---------- Error occurred during initialization of VM Could not find agent library GetModuleByPkgTest1 on the library path, with error: libGetModuleByPkgTest1.so: cannot open shared object file: No such file or directory ----------System.err:(0/0)---------- ----------rerun:(21/1756)*---------- DISPLAY=localhost:11.0 \\ HOME=/home/sspitsyn \\ JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar \\ /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java \\ -Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName \\ -Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ -Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk \\ -Dtest.timeout.factor=1.0 \\ '-Dtest.java.opts=-Xmixed -server' \\ -agentlib:GetModuleByPkgTest1 \\ com.sun.javatest.regtest.agent.MainWrapper /var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.d/main.0.jta result: Failed. Unexpected exit from test [exit code: 1] test result: Failed. Unexpected exit from test [exit code: 1] Thanks, Serguei On 6/19/16 00:09, serguei.spitsyn at oracle.com wrote: Hi Christian, Thank you for the reply! Serguei On 6/18/16 17:33, Christian Tornqvist wrote: Hi Serguei, We?re currently using jtreg 4.2 b02, so you should be able to do this. Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Friday, June 17, 2016 7:39 PM To: Alexander Kulyakhtin Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, I'm curious if the jtreg 4.2 is out and this test can be pushed now? I'd want to use the same pattern to write the Jigsaw related JVMTI tests. Thanks, Serguei On 5/5/16 04:25, Alexander Kulyakhtin wrote: 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 sean.coffey at oracle.com Tue Jun 21 13:31:26 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 21 Jun 2016 14:31:26 +0100 Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info messages into err stream In-Reply-To: <5d265210-ed8b-44a4-89e5-60686b50edcb@default> References: <96de6da4-ea44-4250-95fe-38a95ebbcea3@default> <2915f839-bd74-4bf8-bd6c-13d065f5708a@default> <5d265210-ed8b-44a4-89e5-60686b50edcb@default> Message-ID: <17819410-e16f-1c58-2f3b-ba7aaf5266dd@oracle.com> Do we really need to fix this in JDK 7u ? It's a P4 that brings behavioural change to a JDK release that well mature now. It could introduce issues for tooling that might be seperating out the stdout and stderr streams. 'java -version' also prints to the err stream :-D Regards, Sean. On 21/06/2016 10:01, Fairoz Matte wrote: > PING.... > > Someone could please review this, It is back port to 7. Only modification is changing info messages from err string > - PrintStream err = System.err; > + PrintStream out = System.out; > > And respective err to out in single file > > Thanks, > Fairoz > >> -----Original Message----- >> From: Fairoz Matte >> Sent: Friday, June 17, 2016 3:02 PM >> To: serviceability-dev at openjdk.java.net >> Subject: [7u] RFR: JDK-6626412: jstack using SA prints some info >> messages into err stream >> >> Hi, >> >> Please review the backport of bug: "JDK-6626412: jstack using SA prints >> some info messages into err stream" >> >> Webrev: http://cr.openjdk.java.net/~shshahma/6626412/webrev/ >> >> jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6626412 >> >> jdk9 >> changeset:http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5280822ddfcd >> >> Review thread: http://mail.openjdk.java.net/pipermail/serviceability- >> dev/2013-November/013056.html >> >> Thanks, >> Fairoz From serguei.spitsyn at oracle.com Tue Jun 21 14:49:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 07:49:51 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: References: <57648A27.3060905@oracle.com> <57664538.3090901@oracle.com> <5768F0D8.8040102@oracle.com> <576900D1.5050502@oracle.com> <57690B4E.1060503@oracle.com> Message-ID: <5769540F.7080403@oracle.com> Hi Christian, Ok, thanks! Serguei On 6/21/16 05:11, Christian Tornqvist wrote: > > Hi Serguei, > > Yes, this is path is set in the make files/scripts that run jtreg. > > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 5:39 AM > *To:* Christian Tornqvist ; 'Alexander > Kulyakhtin' > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > On 6/21/16 01:54, serguei.spitsyn at oracle.com > wrote: > > Ok, I've found how to work around my problem below. > > The flag -nativepath needs to be passed to the jtreg: > -nativepath:/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/test/hotspot/jtreg/native > > > Question: > Is this flag passed when the jtreg tests are run in the nightly? > Do I have to adjust anything in order to make new test with the > native agent to pass in nightly? > > Thanks, > Serguei > > > > Thanks, > Serguei > > > On 6/21/16 00:46, serguei.spitsyn at oracle.com > wrote: > > Hi Christian and Alexander, > > Not sure if my code is correct but I can not pass through the > following agent library load error: > > Error occurred during initialization of VM > Could not find agent library GetModuleByPkgTest1 on the > library path, with error: libGetModuleByPkgTest1.so: cannot > open shared object file: No such file or directory > > > I'm using the following shell script to run my test: > > #!/bin/sh > > IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images > JAVA_HOME=$IMAGES/jdk > export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native > > # /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \ > > /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \ > -J-Dtest.java.opts='-Xmixed -server' \ > -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \ > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > > > > The jtreg lines are: > > % cat -50 > test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > /* > * Copyright (c) 2016, Oracle and/or its affiliates. All > rights reserved. > * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license > terms. > */ > > /** > * @test > * @summary Verifies the JVMTI GetModuleByPackageName API > * @compile GetModuleByPkgTest1.java > * @run main/othervm -agentlib:GetModuleByPkgTest1 > GetModuleByPkgTest1 > */ > . . . > > Please, let me know if you see anything wrong in my testing > environment. > Below is the full .jtr log. > > Thanks, > Serguei > > cat > ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr > #Test Results (version 2) > #Tue Jun 21 00:33:26 PDT 2016 > #checksum:265f9695e52dbedb > #-----testdescription----- > $file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > $root=/var/tmp/sspitsyn/jdk9/hotspot/test > keywords=othervm > run=USER_SPECIFIED compile > GetModuleByPkgTest1.java\nUSER_SPECIFIED main/othervm > -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n > source=GetModuleByPkgTest1.java > title=Verifies the JVMTI GetModuleByPackageName API > > #-----environment----- > > #-----testresult----- > description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > elapsed=2061 0\:00\:02.061 > end=Tue Jun 21 00\:33\:26 PDT 2016 > environment=regtest > execStatus=Failed. Unexpected exit from test [exit code\: 1] > hostname=sc11137378.us.oracle.com > javatestOS=Linux 3.2.0-55-generic (amd64) > javatestVersion=4.4 > jtregVersion=jtreg 4.2 fcs b02 > script=com.sun.javatest.regtest.RegressionScript > sections=script_messages compile build main > start=Tue Jun 21 00\:33\:24 PDT 2016 > test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > user.name=sspitsyn > work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName > > #section:script_messages > ----------messages:(5/324)---------- > JDK under test: > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > java version "9-internal" > Java(TM) SE Runtime Environment (fastdebug build > 9-internal+0-2016-06-09-145126.sspitsyn.jdk9) > Java HotSpot(TM) 64-Bit Server VM (fastdebug build > 9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode) > > > #section:compile > ----------messages:(4/233)---------- > command: compile > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > reason: User specified action: run compile > GetModuleByPkgTest1.java > Mode: othervm > elapsed time (seconds): 1.7 > ----------configuration:(4/227)---------- > javac compilation environment > class path: > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > > /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > > > ----------rerun:(21/1677)*---------- > DISPLAY=localhost:11.0 \\ > HOME=/home/sspitsyn \\ > JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ > LANG=en_US.UTF-8 \\ > PATH=/bin:/usr/bin \\ > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/javac > \\ > -J'-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -J-Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed -server' \\ > -J-Dtest.compiler.opts= \\ > -J-Dtest.java.opts= \\ > -J-Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -J-Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -J-Dtest.timeout.factor=1.0 \\ > -d > /var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -sourcepath > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -classpath > /var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java > ----------System.out:(0/0)---------- > ----------System.err:(0/0)---------- > result: Passed. Compilation successful > > #section:build > ----------messages:(3/104)---------- > command: build GetModuleByPkgTest1 > reason: Named class compiled on demand > elapsed time (seconds): 0.002 > result: Passed. All files up to date > > #section:main > ----------messages:(4/228)---------- > command: main -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 > reason: User specified action: run main/othervm > -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1 > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.017 > ----------configuration:(0/0)---------- > ----------System.out:(2/210)---------- > Error occurred during initialization of VM > Could not find agent library GetModuleByPkgTest1 on the > library path, with error: libGetModuleByPkgTest1.so: cannot > open shared object file: No such file or directory > ----------System.err:(0/0)---------- > ----------rerun:(21/1756)*---------- > DISPLAY=localhost:11.0 \\ > HOME=/home/sspitsyn \\ > JTREG_HOME=/java/re/jtreg/4.2/promoted/latest/binaries/jtreg \\ > LANG=en_US.UTF-8 \\ > PATH=/bin:/usr/bin \\ > CLASSPATH=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/javatest.jar:/net/scanas416.us.oracle.com/export/java_re2/misc/promoted/jtreg/4.2/fcs/b02/binaries/jtreg/lib/jtreg.jar > \\ > /var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > \\ > -Dtest.src=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.src.path=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.classes=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.class.path=/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName > \\ > -Dtest.vm.opts='-Dtest.java.opts=-Xmixed -server' \\ > -Dtest.tool.vm.opts='-J-Dtest.java.opts=-Xmixed > -server' \\ > -Dtest.compiler.opts= \\ > -Dtest.java.opts= \\ > -Dtest.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -Dcompile.jdk=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk > \\ > -Dtest.timeout.factor=1.0 \\ > '-Dtest.java.opts=-Xmixed -server' \\ > -agentlib:GetModuleByPkgTest1 \\ > com.sun.javatest.regtest.agent.MainWrapper > /var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.d/main.0.jta > result: Failed. Unexpected exit from test [exit code: 1] > > > test result: Failed. Unexpected exit from test [exit code: 1] > > Thanks, > Serguei > > > On 6/19/16 00:09, serguei.spitsyn at oracle.com > wrote: > > Hi Christian, > > Thank you for the reply! > Serguei > > > On 6/18/16 17:33, Christian Tornqvist wrote: > > Hi Serguei, > > We?re currently using jtreg 4.2 b02, so you should be > able to do this. > > Thanks, > > Christian > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] > *On Behalf Of *serguei.spitsyn at oracle.com > > *Sent:* Friday, June 17, 2016 7:39 PM > *To:* Alexander Kulyakhtin > > > *Cc:* serviceability-dev at openjdk.java.net > > *Subject:* Re: RFR:8153978:New test to verify the > modules info as returned by the JVMTI > > Hi Alexander, > > I'm curious if the jtreg 4.2 is out and this test can > be pushed now? > I'd want to use the same pattern to write the Jigsaw > related JVMTI tests. > > Thanks, > Serguei > > > On 5/5/16 04:25, Alexander Kulyakhtin wrote: > > 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 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 serguei.spitsyn at oracle.com Tue Jun 21 14:58:48 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 07:58:48 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <57695628.4000200@oracle.com> Hi Christian, Thank you for looking at it! On 6/21/16 04:56, Christian Tornqvist wrote: > > Hi Serguei, > > I?ve only looked at the test code so far, here are some comments: > > * You?re not allowed to call System.exit in a jtreg test. If something > fails, you need to throw an exception. > Ok, an exception is Ok with me. > * Instead of a run() method you could simply collapse all this into > the main method like this: > > assertEQ(check(), 0); > Will check if this works for me. > * Would it make sense to throw exceptions with useful error messages > from the JNI code instead of returning failed status codes? Our error > matching system would work a lot better with unique error messages. > Will check if this works well in this case. The unique error messages are already printed in the native code. Thanks, Serguei > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 6:49 AM > *To:* Alan Bateman ; > serviceability-dev at openjdk.java.net; Christian T?rnqvist > ; Alexander Kulyakhtin > ; hotspot-dev at openjdk.java.net > Developers > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > On 6/21/16 03:23, Alan Bateman wrote: > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com > wrote: > > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Serguei - can you put the patches on cr.openjdk.java.net? > > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the jtreg > format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > > Thanks, > Serguei > > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 21 14:59:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 07:59:58 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <5769566E.6080609@oracle.com> Hi Alan, Thank you for the review! I'll implement all your suggestions. Thanks, Serguei On 6/21/16 04:56, Alan Bateman wrote: > > > On 21/06/2016 11:48, serguei.spitsyn at oracle.com wrote: >> >> Sorry. >> My initial plan was to write an nsk.jvmti test and review it on a >> confidential mailing list. >> It is why I put the webrevs on the non-public server. >> Forgot to switch the server when the test was converted into the >> jtreg format. >> >> The public webrevs are: >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> >> Jdk: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> > > The spec generally looks good, just two small points: > > 1. "java.lang.ClassLoader" would be better than > "java/lang/ClassLoader" when describing the class_loader parameter. > > 2. For the package name then it might be clearer to say that the > package name is in internal form and then include the example of > "java/lang" in parenthesis. > > One comment on the test is that it looks like check_system_loader > doesn't test any packages that are defined to a module. > check_bootstrap_loader does have tests for named modules for the null > loader case. Just wondering if we need more here. > > You might have spotted this already but the header comment on the > tests needs to be the GPL header. > > -Alan From vladimir.kozlov at oracle.com Tue Jun 21 16:36:07 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 09:36:07 -0700 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <3c84643c-c10a-7eaa-d28e-83fa0ee037de@oracle.com> 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> <3c84643c-c10a-7eaa-d28e-83fa0ee037de@oracle.com> Message-ID: <4165eb28-635d-71a1-f220-32647c1a6ed5@oracle.com> This RFE is approved for push. Thanks, Vladimir On 5/24/16 9:46 AM, Kevin Walls wrote: > > ...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 christian.tornqvist at oracle.com Tue Jun 21 17:06:17 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 21 Jun 2016 13:06:17 -0400 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57695628.4000200@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <57695628.4000200@oracle.com> Message-ID: Hi Serguei, >Will check if this works well in this case. >The unique error messages are already printed in the native code. Yes, they?re printed on stdout/stderr but the test will fail with a ?Test failed? exception and our failure matching system wouldn?t be able to tell why it failed. It?d be a lot nicer if it?d just throw an exception when one of the checks in the native code failed. Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 10:59 AM To: Christian Tornqvist ; 'Alan Bateman' ; serviceability-dev at openjdk.java.net; 'Alexander Kulyakhtin' ; hotspot-dev at openjdk.java.net Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName Hi Christian, Thank you for looking at it! On 6/21/16 04:56, Christian Tornqvist wrote: Hi Serguei, I?ve only looked at the test code so far, here are some comments: * You?re not allowed to call System.exit in a jtreg test. If something fails, you need to throw an exception. Ok, an exception is Ok with me. * Instead of a run() method you could simply collapse all this into the main method like this: assertEQ(check(), 0); Will check if this works for me. * Would it make sense to throw exceptions with useful error messages from the JNI code instead of returning failed status codes? Our error matching system would work a lot better with unique error messages. Will check if this works well in this case. The unique error messages are already printed in the native code. Thanks, Serguei Thanks, Christian From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Tuesday, June 21, 2016 6:49 AM To: Alan Bateman ; serviceability-dev at openjdk.java.net ; Christian T?rnqvist ; Alexander Kulyakhtin ; hotspot-dev at openjdk.java.net Developers Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName On 6/21/16 03:23, Alan Bateman wrote: On 21/06/2016 10:54, serguei.spitsyn at oracle.com wrote: Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ The Jdk webrev: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Serguei - can you put the patches on cr.openjdk.java.net? Sorry. My initial plan was to write an nsk.jvmti test and review it on a confidential mailing list. It is why I put the webrevs on the non-public server. Forgot to switch the server when the test was converted into the jtreg format. The public webrevs are: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ Jdk: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Tue Jun 21 17:26:31 2016 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 21 Jun 2016 18:26:31 +0100 Subject: RFR[9u-dev]: 8150900: Implement diagnostic_pd In-Reply-To: <4165eb28-635d-71a1-f220-32647c1a6ed5@oracle.com> 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> <3c84643c-c10a-7eaa-d28e-83fa0ee037de@oracle.com> <4165eb28-635d-71a1-f220-32647c1a6ed5@oracle.com> Message-ID: Hi Vladimir - that's great, thanks for letting us know. I'll get it pushed. Kevin On 21/06/2016 17:36, Vladimir Kozlov wrote: > This RFE is approved for push. > > Thanks, > Vladimir > > On 5/24/16 9:46 AM, Kevin Walls wrote: >> >> ...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 adinn at redhat.com Tue Jun 21 10:19:42 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 11:19:42 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <576914BE.1030309@redhat.com> On 21/06/16 10:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ I don't seem to be able to access those webrevs: Server not found Firefox can't find the server at javaweb.sfbay.sun.com. . . . regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From yasuenag at gmail.com Tue Jun 21 23:37:20 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 22 Jun 2016 08:37:20 +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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: PING: Could you review it? BTW, should I add jdk9-fc-request label to JBS? Thanks, Yasumasa 2016/06/13 13:24 "David Holmes" : > Hi Yasumasa, > > On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: > >> Hi David, >> >> Thank you for your comment. >> >> So options are a distinct property of outputs and so should have been >>> a first class entity in LogOutput all along. >>> >> >> I agree to you. >> But I think we need to discuss about it with logging folks. >> >> I uploaded a new webrev. It removes fixed buffer length and changes the >> order of output. >> Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >> > > It's okay to wait and hear what opinions others may have before changing > things based on my comments. :) The fixed buffer may be okay - as I said I > don't know what the potential options are, so don't know if it is okay or > not. > > Using dynamic allocation avoids that but raises other concerns - like > calling vm_exit_on_out_of_memory on failure; or whether to use malloc or > resource area? > > Lets wait for other feedback before going further. > > Thanks, > David > > >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 9:05, David Holmes wrote: >> >>> Hi Yasumasa, >>> >>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>> >>>> Hi David, >>>> >>>> I think "config_string" is different from "option_string". >>>> >>>> -Xlog format (from -Xlog:help message): >>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>> >>>> config_string: "what" (ex. gc=trace) >>>> option_string: "output-options" (ex. filecount=5) >>>> >>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>> It does not contain output options. >>>> >>> >>> Okay I'm starting to see the bigger picture here. In terms of the >>> overall logging configuration we might have, for example: >>> >>> gc=trace -> stdout >>> runtime=info -> fileA >>> compiler=trace -> fileB >>> >>> where the LHS is (part of) the configuration, and the RHS is the >>> output. So for each output we set its "configuration" to the >>> associated LHS. >>> >>> So options are a distinct property of outputs and so should have been >>> a first class entity in LogOutput all along. >>> >>> Okay so looking at your v4 I have two comments: >>> >>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>> are so don't know if 100 is adequate. >>> >>> Second, if the logging syntax is: >>> >>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>> >>> then shouldn't the configuration be printed in the same order/format? >>> >>> Thanks, >>> David >>> >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/13 8:14, David Holmes wrote: >>>> >>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> Thank you for your comment. >>>>>> >>>>>> Is there some reason the option string could not simply become >>>>>>> part of >>>>>>> the existing configuration string? >>>>>>> >>>>>> >>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>> (See webrev.01). >>>>>> Marcus commented that option string should be generated from current >>>>>> configuration. >>>>>> >>>>>> I uploaded new webrev. >>>>>> Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>> >>>>> >>>>> Sorry but I repeat my question - why is the option information not >>>>> simply part of the config_string? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>> actually needs to implement. >>>>>>> >>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>> - we >>>>>>> have getters for all the other "properties" which are then printed by >>>>>>> the describe_current_configuration method. But this is instead a >>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>> two styles seems messy. It probably would have been better to have >>>>>>> had >>>>>>> a print-style API from the start - then adding the options would have >>>>>>> been a trivial extension for those output classes with options. >>>>>>> >>>>>>> In addition the change you made to describe_current_configuration is >>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>> the config string and the decorators) for this one class and so you >>>>>>> added the code to support that format. But that format may not make >>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>> >>>>>>> Is there some reason the option string could not simply become >>>>>>> part of >>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>> these "options" really are part of the configuration. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>> "2015, 2016,". >>>>>>> >>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>>> PING: Could you review it? >>>>>>>> We need a second reviewer. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>> FileLogOutput configuration. >>>>>>>> So I want to merge it to jdk 9. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Tue Jun 21 23:40:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 22 Jun 2016 08:40:36 +0900 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: References: Message-ID: Hi all, Can I add jdk9-fc-request label to JBS? This changes has not been reviewed yet. Thanks, Yasumasa 2016/03/22 21:24 "Yasumasa Suenaga" : > 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 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jun 22 00:45:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 10:45:52 +1000 Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: References: Message-ID: On 22/06/2016 9:40 AM, Yasumasa Suenaga wrote: > Hi all, > > Can I add jdk9-fc-request label to JBS? Bug fixes do not need approval only enhancements. David ----- > This changes has not been reviewed yet. > > Thanks, > > Yasumasa > > 2016/03/22 21:24 "Yasumasa Suenaga" >: > > 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 Jun 22 00:48:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 10:48:15 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: On 22/06/2016 9:37 AM, Yasumasa Suenaga wrote: > PING: Could you review it? > BTW, should I add jdk9-fc-request label to JBS? Yes this enhancement will need approval. Please add the label and other information as outlined here: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html Thanks, David > Thanks, > > Yasumasa > > 2016/06/13 13:24 "David Holmes" >: > > Hi Yasumasa, > > On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: > > Hi David, > > Thank you for your comment. > > So options are a distinct property of outputs and so should > have been > a first class entity in LogOutput all along. > > > I agree to you. > But I think we need to discuss about it with logging folks. > > I uploaded a new webrev. It removes fixed buffer length and > changes the > order of output. > Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ > > > It's okay to wait and hear what opinions others may have before > changing things based on my comments. :) The fixed buffer may be > okay - as I said I don't know what the potential options are, so > don't know if it is okay or not. > > Using dynamic allocation avoids that but raises other concerns - > like calling vm_exit_on_out_of_memory on failure; or whether to use > malloc or resource area? > > Lets wait for other feedback before going further. > > Thanks, > David > > > Thanks, > > Yasumasa > > > On 2016/06/13 9:05, David Holmes wrote: > > Hi Yasumasa, > > On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: > > Hi David, > > I think "config_string" is different from "option_string". > > -Xlog format (from -Xlog:help message): > -Xlog[:[what][:[output][:[decorators][:output-options]]]] > > config_string: "what" (ex. gc=trace) > option_string: "output-options" (ex. filecount=5) > > Currently, LogOutput handles tags and loglevels only as > config_string. > It does not contain output options. > > > Okay I'm starting to see the bigger picture here. In terms > of the > overall logging configuration we might have, for example: > > gc=trace -> stdout > runtime=info -> fileA > compiler=trace -> fileB > > where the LHS is (part of) the configuration, and the RHS is the > output. So for each output we set its "configuration" to the > associated LHS. > > So options are a distinct property of outputs and so should > have been > a first class entity in LogOutput all along. > > Okay so looking at your v4 I have two comments: > > First, hard-wiring OPTIONS_LEN. I don't know what the > possible options > are so don't know if 100 is adequate. > > Second, if the logging syntax is: > > -Xlog[:[what][:[output][:[decorators][:output-options]]]] > > then shouldn't the configuration be printed in the same > order/format? > > Thanks, > David > > > Thanks, > > Yasumasa > > > On 2016/06/13 8:14, David Holmes wrote: > > On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: > > Hi David, > > Thank you for your comment. > > Is there some reason the option string could > not simply become > part of > the existing configuration string? > > > My first proposal keeps option string at > LogOutput and its child class > (See webrev.01). > Marcus commented that option string should be > generated from current > configuration. > > I uploaded new webrev. > Could you review again? > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ > > > Sorry but I repeat my question - why is the option > information not > simply part of the config_string? > > Thanks, > David > > > Thanks, > > Yasumasa > > > On 2016/06/12 6:44, David Holmes wrote: > > Hi Yasumasa, > > Sorry but this API seems poorly fitting to > me. First > print_option_string seems the wrong name > given that the base class, > LogOutput, has no notion of having an > "option string". It seems to be > a supposedly generic "print other stuff" > function that only one class > actually needs to implement. > > Secondly it inverts the style of the API > used for everything else > - we > have getters for all the other "properties" > which are then printed by > the describe_current_configuration method. > But this is instead a > "print" function where we ask the target to > print itself. Mixing the > two styles seems messy. It probably would > have been better to have > had > a print-style API from the start - then > adding the options would have > been a trivial extension for those output > classes with options. > > In addition the change you made to > describe_current_configuration is > not at all general purpose - you wanted a > given format (print between > the config string and the decorators) for > this one class and so you > added the code to support that format. But > that format may not make > sense for other classes that might have > "extra stuff" to print. > > Is there some reason the option string could > not simply become > part of > the existing configuration string? It seems > to me that for a LogFile > these "options" really are part of the > configuration. > > Thanks, > David > > PS. The two hpp files would need their > copyright years updated to > "2015, 2016,". > > On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: > > PING: Could you review it? > We need a second reviewer. > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ > > > This change is small fix, and it helps > us to confirm current > FileLogOutput configuration. > So I want to merge it to jdk 9. > > > Thanks, > > Yasumasa > > > On 2016/05/17 19:17, Yasumasa Suenaga wrote: > > 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 david.holmes at oracle.com Wed Jun 22 00:59:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 10:59:03 +1000 Subject: RFR: 8159959: Quarantine the test java/lang/management/MemoryMXBean/Pending.java In-Reply-To: <6f4e4d19-35bc-4eb1-b3a6-28daa76a57ae@default> References: <6f4e4d19-35bc-4eb1-b3a6-28daa76a57ae@default> Message-ID: <36adf587-c99a-a0e0-c735-a273a905b55b@oracle.com> Looks good. Thanks, David On 21/06/2016 8:59 PM, Alexander Kulyakhtin wrote: > Hi, > > Could I, please, have a review of this trivial change (quarantining 1 test): > > CR: https://bugs.openjdk.java.net/browse/JDK-8159959 "Quarantine java/lang/management/MemoryMXBean/Pending.java" > Webrev: http://cr.openjdk.java.net/~akulyakh/8159959/test/ProblemList.txt.udiff.html > > Best regards, > Alexander > From david.holmes at oracle.com Wed Jun 22 03:52:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jun 2016 13:52:34 +1000 Subject: RFR: 8159959: Quarantine the test java/lang/management/MemoryMXBean/Pending.java In-Reply-To: <36adf587-c99a-a0e0-c735-a273a905b55b@oracle.com> References: <6f4e4d19-35bc-4eb1-b3a6-28daa76a57ae@default> <36adf587-c99a-a0e0-c735-a273a905b55b@oracle.com> Message-ID: <6e4415de-c91b-c8ea-5821-04d80c7959ed@oracle.com> Alexander, This should also be used to quarantine java/lang/management/MemoryMXBean/PendingAllGC.sh See - https://bugs.openjdk.java.net/browse/JDK-8158760 David On 22/06/2016 10:59 AM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 21/06/2016 8:59 PM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could I, please, have a review of this trivial change (quarantining 1 >> test): >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8159959 "Quarantine >> java/lang/management/MemoryMXBean/Pending.java" >> Webrev: >> http://cr.openjdk.java.net/~akulyakh/8159959/test/ProblemList.txt.udiff.html >> >> >> Best regards, >> Alexander >> From yasuenag at gmail.com Wed Jun 22 03:53:35 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 22 Jun 2016 12:53:35 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: 2016/06/22 9:48 "David Holmes" : > > On 22/06/2016 9:37 AM, Yasumasa Suenaga wrote: >> >> PING: Could you review it? >> BTW, should I add jdk9-fc-request label to JBS? > > > Yes this enhancement will need approval. Please add the label and other information as outlined here: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html Thanks! I added. Yasumasa > Thanks, > David > > > >> Thanks, >> >> Yasumasa >> >> 2016/06/13 13:24 "David Holmes" > >: >> >> >> Hi Yasumasa, >> >> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> Thank you for your comment. >> >> So options are a distinct property of outputs and so should >> have been >> a first class entity in LogOutput all along. >> >> >> I agree to you. >> But I think we need to discuss about it with logging folks. >> >> I uploaded a new webrev. It removes fixed buffer length and >> changes the >> order of output. >> Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >> >> >> It's okay to wait and hear what opinions others may have before >> changing things based on my comments. :) The fixed buffer may be >> okay - as I said I don't know what the potential options are, so >> don't know if it is okay or not. >> >> Using dynamic allocation avoids that but raises other concerns - >> like calling vm_exit_on_out_of_memory on failure; or whether to use >> malloc or resource area? >> >> Lets wait for other feedback before going further. >> >> Thanks, >> David >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 9:05, David Holmes wrote: >> >> Hi Yasumasa, >> >> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> I think "config_string" is different from "option_string". >> >> -Xlog format (from -Xlog:help message): >> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >> >> config_string: "what" (ex. gc=trace) >> option_string: "output-options" (ex. filecount=5) >> >> Currently, LogOutput handles tags and loglevels only as >> config_string. >> It does not contain output options. >> >> >> Okay I'm starting to see the bigger picture here. In terms >> of the >> overall logging configuration we might have, for example: >> >> gc=trace -> stdout >> runtime=info -> fileA >> compiler=trace -> fileB >> >> where the LHS is (part of) the configuration, and the RHS is the >> output. So for each output we set its "configuration" to the >> associated LHS. >> >> So options are a distinct property of outputs and so should >> have been >> a first class entity in LogOutput all along. >> >> Okay so looking at your v4 I have two comments: >> >> First, hard-wiring OPTIONS_LEN. I don't know what the >> possible options >> are so don't know if 100 is adequate. >> >> Second, if the logging syntax is: >> >> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >> >> then shouldn't the configuration be printed in the same >> order/format? >> >> Thanks, >> David >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 8:14, David Holmes wrote: >> >> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> Thank you for your comment. >> >> Is there some reason the option string could >> not simply become >> part of >> the existing configuration string? >> >> >> My first proposal keeps option string at >> LogOutput and its child class >> (See webrev.01). >> Marcus commented that option string should be >> generated from current >> configuration. >> >> I uploaded new webrev. >> Could you review again? >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >> >> >> Sorry but I repeat my question - why is the option >> information not >> simply part of the config_string? >> >> Thanks, >> David >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/12 6:44, David Holmes wrote: >> >> Hi Yasumasa, >> >> Sorry but this API seems poorly fitting to >> me. First >> print_option_string seems the wrong name >> given that the base class, >> LogOutput, has no notion of having an >> "option string". It seems to be >> a supposedly generic "print other stuff" >> function that only one class >> actually needs to implement. >> >> Secondly it inverts the style of the API >> used for everything else >> - we >> have getters for all the other "properties" >> which are then printed by >> the describe_current_configuration method. >> But this is instead a >> "print" function where we ask the target to >> print itself. Mixing the >> two styles seems messy. It probably would >> have been better to have >> had >> a print-style API from the start - then >> adding the options would have >> been a trivial extension for those output >> classes with options. >> >> In addition the change you made to >> describe_current_configuration is >> not at all general purpose - you wanted a >> given format (print between >> the config string and the decorators) for >> this one class and so you >> added the code to support that format. But >> that format may not make >> sense for other classes that might have >> "extra stuff" to print. >> >> Is there some reason the option string could >> not simply become >> part of >> the existing configuration string? It seems >> to me that for a LogFile >> these "options" really are part of the >> configuration. >> >> Thanks, >> David >> >> PS. The two hpp files would need their >> copyright years updated to >> "2015, 2016,". >> >> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >> >> PING: Could you review it? >> We need a second reviewer. >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >> >> >> This change is small fix, and it helps >> us to confirm current >> FileLogOutput configuration. >> So I want to merge it to jdk 9. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >> >> 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 >> >> >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 22 06:39:57 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Jun 2016 23:39:57 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <57695628.4000200@oracle.com> Message-ID: <576A32BD.4040709@oracle.com> Hi Christian, I understand that. Will do my best to achieve this. There are some corner cases however. Thanks, Serguei On 6/21/16 10:06, Christian Tornqvist wrote: > > Hi Serguei, > > >Will check if this works well in this case. > > >The unique error messages are already printed in the native code. > > Yes, they?re printed on stdout/stderr but the test will fail with a > ?Test failed? exception and our failure matching system wouldn?t be > able to tell why it failed. It?d be a lot nicer if it?d just throw an > exception when one of the checks in the native code failed. > > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 10:59 AM > *To:* Christian Tornqvist ; 'Alan > Bateman' ; > serviceability-dev at openjdk.java.net; 'Alexander Kulyakhtin' > ; hotspot-dev at openjdk.java.net > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > Hi Christian, > > Thank you for looking at it! > > > On 6/21/16 04:56, Christian Tornqvist wrote: > > Hi Serguei, > > I?ve only looked at the test code so far, here are some comments: > > * You?re not allowed to call System.exit in a jtreg test. If > something fails, you need to throw an exception. > > > Ok, an exception is Ok with me. > > > * Instead of a run() method you could simply collapse all this > into the main method like this: > > assertEQ(check(), 0); > > > Will check if this works for me. > > > > > > * Would it make sense to throw exceptions with useful error > messages from the JNI code instead of returning failed status > codes? Our error matching system would work a lot better with > unique error messages. > > > Will check if this works well in this case. > The unique error messages are already printed in the native code. > > Thanks, > Serguei > > > Thanks, > > Christian > > *From:*serguei.spitsyn at oracle.com > > [mailto:serguei.spitsyn at oracle.com] > *Sent:* Tuesday, June 21, 2016 6:49 AM > *To:* Alan Bateman > ; > serviceability-dev at openjdk.java.net > ; Christian T?rnqvist > > ; Alexander Kulyakhtin > > ; > hotspot-dev at openjdk.java.net > Developers > > *Subject:* Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function > GetModuleByPackageName > > On 6/21/16 03:23, Alan Bateman wrote: > > On 21/06/2016 10:54, serguei.spitsyn at oracle.com > wrote: > > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Serguei - can you put the patches on cr.openjdk.java.net? > > > Sorry. > My initial plan was to write an nsk.jvmti test and review it on a > confidential mailing list. > It is why I put the webrevs on the non-public server. > Forgot to switch the server when the test was converted into the > jtreg format. > > The public webrevs are: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > > Jdk: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > > Thanks, > Serguei > > > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 22 08:44:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 09:44:03 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57691B87.20104@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> Message-ID: <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> Serguei, One other question - are you going to drop the (temporary) JVM_* function and update the JPLISAgent as part of this or are you leaving that to a follow-on issue? -Alan From serguei.spitsyn at oracle.com Wed Jun 22 09:00:29 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 02:00:29 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> Message-ID: <576A53AD.2090209@oracle.com> Alan, Now I prefer to separate both changes. My plan was to separate dropping the JVM_* function as we discussed previously. The JPLISAgent can be updated as a part of adding back the transform method class loader argument as the change is pretty trivial. But I can make this change as a part of this fix if you think it is more appropriate. Thanks, Serguei On 6/22/16 01:44, Alan Bateman wrote: > Serguei, > > One other question - are you going to drop the (temporary) JVM_* > function and update the JPLISAgent as part of this or are you leaving > that to a follow-on issue? > > -Alan From Alan.Bateman at oracle.com Wed Jun 22 09:02:11 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 10:02:11 +0100 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A53AD.2090209@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> <576A53AD.2090209@oracle.com> Message-ID: <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> On 22/06/2016 10:00, serguei.spitsyn at oracle.com wrote: > Alan, > > Now I prefer to separate both changes. > My plan was to separate dropping the JVM_* function as we discussed > previously. > The JPLISAgent can be updated as a part of adding back the transform > method > class loader argument as the change is pretty trivial. > But I can make this change as a part of this fix if you think it is > more appropriate. > Two steps is okay with me, I just want to make sure that this part is covered. -Alan From serguei.spitsyn at oracle.com Wed Jun 22 09:09:23 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 02:09:23 -0700 Subject: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> References: <57690EBB.2010007@oracle.com> <62ff9266-09ab-26bc-2fc5-5ca6fb50cb45@oracle.com> <57691B87.20104@oracle.com> <89068a44-f213-e75b-1984-90e649ef58bf@oracle.com> <576A53AD.2090209@oracle.com> <92df23e5-2256-01f9-3585-9f5ed364706c@oracle.com> Message-ID: <576A55C3.4060305@oracle.com> On 6/22/16 02:02, Alan Bateman wrote: > > > On 22/06/2016 10:00, serguei.spitsyn at oracle.com wrote: >> Alan, >> >> Now I prefer to separate both changes. >> My plan was to separate dropping the JVM_* function as we discussed >> previously. >> The JPLISAgent can be updated as a part of adding back the transform >> method >> class loader argument as the change is pretty trivial. >> But I can make this change as a part of this fix if you think it is >> more appropriate. >> > Two steps is okay with me, I just want to make sure that this part is > covered. Yes, I keep it in mind. Thanks! Serguei > > -Alan From serguei.spitsyn at oracle.com Wed Jun 22 11:07:53 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 04:07:53 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <57690EBB.2010007@oracle.com> References: <57690EBB.2010007@oracle.com> Message-ID: <576A7189.6040809@oracle.com> Here are new hotspot webrev where I've fixed the comments from Alan and Christian. Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 The Jdk webrev is the same: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Thanks, Serguei On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ > > The Jdk webrev: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Summary: > > JVM TI agents that instrument code in named modules need the Module at > class load time. > > One way to do this is by introducing a new ClassFileLoadHook that > takes an additional parameter but this approach is disruptive. > The alternative option is a JVM TI function that maps a classloader > + package name to a module. > We were initially not confident with this approach so we introduced > it as JVM function JVM_GetModuleByPackageName. > Based on experience to date then this approach seems okay and so > this function needs to be promoted to a JVMTI function. > > This fix is to introduce new JVMTI function GetModuleByPackageName. > It includes new jtreg test with native JVMTI agent. > > A CCC is fast-tracked and getting an approval is in progress. > > Testing: > Run newly developed jtreg test. > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jun 22 13:05:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 06:05:17 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A7189.6040809@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> Message-ID: <576A8D0D.3090907@oracle.com> I've updated the libGetModuleByPkgTest.c in place in the webrev #2 with minor improvements. Sorry, if it spoiled your work. Thanks, Serguei On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: > Here are new hotspot webrev where I've fixed the comments from Alan > and Christian. > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > > > The Jdk webrev is the same: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Thanks, > Serguei > > > On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Summary: >> >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> This fix is to introduce new JVMTI function GetModuleByPackageName. >> It includes new jtreg test with native JVMTI agent. >> >> A CCC is fast-tracked and getting an approval is in progress. >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Wed Jun 22 17:29:09 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 10:29:09 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A7189.6040809@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> Message-ID: <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> Hi Serguei, The comment in the following assert is outdated. There is no get_module_from_pkg. Should it be changed to get_module_by_package_name()? 804 assert(ModuleEntryTable::javabase_defined(), 805 "Attempt to call get_module_from_pkg before java.base is defined"); It?s not part of your change, I just happen to notice it. In the same get_module_by_package_name(), both the ?if? and ?else? cases have return statement. The ?return NULL? at line 825 seems will never reached and not needed. Thanks, Jiangli > On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: > > Here are new hotspot webrev where I've fixed the comments from Alan and Christian. > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > > > The Jdk webrev is the same: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > > Thanks, > Serguei > > > On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >> >> The Jdk webrev: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Summary: >> >> JVM TI agents that instrument code in named modules need the Module at class load time. >> >> One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader + package name to a module. >> We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. >> >> This fix is to introduce new JVMTI function GetModuleByPackageName. >> It includes new jtreg test with native JVMTI agent. >> >> A CCC is fast-tracked and getting an approval is in progress. >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 22 17:45:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 18:45:36 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> On 22/06/2016 18:09, stanislav lukyanov wrote: > Hi Serguei, > > What is the expected behavior when passed string is not a valid > package name (e.g. contains illegal characters)? > I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that > case. > > Now it looks like the method will return unnamed module not only for > an empty string > but for any string that is not a known package name. > If it's correct, I think the empty string case shouldn't be described > explicitly. The empty string is the unnamed module case and so the function should always return the unamed module. You question on whether this function checks for invalid identifiers is a good question as that is currently not specified. -Alan From serguei.spitsyn at oracle.com Wed Jun 22 18:11:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:11:31 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> Message-ID: <576AD4D3.9030002@oracle.com> On 6/22/16 10:45, Alan Bateman wrote: > > > On 22/06/2016 18:09, stanislav lukyanov wrote: >> Hi Serguei, >> >> What is the expected behavior when passed string is not a valid >> package name (e.g. contains illegal characters)? >> I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in >> that case. >> >> Now it looks like the method will return unnamed module not only for >> an empty string >> but for any string that is not a known package name. >> If it's correct, I think the empty string case shouldn't be described >> explicitly. > The empty string is the unnamed module case and so the function should > always return the unamed module. > > You question on whether this function checks for invalid identifiers > is a good question as that is currently not specified. I'd suggest to specify this function does not check for invalid characters (or identifiers). Please, let me know if you have objections. Thanks, Serguei > > -Alan From serguei.spitsyn at oracle.com Wed Jun 22 18:26:02 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:26:02 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: <576AD83A.5070402@oracle.com> Hi Stanislav, Thank you for looking at this update and the comments! On 6/22/16 10:09, stanislav lukyanov wrote: > Hi Serguei, > > What is the expected behavior when passed string is not a valid > package name (e.g. contains illegal characters)? > I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that > case. I initially was thinking the same but currently have a doubt it is really needed. Let's find out if we can reach a consensus here. > > Now it looks like the method will return unnamed module not only for > an empty string > but for any string that is not a known package name. Yes, this is correct. We are not able to recognize non-existing package names and always return the unnamed package. I'm still not sure we want to explicitly specify it. > If it's correct, I think the empty string case shouldn't be described > explicitly. I agree, it can confuse the users. I still prefer to explicitly specify it. The question is if we want to explicitly specify that we always return the unnamed package for non-existing packages. Thanks, Serguei > > Thanks, > Stas > > On 22.06.2016 16:05, serguei.spitsyn at oracle.com wrote: >> I've updated the libGetModuleByPkgTest.c in place in the webrev #2 >> with minor improvements. >> Sorry, if it spoiled your work. >> >> Thanks, >> Serguei >> >> >> On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: >>> Here are new hotspot webrev where I've fixed the comments from Alan >>> and Christian. >>> >>> Hotspot: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>> >>> >>> >>> The Jdk webrev is the same: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>> >>>> >>>> The Jdk webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> JVM TI agents that instrument code in named modules need the Module >>>> at class load time. >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that >>>> takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a >>>> classloader + package name to a module. >>>> We were initially not confident with this approach so we >>>> introduced it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so >>>> this function needs to be promoted to a JVMTI function. >>>> >>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> A CCC is fast-tracked and getting an approval is in progress. >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> >> > From serguei.spitsyn at oracle.com Wed Jun 22 18:36:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 11:36:24 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576AD4D3.9030002@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> Message-ID: <576ADAA8.8000902@oracle.com> On 6/22/16 11:11, serguei.spitsyn at oracle.com wrote: > On 6/22/16 10:45, Alan Bateman wrote: >> >> >> On 22/06/2016 18:09, stanislav lukyanov wrote: >>> Hi Serguei, >>> >>> What is the expected behavior when passed string is not a valid >>> package name (e.g. contains illegal characters)? >>> I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in >>> that case. >>> >>> Now it looks like the method will return unnamed module not only for >>> an empty string >>> but for any string that is not a known package name. >>> If it's correct, I think the empty string case shouldn't be >>> described explicitly. >> The empty string is the unnamed module case and so the function >> should always return the unamed module. >> >> You question on whether this function checks for invalid identifiers >> is a good question as that is currently not specified. > > I'd suggest to specify this function does not check for invalid > characters (or identifiers). > Please, let me know if you have objections. Alan, please, let me know if you support the Stanislav's suggestion. I can go ahead and implement returning the JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. Thanks, Serguei > > Thanks, > Serguei > > >> >> -Alan > From Alan.Bateman at oracle.com Wed Jun 22 19:01:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jun 2016 20:01:42 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576ADAA8.8000902@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> Message-ID: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > > Alan, please, let me know if you support the Stanislav's suggestion. > I can go ahead and implement returning the > JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. No objection from me. It would be good to first check the existing spec and also the JNI spec to see if there any similar cases (so that the update and new function is consistent). Off-hand, I can't think of any functions that require the same check. -Alan From serguei.spitsyn at oracle.com Wed Jun 22 19:07:45 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 12:07:45 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: <576AE201.5030702@oracle.com> On 6/22/16 12:01, Alan Bateman wrote: > On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > >> >> Alan, please, let me know if you support the Stanislav's suggestion. >> I can go ahead and implement returning the >> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. > No objection from me. Ok, thanks! > It would be good to first check the existing spec and also the JNI > spec to see if there any similar cases (so that the update and new > function is consistent). Will do. > Off-hand, I can't think of any functions that require the same check. Agreed. Thanks, Serguei > > -Alan From serguei.spitsyn at oracle.com Wed Jun 22 20:17:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 13:17:05 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> Message-ID: <576AF241.7080908@oracle.com> Hi Jiangli, Fixed both places - nice catch! Would you like I list you as a reviewer? Thanks, Serguei On 6/22/16 10:29, Jiangli Zhou wrote: > Hi Serguei, > > The comment in the following assert is outdated. There is no > get_module_from_pkg. Should it be changed to get_module_by_package_name()? > > 804 assert(ModuleEntryTable::javabase_defined(), > 805 "Attempt to call get_module_from_pkg before java.base is defined"); > > It?s not part of your change, I just happen to notice it. In the same > get_module_by_package_name(), both the ?if? and ?else? cases have > return statement. The ?return NULL? at line 825 seems will never > reached and not needed. > > Thanks, > Jiangli > >> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com >> wrote: >> >> Here are new hotspot webrev where I've fixed the comments from Alan >> and Christian. >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >> >> >> >> The Jdk webrev is the same: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> Thanks, >> Serguei >> >> >> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>> >>> The Jdk webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> Summary: >>> >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a classloader >>> + package name to a module. >>> We were initially not confident with this approach so we introduced >>> it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>> It includes new jtreg test with native JVMTI agent. >>> >>> A CCC is fast-tracked and getting an approval is in progress. >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Wed Jun 22 20:54:41 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 22 Jun 2016 13:54:41 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576AF241.7080908@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> <576AF241.7080908@oracle.com> Message-ID: Hi Serguei, > On Jun 22, 2016, at 1:17 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jiangli, > > Fixed both places - nice catch! > Would you like I list you as a reviewer? No worry, if you already committed/pushed your changes. Thanks, Jiangli > > Thanks, > Serguei > > > On 6/22/16 10:29, Jiangli Zhou wrote: >> Hi Serguei, >> >> The comment in the following assert is outdated. There is no get_module_from_pkg. Should it be changed to get_module_by_package_name()? >> >> 804 assert(ModuleEntryTable::javabase_defined(), >> 805 "Attempt to call get_module_from_pkg before java.base is defined"); >> >> It?s not part of your change, I just happen to notice it. In the same get_module_by_package_name(), both the ?if? and ?else? cases have return statement. The ?return NULL? at line 825 seems will never reached and not needed. >> >> Thanks, >> Jiangli >> >>> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Here are new hotspot webrev where I've fixed the comments from Alan and Christian. >>> >>> Hotspot: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>> >>> >>> The Jdk webrev is the same: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>> >>>> The Jdk webrev: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> Summary: >>>> >>>> JVM TI agents that instrument code in named modules need the Module at class load time. >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a classloader + package name to a module. >>>> We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. >>>> >>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> A CCC is fast-tracked and getting an approval is in progress. >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.dmitriev at oracle.com Wed Jun 22 20:57:28 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 22 Jun 2016 23:57:28 +0300 Subject: RFR(XXS): 8160102: Typo in message for NULL memory size arguments in diagnosticArgument.cpp Message-ID: Hello, Please review small patch which fixes error message for NULL memory size arguments. Currently message for nanotime arguments is printed. I change it to make it consistent with other error messages for memory size arguments. JBS: https://bugs.openjdk.java.net/browse/JDK-8160102 webrev.00: http://cr.openjdk.java.net/~ddmitriev/8160102/webrev.00/ Testing: jprt Thanks, Dmitry From serguei.spitsyn at oracle.com Wed Jun 22 21:02:40 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 14:02:40 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <8175258F-38C7-4D54-8FCF-73C9C17D2D61@oracle.com> <576AF241.7080908@oracle.com> Message-ID: <576AFCF0.9050201@oracle.com> On 6/22/16 13:54, Jiangli Zhou wrote: > Hi Serguei, > >> On Jun 22, 2016, at 1:17 PM, serguei.spitsyn at oracle.com >> wrote: >> >> Hi Jiangli, >> >> Fixed both places - nice catch! >> Would you like I list you as a reviewer? > > No worry, if you already committed/pushed your changes. I've not committed/pushed yet. Thanks, Serguei > > Thanks, > Jiangli > >> >> Thanks, >> Serguei >> >> >> On 6/22/16 10:29, Jiangli Zhou wrote: >>> Hi Serguei, >>> >>> The comment in the following assert is outdated. There is no >>> get_module_from_pkg. Should it be changed to >>> get_module_by_package_name()? >>> >>> 804 assert(ModuleEntryTable::javabase_defined(), >>> 805 "Attempt to call get_module_from_pkg before java.base is defined"); >>> >>> It?s not part of your change, I just happen to notice it. In the >>> same get_module_by_package_name(), both the ?if? and ?else? cases >>> have return statement. The ?return NULL? at line 825 seems will >>> never reached and not needed. >>> >>> Thanks, >>> Jiangli >>> >>>> On Jun 22, 2016, at 4:07 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Here are new hotspot webrev where I've fixed the comments from Alan >>>> and Christian. >>>> >>>> Hotspot: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >>>> >>>> >>>> >>>> The Jdk webrev is the same: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>>>> >>>>> The Jdk webrev: >>>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> JVM TI agents that instrument code in named modules need the >>>>> Module at class load time. >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a >>>>> classloader + package name to a module. >>>>> We were initially not confident with this approach so we >>>>> introduced it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> A CCC is fast-tracked and getting an approval is in progress. >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jun 22 22:31:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 08:31:50 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: On 23/06/2016 5:01 AM, Alan Bateman wrote: > On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: > >> >> Alan, please, let me know if you support the Stanislav's suggestion. >> I can go ahead and implement returning the >> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. > No objection from me. It would be good to first check the existing spec > and also the JNI spec to see if there any similar cases (so that the > update and new function is consistent). Off-hand, I can't think of any > functions that require the same check. Taking GetLocalVariableTable as an example there is no validation that names are legal, so there should not be a check in this case either. Thanks, David ----- > -Alan From serguei.spitsyn at oracle.com Wed Jun 22 23:20:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 16:20:49 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> Message-ID: <576B1D51.10403@oracle.com> On 6/22/16 15:31, David Holmes wrote: > On 23/06/2016 5:01 AM, Alan Bateman wrote: >> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >> >>> >>> Alan, please, let me know if you support the Stanislav's suggestion. >>> I can go ahead and implement returning the >>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >> No objection from me. It would be good to first check the existing spec >> and also the JNI spec to see if there any similar cases (so that the >> update and new function is consistent). Off-hand, I can't think of any >> functions that require the same check. > > Taking GetLocalVariableTable as an example there is no validation that > names are legal, so there should not be a check in this case either. David, I agree with it. Thank you for pointing to this JVMTI example. I did not find in the JNI where the names are checked to be legal. We are going to open a can of worms with this kind of check as there can be many corner cases to cover. Thanks, Serguei > > Thanks, > David > ----- > >> -Alan From david.holmes at oracle.com Wed Jun 22 23:40:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 09:40:49 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B1D51.10403@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> Message-ID: <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> On 23/06/2016 9:20 AM, serguei.spitsyn at oracle.com wrote: > On 6/22/16 15:31, David Holmes wrote: >> On 23/06/2016 5:01 AM, Alan Bateman wrote: >>> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >>> >>>> >>>> Alan, please, let me know if you support the Stanislav's suggestion. >>>> I can go ahead and implement returning the >>>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >>> No objection from me. It would be good to first check the existing spec >>> and also the JNI spec to see if there any similar cases (so that the >>> update and new function is consistent). Off-hand, I can't think of any >>> functions that require the same check. >> >> Taking GetLocalVariableTable as an example there is no validation that >> names are legal, so there should not be a check in this case either. > > David, > > I agree with it. > Thank you for pointing to this JVMTI example. > I did not find in the JNI where the names are checked to be legal. > We are going to open a can of worms with this kind of check as there can > be many corner cases to cover. Right - JVM TI and JNI both do minimal argument checking/validation. You may want to specify an error for the NULL case - or else treat it as the empty string (which would need documenting). Cheers, David > Thanks, > Serguei > > >> >> Thanks, >> David >> ----- >> >>> -Alan > From stanislav.lukyanov at oracle.com Wed Jun 22 17:09:19 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Wed, 22 Jun 2016 20:09:19 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576A8D0D.3090907@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> Message-ID: Hi Serguei, What is the expected behavior when passed string is not a valid package name (e.g. contains illegal characters)? I think I'd expect JVMTI_ERROR_ILLEGAL_ARGUMENT to be returned in that case. Now it looks like the method will return unnamed module not only for an empty string but for any string that is not a known package name. If it's correct, I think the empty string case shouldn't be described explicitly. Thanks, Stas On 22.06.2016 16:05, serguei.spitsyn at oracle.com wrote: > I've updated the libGetModuleByPkgTest.c in place in the webrev #2 > with minor improvements. > Sorry, if it spoiled your work. > > Thanks, > Serguei > > > On 6/22/16 04:07, serguei.spitsyn at oracle.com wrote: >> Here are new hotspot webrev where I've fixed the comments from Alan >> and Christian. >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 >> >> >> >> The Jdk webrev is the same: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> >> >> >> Thanks, >> Serguei >> >> >> On 6/21/16 02:54, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/ >>> >>> >>> The Jdk webrev: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >>> >>> >>> Summary: >>> >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a >>> classloader + package name to a module. >>> We were initially not confident with this approach so we >>> introduced it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> This fix is to introduce new JVMTI function GetModuleByPackageName. >>> It includes new jtreg test with native JVMTI agent. >>> >>> A CCC is fast-tracked and getting an approval is in progress. >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Thu Jun 23 00:02:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jun 2016 17:02:33 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <4d85bb7c-0f8a-c05d-782f-fd7e7499d652@oracle.com> Message-ID: <576B2719.7020104@oracle.com> On 6/22/16 16:40, David Holmes wrote: > On 23/06/2016 9:20 AM, serguei.spitsyn at oracle.com wrote: >> On 6/22/16 15:31, David Holmes wrote: >>> On 23/06/2016 5:01 AM, Alan Bateman wrote: >>>> On 22/06/2016 19:36, serguei.spitsyn at oracle.com wrote: >>>> >>>>> >>>>> Alan, please, let me know if you support the Stanislav's suggestion. >>>>> I can go ahead and implement returning the >>>>> JVMTI_ERROR_ILLEGAL_ARGUMENT for invalid package names. >>>> No objection from me. It would be good to first check the existing >>>> spec >>>> and also the JNI spec to see if there any similar cases (so that the >>>> update and new function is consistent). Off-hand, I can't think of any >>>> functions that require the same check. >>> >>> Taking GetLocalVariableTable as an example there is no validation that >>> names are legal, so there should not be a check in this case either. >> >> David, >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there can >> be many corner cases to cover. > > Right - JVM TI and JNI both do minimal argument checking/validation. > > You may want to specify an error for the NULL case - or else treat it > as the empty string (which would need documenting). It is already there. It is a part of the universal-error : http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#universal-error Thanks, Serguei > > Cheers, > David > >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> -Alan >> From david.holmes at oracle.com Thu Jun 23 00:08:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 10:08:43 +1000 Subject: RFR(XXS): 8160102: Typo in message for NULL memory size arguments in diagnosticArgument.cpp In-Reply-To: References: Message-ID: <0f7dd363-d40a-609d-58c3-22317f29d489@oracle.com> Looks good. Thanks, David On 23/06/2016 6:57 AM, Dmitry Dmitriev wrote: > Hello, > > Please review small patch which fixes error message for NULL memory size > arguments. Currently message for nanotime arguments is printed. I change > it to make it consistent with other error messages for memory size > arguments. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160102 > webrev.00: http://cr.openjdk.java.net/~ddmitriev/8160102/webrev.00/ > > Testing: jprt > > Thanks, > Dmitry From Alan.Bateman at oracle.com Thu Jun 23 07:51:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 08:51:36 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B1D51.10403@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> Message-ID: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: > : > > I agree with it. > Thank you for pointing to this JVMTI example. > I did not find in the JNI where the names are checked to be legal. > We are going to open a can of worms with this kind of check as there > can be many corner cases to cover. The primary use-case for this function is from within the CLFH callback so have it return the unnamed module when calling with garage is probably okay, it just needs to be specified. Will you update the webrev to reflect where we've got to this in this discussion? -Alan From david.holmes at oracle.com Thu Jun 23 07:57:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 17:57:25 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> Message-ID: <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> On 23/06/2016 5:51 PM, Alan Bateman wrote: > > > On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >> : >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there >> can be many corner cases to cover. > The primary use-case for this function is from within the CLFH callback > so have it return the unnamed module when calling with garage is > probably okay, it just needs to be specified. It already is specified :) If the name is garbage then it is, by definition, not a package that is associated with any module hence the else clause kicks in and the unnamed module is returned. David ----- > Will you update the webrev to reflect where we've got to this in this > discussion? > > -Alan From Alan.Bateman at oracle.com Thu Jun 23 08:02:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jun 2016 09:02:45 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> Message-ID: <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> On 23/06/2016 08:57, David Holmes wrote: > > It already is specified :) If the name is garbage then it is, by > definition, not a package that is associated with any module hence the > else clause kicks in and the unnamed module is returned. Sure but there are are other changes the wording in this thread and I think it would be good to see the final changes to jvmti.xml. -Alan From serguei.spitsyn at oracle.com Thu Jun 23 08:04:13 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 01:04:13 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> Message-ID: <576B97FD.1080303@oracle.com> On 6/23/16 00:51, Alan Bateman wrote: > > > On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >> : >> >> I agree with it. >> Thank you for pointing to this JVMTI example. >> I did not find in the JNI where the names are checked to be legal. >> We are going to open a can of worms with this kind of check as there >> can be many corner cases to cover. > The primary use-case for this function is from within the CLFH > callback so have it return the unnamed module when calling with garage > is probably okay, it just needs to be specified. > > Will you update the webrev to reflect where we've got to this in this > discussion? I need to undo my fix for additional check. My up-to-date understanding is that we have to explicitly specify two points: - the function returns the unnamed module if the package does not exist - the function does not check the package names for validness and always returns the unnamed module for illegal package names It is better to specify these points explicitly to avoid possible confusion. Thanks, Serguei > > -Alan From serguei.spitsyn at oracle.com Thu Jun 23 08:41:37 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 01:41:37 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> Message-ID: <576BA0C1.2090301@oracle.com> Updated the webrev in place: Hotspot: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 Please, let me know about your opinion. Do I have to update the CCC as well? Thanks, Serguei On 6/23/16 01:02, Alan Bateman wrote: > > > On 23/06/2016 08:57, David Holmes wrote: >> >> It already is specified :) If the name is garbage then it is, by >> definition, not a package that is associated with any module hence >> the else clause kicks in and the unnamed module is returned. > Sure but there are are other changes the wording in this thread and I > think it would be good to see the final changes to jvmti.xml. > > -Alan From adinn at redhat.com Thu Jun 23 08:52:57 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Jun 2016 09:52:57 +0100 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BA0C1.2090301@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> <576BA0C1.2090301@oracle.com> Message-ID: <576BA369.4080305@redhat.com> On 23/06/16 09:41, serguei.spitsyn at oracle.com wrote: > Updated the webrev in place: > > Hotspot: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 Just as an aside, I think it's actually a bad idea to update in place. Much better to just add new webrevs. Why? Well, the mail lists provide an audit of the review process for a given change. Webrevs are the data on which those reviews are based. So, removing them (by overwriting) makes it harder to understand why a specific choice was made. This may not matter most of the time but when a fix gets revoked thanks, say, to a regression of some sort it's important to be able to go back and re-read that audit trail. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From serguei.spitsyn at oracle.com Thu Jun 23 09:08:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 02:08:08 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BA369.4080305@redhat.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <4f9176cf-9ec1-12ac-132a-2baf14091248@oracle.com> <4ddba382-f852-19f2-3b98-1096bea5d3dc@oracle.com> <576BA0C1.2090301@oracle.com> <576BA369.4080305@redhat.com> Message-ID: <576BA6F8.8040808@oracle.com> Hi Andrew, You should not try to convince me that updating webrev in place is a generally bad idea. I have the same opinion. :) Just did not want to generate another round for a pretty small change. Sorry. Thanks, Serguei On 6/23/16 01:52, Andrew Dinn wrote: > On 23/06/16 09:41, serguei.spitsyn at oracle.com wrote: >> Updated the webrev in place: >> >> Hotspot: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.2 > Just as an aside, I think it's actually a bad idea to update in place. > Much better to just add new webrevs. > > Why? Well, the mail lists provide an audit of the review process for a > given change. Webrevs are the data on which those reviews are based. So, > removing them (by overwriting) makes it harder to understand why a > specific choice was made. This may not matter most of the time but when > a fix gets revoked thanks, say, to a regression of some sort it's > important to be able to go back and re-read that audit trail. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From robbin.ehn at oracle.com Thu Jun 23 09:54:09 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 23 Jun 2016 11:54:09 +0200 Subject: RFR(XXS): 8160102: Typo in message for NULL memory size arguments in diagnosticArgument.cpp In-Reply-To: References: Message-ID: Hi Dmitry, Looks good, thanks! /Robbin On 06/22/2016 10:57 PM, Dmitry Dmitriev wrote: > Hello, > > Please review small patch which fixes error message for NULL memory size arguments. Currently message for nanotime arguments is printed. I change it to make it consistent > with other error messages for memory size arguments. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160102 > webrev.00: http://cr.openjdk.java.net/~ddmitriev/8160102/webrev.00/ > Testing: jprt > > Thanks, > Dmitry From david.holmes at oracle.com Thu Jun 23 10:51:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 20:51:27 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576B97FD.1080303@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> Message-ID: <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 00:51, Alan Bateman wrote: >> >> >> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>> : >>> >>> I agree with it. >>> Thank you for pointing to this JVMTI example. >>> I did not find in the JNI where the names are checked to be legal. >>> We are going to open a can of worms with this kind of check as there >>> can be many corner cases to cover. >> The primary use-case for this function is from within the CLFH >> callback so have it return the unnamed module when calling with garage >> is probably okay, it just needs to be specified. >> >> Will you update the webrev to reflect where we've got to this in this >> discussion? > > I need to undo my fix for additional check. > My up-to-date understanding is that we have to explicitly specify two > points: > - the function returns the unnamed module if the package does not exist > - the function does not check the package names for validness and > always returns the unnamed module for illegal package names > > It is better to specify these points explicitly to avoid possible > confusion. I don't agree - nothing else refers to invalid "names" in JVM TI. I don't see any need to call this out here. If the name supplied is not a legal package name then it will not match - end of story. Cheers, David > Thanks, > Serguei > > > >> >> -Alan > From dmitry.dmitriev at oracle.com Thu Jun 23 10:56:59 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 23 Jun 2016 13:56:59 +0300 Subject: RFR(XXS): 8160102: Typo in message for NULL memory size arguments in diagnosticArgument.cpp In-Reply-To: <0f7dd363-d40a-609d-58c3-22317f29d489@oracle.com> References: <0f7dd363-d40a-609d-58c3-22317f29d489@oracle.com> Message-ID: <0f4b2e8e-ac23-e0a9-effc-bc256d147d59@oracle.com> David, thank you for the review! Dmitry On 23.06.2016 3:08, David Holmes wrote: > Looks good. > > Thanks, > David > > On 23/06/2016 6:57 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review small patch which fixes error message for NULL memory size >> arguments. Currently message for nanotime arguments is printed. I change >> it to make it consistent with other error messages for memory size >> arguments. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160102 >> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8160102/webrev.00/ >> >> Testing: jprt >> >> Thanks, >> Dmitry From dmitry.dmitriev at oracle.com Thu Jun 23 10:57:20 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 23 Jun 2016 13:57:20 +0300 Subject: RFR(XXS): 8160102: Typo in message for NULL memory size arguments in diagnosticArgument.cpp In-Reply-To: References: Message-ID: <7698c20f-d63d-f132-4749-0c415c4481c0@oracle.com> Robbin, thank you for the review! Dmitry On 23.06.2016 12:54, Robbin Ehn wrote: > Hi Dmitry, > > Looks good, thanks! > > /Robbin > > On 06/22/2016 10:57 PM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review small patch which fixes error message for NULL memory >> size arguments. Currently message for nanotime arguments is printed. >> I change it to make it consistent >> with other error messages for memory size arguments. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160102 >> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8160102/webrev.00/ >> >> Testing: jprt >> >> Thanks, >> Dmitry From serguei.spitsyn at oracle.com Thu Jun 23 11:08:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 04:08:33 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> Message-ID: <576BC331.8000400@oracle.com> On 6/23/16 03:51, David Holmes wrote: > On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 00:51, Alan Bateman wrote: >>> >>> >>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>> : >>>> >>>> I agree with it. >>>> Thank you for pointing to this JVMTI example. >>>> I did not find in the JNI where the names are checked to be legal. >>>> We are going to open a can of worms with this kind of check as there >>>> can be many corner cases to cover. >>> The primary use-case for this function is from within the CLFH >>> callback so have it return the unnamed module when calling with garage >>> is probably okay, it just needs to be specified. >>> >>> Will you update the webrev to reflect where we've got to this in this >>> discussion? >> >> I need to undo my fix for additional check. >> My up-to-date understanding is that we have to explicitly specify two >> points: >> - the function returns the unnamed module if the package does not >> exist >> - the function does not check the package names for validness and >> always returns the unnamed module for illegal package names >> >> It is better to specify these points explicitly to avoid possible >> confusion. > > I don't agree - nothing else refers to invalid "names" in JVM TI. I > don't see any need to call this out here. If the name supplied is not > a legal package name then it will not match - end of story. David, It was the original approach that is in the CCC. You were the one who got confused here, and it convinced me that this needs to be more clear. All these changes are because you started the discussion. :) It was useful anyway. Are you against both clarifications or just the last one? I'm Ok to return it back as it is in the CCC. It will save time on the CCC approval. This is the last addition to the spec: + The unnamed module is returned if the specified package does not exist. + The function does not check if the specified package name is illegal. Thanks, Serguei > > Cheers, > David > > >> Thanks, >> Serguei >> >> >> >>> >>> -Alan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 23 11:27:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:27:10 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BC331.8000400@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> Message-ID: <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 03:51, David Holmes wrote: >> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 00:51, Alan Bateman wrote: >>>> >>>> >>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>> : >>>>> >>>>> I agree with it. >>>>> Thank you for pointing to this JVMTI example. >>>>> I did not find in the JNI where the names are checked to be legal. >>>>> We are going to open a can of worms with this kind of check as there >>>>> can be many corner cases to cover. >>>> The primary use-case for this function is from within the CLFH >>>> callback so have it return the unnamed module when calling with garage >>>> is probably okay, it just needs to be specified. >>>> >>>> Will you update the webrev to reflect where we've got to this in this >>>> discussion? >>> >>> I need to undo my fix for additional check. >>> My up-to-date understanding is that we have to explicitly specify two >>> points: >>> - the function returns the unnamed module if the package does not >>> exist >>> - the function does not check the package names for validness and >>> always returns the unnamed module for illegal package names >>> >>> It is better to specify these points explicitly to avoid possible >>> confusion. >> >> I don't agree - nothing else refers to invalid "names" in JVM TI. I >> don't see any need to call this out here. If the name supplied is not >> a legal package name then it will not match - end of story. > > David, > > It was the original approach that is in the CCC. > You were the one who got confused here, and it convinced me that this > needs to be more clear. > All these changes are because you started the discussion. :) > It was useful anyway. I never said anything about illegal package names. > Are you against both clarifications or just the last one? > I'm Ok to return it back as it is in the CCC. > It will save time on the CCC approval. > > This is the last addition to the spec: > > + The unnamed module is returned if the specified package does not exist. The notion of "package does not exist" is ill-defined. This case is already covered by the primary specification. > + The function does not check if the specified package name is illegal. This does not need to be stated as it is not stated anywhere else for anything else that may have legal and illegal forms. Thanks, David > > > Thanks, > Serguei > > > > >> >> Cheers, >> David >> >> >>> Thanks, >>> Serguei >>> >>> >>> >>>> >>>> -Alan >>> > From serguei.spitsyn at oracle.com Thu Jun 23 11:33:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 04:33:49 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> Message-ID: <576BC91D.9050204@oracle.com> On 6/23/16 04:27, David Holmes wrote: > On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 03:51, David Holmes wrote: >>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>> >>>>> >>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>> : >>>>>> >>>>>> I agree with it. >>>>>> Thank you for pointing to this JVMTI example. >>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>> We are going to open a can of worms with this kind of check as there >>>>>> can be many corner cases to cover. >>>>> The primary use-case for this function is from within the CLFH >>>>> callback so have it return the unnamed module when calling with >>>>> garage >>>>> is probably okay, it just needs to be specified. >>>>> >>>>> Will you update the webrev to reflect where we've got to this in this >>>>> discussion? >>>> >>>> I need to undo my fix for additional check. >>>> My up-to-date understanding is that we have to explicitly specify two >>>> points: >>>> - the function returns the unnamed module if the package does not >>>> exist >>>> - the function does not check the package names for validness and >>>> always returns the unnamed module for illegal package names >>>> >>>> It is better to specify these points explicitly to avoid possible >>>> confusion. >>> >>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>> don't see any need to call this out here. If the name supplied is not >>> a legal package name then it will not match - end of story. >> >> David, >> >> It was the original approach that is in the CCC. >> You were the one who got confused here, and it convinced me that this >> needs to be more clear. >> All these changes are because you started the discussion. :) >> It was useful anyway. > > I never said anything about illegal package names. True. This is my (probably, wrong) attempt to make it more clear. > >> Are you against both clarifications or just the last one? >> I'm Ok to return it back as it is in the CCC. >> It will save time on the CCC approval. >> >> This is the last addition to the spec: >> >> + The unnamed module is returned if the specified package does not >> exist. > > The notion of "package does not exist" is ill-defined. This case is > already covered by the primary specification. > >> + The function does not check if the specified package name is illegal. > > This does not need to be stated as it is not stated anywhere else for > anything else that may have legal and illegal forms. Good. This is a relevant fragment from current version of CCC: + + Return the java.lang.reflect.Module object for a module + defined to a class loader that contains a given package. + The module is returned via module_ptr. +

+ If a named module is defined to the class loader and it + contains the package then that named module is returned, + otherwise the unnamed module of the class loader is returned. + If the package name is the empty string then this function + always returns the unnamed module for the class loader. +

Does it looks Ok? Thanks, Serguei > > Thanks, > David > >> >> >> Thanks, >> Serguei >> >> >> >> >>> >>> Cheers, >>> David >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>>> >>>>> -Alan >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 23 11:40:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jun 2016 21:40:31 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576BC91D.9050204@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> Message-ID: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: > On 6/23/16 04:27, David Holmes wrote: >> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 03:51, David Holmes wrote: >>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>> : >>>>>>> >>>>>>> I agree with it. >>>>>>> Thank you for pointing to this JVMTI example. >>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>> We are going to open a can of worms with this kind of check as there >>>>>>> can be many corner cases to cover. >>>>>> The primary use-case for this function is from within the CLFH >>>>>> callback so have it return the unnamed module when calling with >>>>>> garage >>>>>> is probably okay, it just needs to be specified. >>>>>> >>>>>> Will you update the webrev to reflect where we've got to this in this >>>>>> discussion? >>>>> >>>>> I need to undo my fix for additional check. >>>>> My up-to-date understanding is that we have to explicitly specify two >>>>> points: >>>>> - the function returns the unnamed module if the package does not >>>>> exist >>>>> - the function does not check the package names for validness and >>>>> always returns the unnamed module for illegal package names >>>>> >>>>> It is better to specify these points explicitly to avoid possible >>>>> confusion. >>>> >>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>> don't see any need to call this out here. If the name supplied is not >>>> a legal package name then it will not match - end of story. >>> >>> David, >>> >>> It was the original approach that is in the CCC. >>> You were the one who got confused here, and it convinced me that this >>> needs to be more clear. >>> All these changes are because you started the discussion. :) >>> It was useful anyway. >> >> I never said anything about illegal package names. > > True. > This is my (probably, wrong) attempt to make it more clear. > >> >>> Are you against both clarifications or just the last one? >>> I'm Ok to return it back as it is in the CCC. >>> It will save time on the CCC approval. >>> >>> This is the last addition to the spec: >>> >>> + The unnamed module is returned if the specified package does not >>> exist. >> >> The notion of "package does not exist" is ill-defined. This case is >> already covered by the primary specification. >> >>> + The function does not check if the specified package name is illegal. >> >> This does not need to be stated as it is not stated anywhere else for >> anything else that may have legal and illegal forms. > > Good. > This is a relevant fragment from current version of CCC: > > + > + Return the java.lang.reflect.Module object for a > module > + defined to a class loader that contains a given package. > + The module is returned via module_ptr. > +

> + If a named module is defined to the class loader and it > + contains the package then that named module is returned, > + otherwise the unnamed module of the class loader is returned. > + If the package name is the empty string then this function > + always returns the unnamed module for the class loader. > +

As Stanislav said explicitly mentioning the empty string is not really necessary - but I don't see it as harmful. > Does it looks Ok? Yes - as good now as it was in the CCC discussion :) Cheers, David > > Thanks, > Serguei > >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>>> >>>> Cheers, >>>> David >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>>> >>>>>> -Alan >>>>> >>> > From serguei.spitsyn at oracle.com Thu Jun 23 12:00:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 05:00:46 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: <576BCF6E.9030000@oracle.com> On 6/23/16 04:40, David Holmes wrote: > > > On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 04:27, David Holmes wrote: >>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 03:51, David Holmes wrote: >>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>> : >>>>>>>> >>>>>>>> I agree with it. >>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>> there >>>>>>>> can be many corner cases to cover. >>>>>>> The primary use-case for this function is from within the CLFH >>>>>>> callback so have it return the unnamed module when calling with >>>>>>> garage >>>>>>> is probably okay, it just needs to be specified. >>>>>>> >>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>> this >>>>>>> discussion? >>>>>> >>>>>> I need to undo my fix for additional check. >>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>> two >>>>>> points: >>>>>> - the function returns the unnamed module if the package does not >>>>>> exist >>>>>> - the function does not check the package names for validness and >>>>>> always returns the unnamed module for illegal package names >>>>>> >>>>>> It is better to specify these points explicitly to avoid possible >>>>>> confusion. >>>>> >>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>> don't see any need to call this out here. If the name supplied is not >>>>> a legal package name then it will not match - end of story. >>>> >>>> David, >>>> >>>> It was the original approach that is in the CCC. >>>> You were the one who got confused here, and it convinced me that this >>>> needs to be more clear. >>>> All these changes are because you started the discussion. :) >>>> It was useful anyway. >>> >>> I never said anything about illegal package names. >> >> True. >> This is my (probably, wrong) attempt to make it more clear. >> >>> >>>> Are you against both clarifications or just the last one? >>>> I'm Ok to return it back as it is in the CCC. >>>> It will save time on the CCC approval. >>>> >>>> This is the last addition to the spec: >>>> >>>> + The unnamed module is returned if the specified package does not >>>> exist. >>> >>> The notion of "package does not exist" is ill-defined. This case is >>> already covered by the primary specification. >>> >>>> + The function does not check if the specified package name is >>>> illegal. >>> >>> This does not need to be stated as it is not stated anywhere else for >>> anything else that may have legal and illegal forms. >> >> Good. >> This is a relevant fragment from current version of CCC: >> >> + >> + Return the java.lang.reflect.Module object for a >> module >> + defined to a class loader that contains a given package. >> + The module is returned via module_ptr. >> +

>> + If a named module is defined to the class loader and it >> + contains the package then that named module is returned, >> + otherwise the unnamed module of the class loader is returned. >> + If the package name is the empty string then this function >> + always returns the unnamed module for the class loader. >> +

> > As Stanislav said explicitly mentioning the empty string is not really > necessary - but I don't see it as harmful. Me too. Stanislav did not insist on this matter. > >> Does it looks Ok? > > Yes - as good now as it was in the CCC discussion :) Great! I'm also waiting for a feedback from Alan. Thanks! Serguei > > Cheers, > David > From stanislav.lukyanov at oracle.com Thu Jun 23 13:02:57 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Thu, 23 Jun 2016 16:02:57 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: There were different points in the discussion I didn't have a chance to comment in time, so I'll just summarize everything here not to break the thread flow with answers to older messages. First of all, I'm perfectly fine with either approach (adding name validation or not) as long as the behavior is clearly documented. I think it should be specified that unnamed module will be returned even if there cannot ever be a package with that name. It is not a complicated case to specify, but it brings much more clarity. Formally, now the function is specified to work with "package names" and the behavior on a string that is clearly not a "package name" is unspecified. The empty string case may or may not be specified. It may be considered another corner case, different from both "legal" and "illegal" package names, but I personally think that the behavior is clear anyway. I don't think the argument that JVMTI doesn't validate names is correct. GetLocalVariableTable doesn't look like a good example here, since it just reads data that's already in the VM anyway, but in case of GetModuleByPackageName it is about validation of input parameters. Other APIs that take identifiers like, for example, JNI FindClass or GetMethodID don't specify name checks explicitly, but throw ClassNotFoundError/NoSuchMethodError illegal names. It looks like GetModuleByPackageName is the first JNI/JVMTI function to succeed when an ill-formed identifier is passed, so it deserves to be documented. On CCC update: AFAIU CCC needs to have final version of the proposed specification, so yes, it needs to be updated to with the test that will be actually pushed to the workspace. Thanks, Stas On 23.06.2016 14:40, David Holmes wrote: > > > On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 04:27, David Holmes wrote: >>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 03:51, David Holmes wrote: >>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>> >>>>>>> >>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>> : >>>>>>>> >>>>>>>> I agree with it. >>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>> there >>>>>>>> can be many corner cases to cover. >>>>>>> The primary use-case for this function is from within the CLFH >>>>>>> callback so have it return the unnamed module when calling with >>>>>>> garage >>>>>>> is probably okay, it just needs to be specified. >>>>>>> >>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>> this >>>>>>> discussion? >>>>>> >>>>>> I need to undo my fix for additional check. >>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>> two >>>>>> points: >>>>>> - the function returns the unnamed module if the package does not >>>>>> exist >>>>>> - the function does not check the package names for validness and >>>>>> always returns the unnamed module for illegal package names >>>>>> >>>>>> It is better to specify these points explicitly to avoid possible >>>>>> confusion. >>>>> >>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>> don't see any need to call this out here. If the name supplied is not >>>>> a legal package name then it will not match - end of story. >>>> >>>> David, >>>> >>>> It was the original approach that is in the CCC. >>>> You were the one who got confused here, and it convinced me that this >>>> needs to be more clear. >>>> All these changes are because you started the discussion. :) >>>> It was useful anyway. >>> >>> I never said anything about illegal package names. >> >> True. >> This is my (probably, wrong) attempt to make it more clear. >> >>> >>>> Are you against both clarifications or just the last one? >>>> I'm Ok to return it back as it is in the CCC. >>>> It will save time on the CCC approval. >>>> >>>> This is the last addition to the spec: >>>> >>>> + The unnamed module is returned if the specified package does not >>>> exist. >>> >>> The notion of "package does not exist" is ill-defined. This case is >>> already covered by the primary specification. >>> >>>> + The function does not check if the specified package name is >>>> illegal. >>> >>> This does not need to be stated as it is not stated anywhere else for >>> anything else that may have legal and illegal forms. >> >> Good. >> This is a relevant fragment from current version of CCC: >> >> + >> + Return the java.lang.reflect.Module object for a >> module >> + defined to a class loader that contains a given package. >> + The module is returned via module_ptr. >> +

>> + If a named module is defined to the class loader and it >> + contains the package then that named module is returned, >> + otherwise the unnamed module of the class loader is returned. >> + If the package name is the empty string then this function >> + always returns the unnamed module for the class loader. >> +

> > As Stanislav said explicitly mentioning the empty string is not really > necessary - but I don't see it as harmful. > >> Does it looks Ok? > > Yes - as good now as it was in the CCC discussion :) > > Cheers, > David > >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -Alan >>>>>> >>>> >> From david.holmes at oracle.com Thu Jun 23 22:14:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 08:14:45 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> Message-ID: <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: > There were different points in the discussion I didn't have a chance to > comment in time, > so I'll just summarize everything here not to break the thread flow with > answers to older messages. > > First of all, I'm perfectly fine with either approach (adding name > validation or not) > as long as the behavior is clearly documented. > > I think it should be specified that unnamed module will be returned even > if there cannot ever be a package > with that name. It is not a complicated case to specify, but it brings > much more clarity. > Formally, now the function is specified to work with "package names" and > the behavior on a string that is clearly not a "package name" is > unspecified. I think it is completely specified. Something that can not be a valid package name can obviously not have a module associated with it and so the unnamed-module is always returned. > The empty string case may or may not be specified. It may be considered > another corner case, different from both > "legal" and "illegal" package names, but I personally think that the > behavior is clear anyway. > > I don't think the argument that JVMTI doesn't validate names is correct. > GetLocalVariableTable doesn't look like a good example here, since > it just reads data that's already in the VM anyway, > but in case of GetModuleByPackageName it is about validation of input > parameters. > Other APIs that take identifiers like, for example, JNI FindClass or > GetMethodID > don't specify name checks explicitly, but throw > ClassNotFoundError/NoSuchMethodError illegal names. > It looks like GetModuleByPackageName is the first JNI/JVMTI function to > succeed when an ill-formed identifier is passed, > so it deserves to be documented. I disagree with all of that. GetLocalVariableTable, ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a few, all take "names" encoded as UTF-8 modified strings. None of them validate that the "name" is legal for the entity being named - JVM TI simply does not do that kind of argument validation. The JNI functions also do not do argument validation. The JNI spec is clear "The JNI does not check for programming errors such as passing in NULL pointers or illegal argument types". It is up to the programmer to ensure they pass valid arguments. FindClass is specified to simply throw: NoClassDefFoundError: if no definition for a requested class or interface can be found. It is the internal VM code, that has to deal with bytecode from arbitrary sources, that performs the more detailed checking of the name. GetModuleByPackageName is slightly unusual in that it really never fails. As I discussed in the CCC review it could have made a distinction between packages that would be loaded by the loader and packages that would not, and throw an exception (which in turn may have been able to discern that the name was invalid). But that is not the case - if you don't pass the name of a package that is known to the loader then you get back the unnamed-module. It doesn't matter whether the package name is legal-but-unknown, or illegal - it is just unknown. David ------ > On CCC update: AFAIU CCC needs to have final version of the proposed > specification, so yes, > it needs to be updated to with the test that will be actually pushed to > the workspace. > > Thanks, > Stas > > On 23.06.2016 14:40, David Holmes wrote: >> >> >> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 04:27, David Holmes wrote: >>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>> : >>>>>>>>> >>>>>>>>> I agree with it. >>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>> I did not find in the JNI where the names are checked to be legal. >>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>> there >>>>>>>>> can be many corner cases to cover. >>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>> garage >>>>>>>> is probably okay, it just needs to be specified. >>>>>>>> >>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>> this >>>>>>>> discussion? >>>>>>> >>>>>>> I need to undo my fix for additional check. >>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>> two >>>>>>> points: >>>>>>> - the function returns the unnamed module if the package does not >>>>>>> exist >>>>>>> - the function does not check the package names for validness and >>>>>>> always returns the unnamed module for illegal package names >>>>>>> >>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>> confusion. >>>>>> >>>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>>> don't see any need to call this out here. If the name supplied is not >>>>>> a legal package name then it will not match - end of story. >>>>> >>>>> David, >>>>> >>>>> It was the original approach that is in the CCC. >>>>> You were the one who got confused here, and it convinced me that this >>>>> needs to be more clear. >>>>> All these changes are because you started the discussion. :) >>>>> It was useful anyway. >>>> >>>> I never said anything about illegal package names. >>> >>> True. >>> This is my (probably, wrong) attempt to make it more clear. >>> >>>> >>>>> Are you against both clarifications or just the last one? >>>>> I'm Ok to return it back as it is in the CCC. >>>>> It will save time on the CCC approval. >>>>> >>>>> This is the last addition to the spec: >>>>> >>>>> + The unnamed module is returned if the specified package does not >>>>> exist. >>>> >>>> The notion of "package does not exist" is ill-defined. This case is >>>> already covered by the primary specification. >>>> >>>>> + The function does not check if the specified package name is >>>>> illegal. >>>> >>>> This does not need to be stated as it is not stated anywhere else for >>>> anything else that may have legal and illegal forms. >>> >>> Good. >>> This is a relevant fragment from current version of CCC: >>> >>> + >>> + Return the java.lang.reflect.Module object for a >>> module >>> + defined to a class loader that contains a given package. >>> + The module is returned via module_ptr. >>> +

>>> + If a named module is defined to the class loader and it >>> + contains the package then that named module is returned, >>> + otherwise the unnamed module of the class loader is returned. >>> + If the package name is the empty string then this function >>> + always returns the unnamed module for the class loader. >>> +

>> >> As Stanislav said explicitly mentioning the empty string is not really >> necessary - but I don't see it as harmful. >> >>> Does it looks Ok? >> >> Yes - as good now as it was in the CCC discussion :) >> >> Cheers, >> David >> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Thu Jun 23 23:07:54 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Jun 2016 16:07:54 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> Message-ID: <576C6BCA.6090100@oracle.com> On 6/23/16 15:14, David Holmes wrote: > On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >> There were different points in the discussion I didn't have a chance to >> comment in time, >> so I'll just summarize everything here not to break the thread flow with >> answers to older messages. Thank you for taking these steps. It is very helpful. >> >> First of all, I'm perfectly fine with either approach (adding name >> validation or not) >> as long as the behavior is clearly documented. Good. >> >> I think it should be specified that unnamed module will be returned even >> if there cannot ever be a package >> with that name. It is not a complicated case to specify, but it brings >> much more clarity. >> Formally, now the function is specified to work with "package names" and >> the behavior on a string that is clearly not a "package name" is >> unspecified. > > I think it is completely specified. Something that can not be a valid > package name can obviously not have a module associated with it and so > the unnamed-module is always returned. I tend to agree with David here. It is good that you guys having this discussion here as it is a way to reach a consensus. > >> The empty string case may or may not be specified. It may be considered >> another corner case, different from both >> "legal" and "illegal" package names, but I personally think that the >> behavior is clear anyway. Ok. >> >> I don't think the argument that JVMTI doesn't validate names is correct. >> GetLocalVariableTable doesn't look like a good example here, since >> it just reads data that's already in the VM anyway, >> but in case of GetModuleByPackageName it is about validation of input >> parameters. Agreed here. >> Other APIs that take identifiers like, for example, JNI FindClass or >> GetMethodID >> don't specify name checks explicitly, but throw >> ClassNotFoundError/NoSuchMethodError illegal names. The JNI does not do any check for illegal names. If the name is illegal then the target is not found. It is why the ClassNotFoundError/NoSuchMethodError is thrown. It perfectly matches the current GetModuleByPackageName specification approach. >> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >> succeed when an ill-formed identifier is passed, >> so it deserves to be documented. > > I disagree with all of that. GetLocalVariableTable, ClassFileLoadHook, > DynamicCodeGenerated, GetThreadInfo, to name a few, all take "names" > encoded as UTF-8 modified strings. None of them validate that the > "name" is legal for the entity being named - JVM TI simply does not do > that kind of argument validation. Right. > > The JNI functions also do not do argument validation. The JNI spec is > clear "The JNI does not check for programming errors such as passing > in NULL pointers or illegal argument types". It is up to the > programmer to ensure they pass valid arguments. FindClass is specified > to simply throw: > > NoClassDefFoundError: if no definition for a requested class or > interface can be found. > > It is the internal VM code, that has to deal with bytecode from > arbitrary sources, that performs the more detailed checking of the name. Right. > > GetModuleByPackageName is slightly unusual in that it really never > fails. As I discussed in the CCC review it could have made a > distinction between packages that would be loaded by the loader and > packages that would not, and throw an exception (which in turn may > have been able to discern that the name was invalid). But that is not > the case - if you don't pass the name of a package that is known to > the loader then you get back the unnamed-module. It doesn't matter > whether the package name is legal-but-unknown, or illegal - it is just > unknown. I tend to agree with David here. But interested to know what objections to this can be. Thanks, Serguei > > David > ------ > >> On CCC update: AFAIU CCC needs to have final version of the proposed >> specification, so yes, >> it needs to be updated to with the test that will be actually pushed to >> the workspace. >> >> Thanks, >> Stas >> >> On 23.06.2016 14:40, David Holmes wrote: >>> >>> >>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/23/16 04:27, David Holmes wrote: >>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> I agree with it. >>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>> legal. >>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>> there >>>>>>>>>> can be many corner cases to cover. >>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>> garage >>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>> >>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>> this >>>>>>>>> discussion? >>>>>>>> >>>>>>>> I need to undo my fix for additional check. >>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>> two >>>>>>>> points: >>>>>>>> - the function returns the unnamed module if the package does >>>>>>>> not >>>>>>>> exist >>>>>>>> - the function does not check the package names for validness >>>>>>>> and >>>>>>>> always returns the unnamed module for illegal package names >>>>>>>> >>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>> confusion. >>>>>>> >>>>>>> I don't agree - nothing else refers to invalid "names" in JVM TI. I >>>>>>> don't see any need to call this out here. If the name supplied >>>>>>> is not >>>>>>> a legal package name then it will not match - end of story. >>>>>> >>>>>> David, >>>>>> >>>>>> It was the original approach that is in the CCC. >>>>>> You were the one who got confused here, and it convinced me that >>>>>> this >>>>>> needs to be more clear. >>>>>> All these changes are because you started the discussion. :) >>>>>> It was useful anyway. >>>>> >>>>> I never said anything about illegal package names. >>>> >>>> True. >>>> This is my (probably, wrong) attempt to make it more clear. >>>> >>>>> >>>>>> Are you against both clarifications or just the last one? >>>>>> I'm Ok to return it back as it is in the CCC. >>>>>> It will save time on the CCC approval. >>>>>> >>>>>> This is the last addition to the spec: >>>>>> >>>>>> + The unnamed module is returned if the specified package does not >>>>>> exist. >>>>> >>>>> The notion of "package does not exist" is ill-defined. This case is >>>>> already covered by the primary specification. >>>>> >>>>>> + The function does not check if the specified package name is >>>>>> illegal. >>>>> >>>>> This does not need to be stated as it is not stated anywhere else for >>>>> anything else that may have legal and illegal forms. >>>> >>>> Good. >>>> This is a relevant fragment from current version of CCC: >>>> >>>> + >>>> + Return the java.lang.reflect.Module object for a >>>> module >>>> + defined to a class loader that contains a given package. >>>> + The module is returned via module_ptr. >>>> +

>>>> + If a named module is defined to the class loader and it >>>> + contains the package then that named module is returned, >>>> + otherwise the unnamed module of the class loader is returned. >>>> + If the package name is the empty string then this function >>>> + always returns the unnamed module for the class loader. >>>> +

>>> >>> As Stanislav said explicitly mentioning the empty string is not really >>> necessary - but I don't see it as harmful. >>> >>>> Does it looks Ok? >>> >>> Yes - as good now as it was in the CCC discussion :) >>> >>> Cheers, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>>>> >>>> >> From stanislav.lukyanov at oracle.com Fri Jun 24 12:10:33 2016 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Fri, 24 Jun 2016 15:10:33 +0300 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <576C6BCA.6090100@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> Message-ID: <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: > On 6/23/16 15:14, David Holmes wrote: >> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>> >>> I think it should be specified that unnamed module will be returned >>> even >>> if there cannot ever be a package >>> with that name. It is not a complicated case to specify, but it brings >>> much more clarity. >>> Formally, now the function is specified to work with "package names" >>> and >>> the behavior on a string that is clearly not a "package name" is >>> unspecified. >> >> I think it is completely specified. Something that can not be a valid >> package name can obviously not have a module associated with it and >> so the unnamed-module is always returned. > > I tend to agree with David here. > It is good that you guys having this discussion here as it is a way to > reach a consensus. > >>> Other APIs that take identifiers like, for example, JNI FindClass or >>> GetMethodID >>> don't specify name checks explicitly, but throw >>> ClassNotFoundError/NoSuchMethodError illegal names. > > The JNI does not do any check for illegal names. > If the name is illegal then the target is not found. > It is why the ClassNotFoundError/NoSuchMethodError is thrown. > It perfectly matches the current GetModuleByPackageName specification > approach. Yes, sure, there are no special checks. What I meant is that the functions do not succeed with illegal names, and because of that don't need such checks, but that's different with the GetModuleByPackageName since it does succeed. >>> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >>> succeed when an ill-formed identifier is passed, >>> so it deserves to be documented. >> >> I disagree with all of that. GetLocalVariableTable, >> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >> few, all take "names" encoded as UTF-8 modified strings. None of them >> validate that the "name" is legal for the entity being named - JVM TI >> simply does not do that kind of argument validation. > > Right. All these functions don't take the names as input from user. GetLocalVariableTable and GetThreadInfo return the names, not accept them. ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. So I see these cases as completely different. >> >> The JNI functions also do not do argument validation. The JNI spec is >> clear "The JNI does not check for programming errors such as passing >> in NULL pointers or illegal argument types". It is up to the >> programmer to ensure they pass valid arguments. FindClass is >> specified to simply throw: >> >> NoClassDefFoundError: if no definition for a requested class or >> interface can be found. >> >> It is the internal VM code, that has to deal with bytecode from >> arbitrary sources, that performs the more detailed checking of the name. > As I've said above, FindClass sure don't specify (and, probably, perform) validation, but it is important that it will always fail with an illegal argument (even if it's with NoClassDefFoundError and not something like IllegalArgumentException) >> >> GetModuleByPackageName is slightly unusual in that it really never >> fails. As I discussed in the CCC review it could have made a >> distinction between packages that would be loaded by the loader and >> packages that would not, and throw an exception (which in turn may >> have been able to discern that the name was invalid). But that is not >> the case - if you don't pass the name of a package that is known to >> the loader then you get back the unnamed-module. It doesn't matter >> whether the package name is legal-but-unknown, or illegal - it is >> just unknown. > > I tend to agree with David here. > But interested to know what objections to this can be. > My concern is that the spec doesn't give straightforward answers to how the function may be called ("Can I pass an arbitrary string, will it just return unnamed module, will I break something?") and, more importantly, implemented ("Can I only care about valid names, can I implement it in a way that doesn't consider illegal characters?"). I feel that could be clarified, but If that's just me still and you still feel that it is clear already then I think it's OK to go with the original version. BTW if the spec doesn't give special treatment to illegal names then the empty string clause should go away - if "otherwise..." clause is good enough to stand for "\t\n!@#$%^&*", it is definitely good enough to stand for "". Thanks, Stas > > Thanks, > Serguei > >> >> David >> ------ >> >>> On CCC update: AFAIU CCC needs to have final version of the proposed >>> specification, so yes, >>> it needs to be updated to with the test that will be actually pushed to >>> the workspace. >>> >>> Thanks, >>> Stas >>> >>> On 23.06.2016 14:40, David Holmes wrote: >>>> >>>> >>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> I agree with it. >>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>> legal. >>>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>>> there >>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>>> garage >>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>> >>>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>>> this >>>>>>>>>> discussion? >>>>>>>>> >>>>>>>>> I need to undo my fix for additional check. >>>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>>> two >>>>>>>>> points: >>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>> does not >>>>>>>>> exist >>>>>>>>> - the function does not check the package names for >>>>>>>>> validness and >>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>> >>>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>>> confusion. >>>>>>>> >>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>> TI. I >>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>> is not >>>>>>>> a legal package name then it will not match - end of story. >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> It was the original approach that is in the CCC. >>>>>>> You were the one who got confused here, and it convinced me that >>>>>>> this >>>>>>> needs to be more clear. >>>>>>> All these changes are because you started the discussion. :) >>>>>>> It was useful anyway. >>>>>> >>>>>> I never said anything about illegal package names. >>>>> >>>>> True. >>>>> This is my (probably, wrong) attempt to make it more clear. >>>>> >>>>>> >>>>>>> Are you against both clarifications or just the last one? >>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>> It will save time on the CCC approval. >>>>>>> >>>>>>> This is the last addition to the spec: >>>>>>> >>>>>>> + The unnamed module is returned if the specified package does not >>>>>>> exist. >>>>>> >>>>>> The notion of "package does not exist" is ill-defined. This case is >>>>>> already covered by the primary specification. >>>>>> >>>>>>> + The function does not check if the specified package name is >>>>>>> illegal. >>>>>> >>>>>> This does not need to be stated as it is not stated anywhere else >>>>>> for >>>>>> anything else that may have legal and illegal forms. >>>>> >>>>> Good. >>>>> This is a relevant fragment from current version of CCC: >>>>> >>>>> + >>>>> + Return the java.lang.reflect.Module object >>>>> for a >>>>> module >>>>> + defined to a class loader that contains a given package. >>>>> + The module is returned via module_ptr. >>>>> +

>>>>> + If a named module is defined to the class loader and it >>>>> + contains the package then that named module is returned, >>>>> + otherwise the unnamed module of the class loader is >>>>> returned. >>>>> + If the package name is the empty string then this function >>>>> + always returns the unnamed module for the class loader. >>>>> +

>>>> >>>> As Stanislav said explicitly mentioning the empty string is not really >>>> necessary - but I don't see it as harmful. >>>> >>>>> Does it looks Ok? >>>> >>>> Yes - as good now as it was in the CCC discussion :) >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Alan >>>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Fri Jun 24 12:53:32 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jun 2016 22:53:32 +1000 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> Message-ID: <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> On 24/06/2016 10:10 PM, stanislav lukyanov wrote: > > On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: >> On 6/23/16 15:14, David Holmes wrote: >>> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>>> >>>> I think it should be specified that unnamed module will be returned >>>> even >>>> if there cannot ever be a package >>>> with that name. It is not a complicated case to specify, but it brings >>>> much more clarity. >>>> Formally, now the function is specified to work with "package names" >>>> and >>>> the behavior on a string that is clearly not a "package name" is >>>> unspecified. >>> >>> I think it is completely specified. Something that can not be a valid >>> package name can obviously not have a module associated with it and >>> so the unnamed-module is always returned. >> >> I tend to agree with David here. >> It is good that you guys having this discussion here as it is a way to >> reach a consensus. >> >>>> Other APIs that take identifiers like, for example, JNI FindClass or >>>> GetMethodID >>>> don't specify name checks explicitly, but throw >>>> ClassNotFoundError/NoSuchMethodError illegal names. >> >> The JNI does not do any check for illegal names. >> If the name is illegal then the target is not found. >> It is why the ClassNotFoundError/NoSuchMethodError is thrown. >> It perfectly matches the current GetModuleByPackageName specification >> approach. > Yes, sure, there are no special checks. > What I meant is that the functions do not succeed with illegal names, > and because of that don't need such checks, but that's different with the > GetModuleByPackageName since it does succeed. It is a matter of perspective. This function simply says "if you give me a package known to this classloader I will give you its module; in all other cases I will give you the unnamed module". >>>> It looks like GetModuleByPackageName is the first JNI/JVMTI function to >>>> succeed when an ill-formed identifier is passed, >>>> so it deserves to be documented. >>> >>> I disagree with all of that. GetLocalVariableTable, >>> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >>> few, all take "names" encoded as UTF-8 modified strings. None of them >>> validate that the "name" is legal for the entity being named - JVM TI >>> simply does not do that kind of argument validation. >> >> Right. > All these functions don't take the names as input from user. > GetLocalVariableTable and GetThreadInfo return the names, not accept them. > ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. > So I see these cases as completely different. Sorry yes you are right these functions fill in structs with the name. I misread that. So there are really no JVM TI functions that take in a name. >>> >>> The JNI functions also do not do argument validation. The JNI spec is >>> clear "The JNI does not check for programming errors such as passing >>> in NULL pointers or illegal argument types". It is up to the >>> programmer to ensure they pass valid arguments. FindClass is >>> specified to simply throw: >>> >>> NoClassDefFoundError: if no definition for a requested class or >>> interface can be found. >>> >>> It is the internal VM code, that has to deal with bytecode from >>> arbitrary sources, that performs the more detailed checking of the name. >> > As I've said above, FindClass sure don't specify (and, probably, > perform) validation, but it is important that it will always fail with > an illegal argument > (even if it's with NoClassDefFoundError and not something like > IllegalArgumentException) Sure but that is just the way it operates. Look at it this way, FindClass could have been specified to operate as follows: - returns the class of the given (valid) name; else - throws NoClassDefFoundError for an unknown (but valid) class; else - throws IllegalArgumentException if the name could not be a class name but it isn't. An invalid name is a class not found - the fact the exception says "by the way that was not a valid class name" is just an incidental effect of the internal implementation. >>> >>> GetModuleByPackageName is slightly unusual in that it really never >>> fails. As I discussed in the CCC review it could have made a >>> distinction between packages that would be loaded by the loader and >>> packages that would not, and throw an exception (which in turn may >>> have been able to discern that the name was invalid). But that is not >>> the case - if you don't pass the name of a package that is known to >>> the loader then you get back the unnamed-module. It doesn't matter >>> whether the package name is legal-but-unknown, or illegal - it is >>> just unknown. >> >> I tend to agree with David here. >> But interested to know what objections to this can be. >> > My concern is that the spec doesn't give straightforward answers > to how the function may be called > ("Can I pass an arbitrary string, will it just return unnamed module, > will I break something?") > and, more importantly, implemented > ("Can I only care about valid names, can I implement it in a way that > doesn't consider illegal characters?"). > I feel that could be clarified, but If that's just me still and you > still feel that > it is clear already then I think it's OK to go with the original version. > > BTW if the spec doesn't give special treatment to illegal names > then the empty string clause should go away - if "otherwise..." clause > is good enough > to stand for "\t\n!@#$%^&*", it is definitely good enough to stand for "". I agree the "" case is already covered. David ----- > Thanks, > Stas >> >> Thanks, >> Serguei >> >>> >>> David >>> ------ >>> >>>> On CCC update: AFAIU CCC needs to have final version of the proposed >>>> specification, so yes, >>>> it needs to be updated to with the test that will be actually pushed to >>>> the workspace. >>>> >>>> Thanks, >>>> Stas >>>> >>>> On 23.06.2016 14:40, David Holmes wrote: >>>>> >>>>> >>>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> I agree with it. >>>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>>> legal. >>>>>>>>>>>> We are going to open a can of worms with this kind of check as >>>>>>>>>>>> there >>>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>>> callback so have it return the unnamed module when calling with >>>>>>>>>>> garage >>>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>>> >>>>>>>>>>> Will you update the webrev to reflect where we've got to this in >>>>>>>>>>> this >>>>>>>>>>> discussion? >>>>>>>>>> >>>>>>>>>> I need to undo my fix for additional check. >>>>>>>>>> My up-to-date understanding is that we have to explicitly specify >>>>>>>>>> two >>>>>>>>>> points: >>>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>>> does not >>>>>>>>>> exist >>>>>>>>>> - the function does not check the package names for >>>>>>>>>> validness and >>>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>>> >>>>>>>>>> It is better to specify these points explicitly to avoid possible >>>>>>>>>> confusion. >>>>>>>>> >>>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>>> TI. I >>>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>>> is not >>>>>>>>> a legal package name then it will not match - end of story. >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> It was the original approach that is in the CCC. >>>>>>>> You were the one who got confused here, and it convinced me that >>>>>>>> this >>>>>>>> needs to be more clear. >>>>>>>> All these changes are because you started the discussion. :) >>>>>>>> It was useful anyway. >>>>>>> >>>>>>> I never said anything about illegal package names. >>>>>> >>>>>> True. >>>>>> This is my (probably, wrong) attempt to make it more clear. >>>>>> >>>>>>> >>>>>>>> Are you against both clarifications or just the last one? >>>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>>> It will save time on the CCC approval. >>>>>>>> >>>>>>>> This is the last addition to the spec: >>>>>>>> >>>>>>>> + The unnamed module is returned if the specified package does not >>>>>>>> exist. >>>>>>> >>>>>>> The notion of "package does not exist" is ill-defined. This case is >>>>>>> already covered by the primary specification. >>>>>>> >>>>>>>> + The function does not check if the specified package name is >>>>>>>> illegal. >>>>>>> >>>>>>> This does not need to be stated as it is not stated anywhere else >>>>>>> for >>>>>>> anything else that may have legal and illegal forms. >>>>>> >>>>>> Good. >>>>>> This is a relevant fragment from current version of CCC: >>>>>> >>>>>> + >>>>>> + Return the java.lang.reflect.Module object >>>>>> for a >>>>>> module >>>>>> + defined to a class loader that contains a given package. >>>>>> + The module is returned via module_ptr. >>>>>> +

>>>>>> + If a named module is defined to the class loader and it >>>>>> + contains the package then that named module is returned, >>>>>> + otherwise the unnamed module of the class loader is >>>>>> returned. >>>>>> + If the package name is the empty string then this function >>>>>> + always returns the unnamed module for the class loader. >>>>>> +

>>>>> >>>>> As Stanislav said explicitly mentioning the empty string is not really >>>>> necessary - but I don't see it as harmful. >>>>> >>>>>> Does it looks Ok? >>>>> >>>>> Yes - as good now as it was in the CCC discussion :) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Alan >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From serguei.spitsyn at oracle.com Fri Jun 24 13:43:12 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Jun 2016 06:43:12 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159145 Add JVMTI function GetModuleByPackageName In-Reply-To: <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> References: <57690EBB.2010007@oracle.com> <576A7189.6040809@oracle.com> <576A8D0D.3090907@oracle.com> <9c11332a-53b0-439f-82ca-f5608d835359@oracle.com> <576AD4D3.9030002@oracle.com> <576ADAA8.8000902@oracle.com> <3497bdd1-3022-2b1f-077c-e06337114453@oracle.com> <576B1D51.10403@oracle.com> <46e39568-ae4d-0eab-a5b3-98da40fca8d5@oracle.com> <576B97FD.1080303@oracle.com> <3a1d2d55-9907-5518-e027-9116a307a5ec@oracle.com> <576BC331.8000400@oracle.com> <32634325-b80f-81fe-674e-74ba5daa41fb@oracle.com> <576BC91D.9050204@oracle.com> <95819fd5-e582-3474-a138-7dd3d8761f5e@oracle.com> <2c0bd870-25a7-7fca-36bc-6386a12902d9@oracle.com> <576C6BCA.6090100@oracle.com> <66d5e398-c221-82a7-2347-823f1f90e9fa@oracle.com> <549ba7cc-d53a-8782-db6b-054c6252c438@oracle.com> Message-ID: <576D38F0.5060403@oracle.com> Stanislav and David, Thank you for this interesting discussion! It seems, there are good points from both sides. Alan suggested to replace the GetModuleByPackageName with the GetNamedModule. The GetNamedModule should return NULL in all cases where the unnamed module was returned by the GetModuleByPackageName. It looks like this approach simplified the spec and will allow us to reach a consensus. You can find new spec in the updated CCC. I will work on the round #3 webrev and then send it for review. (Sorry that I mentioned CCC in the open but it is very inconvenient to separate it in this email thread) Please, let me know about your concerns. Thanks, Serguei On 6/24/16 05:53, David Holmes wrote: > On 24/06/2016 10:10 PM, stanislav lukyanov wrote: >> >> On 24.06.2016 2:07, serguei.spitsyn at oracle.com wrote: >>> On 6/23/16 15:14, David Holmes wrote: >>>> On 23/06/2016 11:02 PM, stanislav lukyanov wrote: >>>>> >>>>> I think it should be specified that unnamed module will be returned >>>>> even >>>>> if there cannot ever be a package >>>>> with that name. It is not a complicated case to specify, but it >>>>> brings >>>>> much more clarity. >>>>> Formally, now the function is specified to work with "package names" >>>>> and >>>>> the behavior on a string that is clearly not a "package name" is >>>>> unspecified. >>>> >>>> I think it is completely specified. Something that can not be a valid >>>> package name can obviously not have a module associated with it and >>>> so the unnamed-module is always returned. >>> >>> I tend to agree with David here. >>> It is good that you guys having this discussion here as it is a way to >>> reach a consensus. >>> >>>>> Other APIs that take identifiers like, for example, JNI FindClass or >>>>> GetMethodID >>>>> don't specify name checks explicitly, but throw >>>>> ClassNotFoundError/NoSuchMethodError illegal names. >>> >>> The JNI does not do any check for illegal names. >>> If the name is illegal then the target is not found. >>> It is why the ClassNotFoundError/NoSuchMethodError is thrown. >>> It perfectly matches the current GetModuleByPackageName specification >>> approach. >> Yes, sure, there are no special checks. >> What I meant is that the functions do not succeed with illegal names, >> and because of that don't need such checks, but that's different with >> the >> GetModuleByPackageName since it does succeed. > > It is a matter of perspective. This function simply says "if you give > me a package known to this classloader I will give you its module; in > all other cases I will give you the unnamed module". > >>>>> It looks like GetModuleByPackageName is the first JNI/JVMTI >>>>> function to >>>>> succeed when an ill-formed identifier is passed, >>>>> so it deserves to be documented. >>>> >>>> I disagree with all of that. GetLocalVariableTable, >>>> ClassFileLoadHook, DynamicCodeGenerated, GetThreadInfo, to name a >>>> few, all take "names" encoded as UTF-8 modified strings. None of them >>>> validate that the "name" is legal for the entity being named - JVM TI >>>> simply does not do that kind of argument validation. >>> >>> Right. >> All these functions don't take the names as input from user. >> GetLocalVariableTable and GetThreadInfo return the names, not accept >> them. >> ClassFileLoadHook and DynamicCodeGenerated are called by JVM, not user. >> So I see these cases as completely different. > > Sorry yes you are right these functions fill in structs with the name. > I misread that. > > So there are really no JVM TI functions that take in a name. > >>>> >>>> The JNI functions also do not do argument validation. The JNI spec is >>>> clear "The JNI does not check for programming errors such as passing >>>> in NULL pointers or illegal argument types". It is up to the >>>> programmer to ensure they pass valid arguments. FindClass is >>>> specified to simply throw: >>>> >>>> NoClassDefFoundError: if no definition for a requested class or >>>> interface can be found. >>>> >>>> It is the internal VM code, that has to deal with bytecode from >>>> arbitrary sources, that performs the more detailed checking of the >>>> name. >>> >> As I've said above, FindClass sure don't specify (and, probably, >> perform) validation, but it is important that it will always fail with >> an illegal argument >> (even if it's with NoClassDefFoundError and not something like >> IllegalArgumentException) > > Sure but that is just the way it operates. Look at it this way, > FindClass could have been specified to operate as follows: > - returns the class of the given (valid) name; else > - throws NoClassDefFoundError for an unknown (but valid) class; else > - throws IllegalArgumentException if the name could not be a class name > > but it isn't. An invalid name is a class not found - the fact the > exception says "by the way that was not a valid class name" is just an > incidental effect of the internal implementation. > >>>> >>>> GetModuleByPackageName is slightly unusual in that it really never >>>> fails. As I discussed in the CCC review it could have made a >>>> distinction between packages that would be loaded by the loader and >>>> packages that would not, and throw an exception (which in turn may >>>> have been able to discern that the name was invalid). But that is not >>>> the case - if you don't pass the name of a package that is known to >>>> the loader then you get back the unnamed-module. It doesn't matter >>>> whether the package name is legal-but-unknown, or illegal - it is >>>> just unknown. >>> >>> I tend to agree with David here. >>> But interested to know what objections to this can be. >>> >> My concern is that the spec doesn't give straightforward answers >> to how the function may be called >> ("Can I pass an arbitrary string, will it just return unnamed module, >> will I break something?") >> and, more importantly, implemented >> ("Can I only care about valid names, can I implement it in a way that >> doesn't consider illegal characters?"). >> I feel that could be clarified, but If that's just me still and you >> still feel that >> it is clear already then I think it's OK to go with the original >> version. >> >> BTW if the spec doesn't give special treatment to illegal names >> then the empty string clause should go away - if "otherwise..." clause >> is good enough >> to stand for "\t\n!@#$%^&*", it is definitely good enough to stand >> for "". > > I agree the "" case is already covered. > > David > ----- > >> Thanks, >> Stas >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ------ >>>> >>>>> On CCC update: AFAIU CCC needs to have final version of the proposed >>>>> specification, so yes, >>>>> it needs to be updated to with the test that will be actually >>>>> pushed to >>>>> the workspace. >>>>> >>>>> Thanks, >>>>> Stas >>>>> >>>>> On 23.06.2016 14:40, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 23/06/2016 9:33 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/23/16 04:27, David Holmes wrote: >>>>>>>> On 23/06/2016 9:08 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/23/16 03:51, David Holmes wrote: >>>>>>>>>> On 23/06/2016 6:04 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> On 6/23/16 00:51, Alan Bateman wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 23/06/2016 00:20, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with it. >>>>>>>>>>>>> Thank you for pointing to this JVMTI example. >>>>>>>>>>>>> I did not find in the JNI where the names are checked to be >>>>>>>>>>>>> legal. >>>>>>>>>>>>> We are going to open a can of worms with this kind of >>>>>>>>>>>>> check as >>>>>>>>>>>>> there >>>>>>>>>>>>> can be many corner cases to cover. >>>>>>>>>>>> The primary use-case for this function is from within the CLFH >>>>>>>>>>>> callback so have it return the unnamed module when calling >>>>>>>>>>>> with >>>>>>>>>>>> garage >>>>>>>>>>>> is probably okay, it just needs to be specified. >>>>>>>>>>>> >>>>>>>>>>>> Will you update the webrev to reflect where we've got to >>>>>>>>>>>> this in >>>>>>>>>>>> this >>>>>>>>>>>> discussion? >>>>>>>>>>> >>>>>>>>>>> I need to undo my fix for additional check. >>>>>>>>>>> My up-to-date understanding is that we have to explicitly >>>>>>>>>>> specify >>>>>>>>>>> two >>>>>>>>>>> points: >>>>>>>>>>> - the function returns the unnamed module if the package >>>>>>>>>>> does not >>>>>>>>>>> exist >>>>>>>>>>> - the function does not check the package names for >>>>>>>>>>> validness and >>>>>>>>>>> always returns the unnamed module for illegal package names >>>>>>>>>>> >>>>>>>>>>> It is better to specify these points explicitly to avoid >>>>>>>>>>> possible >>>>>>>>>>> confusion. >>>>>>>>>> >>>>>>>>>> I don't agree - nothing else refers to invalid "names" in JVM >>>>>>>>>> TI. I >>>>>>>>>> don't see any need to call this out here. If the name supplied >>>>>>>>>> is not >>>>>>>>>> a legal package name then it will not match - end of story. >>>>>>>>> >>>>>>>>> David, >>>>>>>>> >>>>>>>>> It was the original approach that is in the CCC. >>>>>>>>> You were the one who got confused here, and it convinced me that >>>>>>>>> this >>>>>>>>> needs to be more clear. >>>>>>>>> All these changes are because you started the discussion. :) >>>>>>>>> It was useful anyway. >>>>>>>> >>>>>>>> I never said anything about illegal package names. >>>>>>> >>>>>>> True. >>>>>>> This is my (probably, wrong) attempt to make it more clear. >>>>>>> >>>>>>>> >>>>>>>>> Are you against both clarifications or just the last one? >>>>>>>>> I'm Ok to return it back as it is in the CCC. >>>>>>>>> It will save time on the CCC approval. >>>>>>>>> >>>>>>>>> This is the last addition to the spec: >>>>>>>>> >>>>>>>>> + The unnamed module is returned if the specified package does >>>>>>>>> not >>>>>>>>> exist. >>>>>>>> >>>>>>>> The notion of "package does not exist" is ill-defined. This >>>>>>>> case is >>>>>>>> already covered by the primary specification. >>>>>>>> >>>>>>>>> + The function does not check if the specified package name is >>>>>>>>> illegal. >>>>>>>> >>>>>>>> This does not need to be stated as it is not stated anywhere else >>>>>>>> for >>>>>>>> anything else that may have legal and illegal forms. >>>>>>> >>>>>>> Good. >>>>>>> This is a relevant fragment from current version of CCC: >>>>>>> >>>>>>> + >>>>>>> + Return the java.lang.reflect.Module object >>>>>>> for a >>>>>>> module >>>>>>> + defined to a class loader that contains a given package. >>>>>>> + The module is returned via module_ptr. >>>>>>> +

>>>>>>> + If a named module is defined to the class loader and it >>>>>>> + contains the package then that named module is returned, >>>>>>> + otherwise the unnamed module of the class loader is >>>>>>> returned. >>>>>>> + If the package name is the empty string then this function >>>>>>> + always returns the unnamed module for the class loader. >>>>>>> +

>>>>>> >>>>>> As Stanislav said explicitly mentioning the empty string is not >>>>>> really >>>>>> necessary - but I don't see it as harmful. >>>>>> >>>>>>> Does it looks Ok? >>>>>> >>>>>> Yes - as good now as it was in the CCC discussion :) >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Alan >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> From mandy.chung at oracle.com Tue Jun 28 00:16:39 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 27 Jun 2016 17:16:39 -0700 Subject: CFV: New Serviceability Group Member: Staffan Larsen In-Reply-To: <0d0462aa-fac0-06fe-019f-1722fb5bcd3d@oracle.com> References: <0d0462aa-fac0-06fe-019f-1722fb5bcd3d@oracle.com> Message-ID: <4BAE3261-4B26-48A5-B015-418B217ECA06@oracle.com> Vote: yes Mandy From tim.bell at oracle.com Tue Jun 28 00:46:38 2016 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 Jun 2016 17:46:38 -0700 Subject: CFV: New Serviceability Group Member: Staffan Larsen In-Reply-To: <4BAE3261-4B26-48A5-B015-418B217ECA06@oracle.com> References: <0d0462aa-fac0-06fe-019f-1722fb5bcd3d@oracle.com> <4BAE3261-4B26-48A5-B015-418B217ECA06@oracle.com> Message-ID: <5771C8EE.7040504@oracle.com> Vote: yes > I hereby nominate Staffan Larsen to Membership in the Serviceability Group. Tim From robert.field at oracle.com Tue Jun 28 02:15:37 2016 From: robert.field at oracle.com (Robert Field) Date: Mon, 27 Jun 2016 19:15:37 -0700 Subject: CFV: New Serviceability Group Member: Staffan Larsen In-Reply-To: References: Message-ID: <5771DDC9.2010606@oracle.com> Vote: yes Robert On 06/17/16 16:22, Daniel D. Daugherty wrote: > I hereby nominate Staffan Larsen to Membership in the Serviceability > Group. > > Staffan is a Reviewer in the jdk9 and jdk8u Projects, a member of the > Serviceability team, and has so far committed > 145 changesets. He is the > Serviceability architect since 2011, has been working on HotSpot for > more than five years. Before joining the HotSpot team he worked with > the JRockit JVM from 1999. > > Votes are due by 18:00, Fri, July 1, 2016 PDT. > > Only current Members of the Serviceability Group [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Daniel Daugherty > > [1] http://openjdk.java.net/census#serviceability > [2] http://openjdk.java.net/groups/#member-vote > From serguei.spitsyn at oracle.com Tue Jun 28 04:08:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Jun 2016 21:08:20 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule Message-ID: <5771F834.2020504@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 The Hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ The Jdk webrev is the same: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Summary: This is the review round #3. Alan suggested to replace the function GetModuleByPackageName with the GetNamedModule. New function will return NULL if the package is not in a module defined to the class loader. It simplifies the API and makes it easier to specify. JVM TI agents that instrument code in named modules need the Module at class load time. One question that came from the function semantics change. I had to implement the Modules::get_named_module() from scratch independently of the existing Modules::get_module_by_package_name() and Modules::get_module(). The issue is that the Modules::get_module() can return the unnamed module whereas the JVMTI helper Modules::get_named_module() should return NULL instead of the unnamed module. Please, let me know if it is Ok or if you have better ideas how to share the code. This is the Summary from review round #1: One way to do this is by introducing a new ClassFileLoadHook that takes an additional parameter but this approach is disruptive. The alternative option is a JVM TI function that maps a classloader + package name to a module. We were initially not confident with this approach so we introduced it as JVM function JVM_GetModuleByPackageName. Based on experience to date then this approach seems okay and so this function needs to be promoted to a JVMTI function. It includes new jtreg test with native JVMTI agent. Testing: Run newly developed jtreg test. Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 28 04:20:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Jun 2016 21:20:41 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771F834.2020504@oracle.com> References: <5771F834.2020504@oracle.com> Message-ID: <5771FB19.20009@oracle.com> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > > > The Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ > > > The Jdk webrev is the same: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ Sorry, the Jdk webrev changed as well: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ Thanks, Serguei > > > Summary: > > This is the review round #3. > Alan suggested to replace the function GetModuleByPackageName with > the GetNamedModule. > New function will return NULL if the package is not in a module > defined to the class loader. > It simplifies the API and makes it easier to specify. > JVM TI agents that instrument code in named modules need the Module at > class load time. > > One question that came from the function semantics change. > I had to implement the Modules::get_named_module() from scratch > independently of the existing > Modules::get_module_by_package_name() and Modules::get_module(). > The issue is that the Modules::get_module() can return the unnamed > module whereas the > JVMTI helper Modules::get_named_module() should return NULL instead > of the unnamed module. > Please, let me know if it is Ok or if you have better ideas how to > share the code. > > This is the Summary from review round #1: > > One way to do this is by introducing a new ClassFileLoadHook that > takes an additional parameter but this approach is disruptive. > The alternative option is a JVM TI function that maps a classloader > + package name to a module. > We were initially not confident with this approach so we introduced > it as JVM function JVM_GetModuleByPackageName. > Based on experience to date then this approach seems okay and so > this function needs to be promoted to a JVMTI function. > > It includes new jtreg test with native JVMTI agent. > > > Testing: > Run newly developed jtreg test. > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Jun 28 05:06:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jun 2016 15:06:03 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771FB19.20009@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> Message-ID: <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> Hi Serguei, Overall this looks a lot clearer/simpler. On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: > On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ Are there intended to be other callers of Module::get_named_module? If not it seems odd to go to all the trouble of throwing exceptions, just to have the caller clear them and return an error code. Or you could move all that argument checking code into the JVMTI function directly - if called internally you would just assert that arguments are as expected. src/share/vm/prims/jvmti.xml + otherwise the NULL is returned. Delete "the". Otherwise all looks good to me. >> >> >> The Jdk webrev is the same: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ > > Sorry, the Jdk webrev changed as well: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ Looks fine. Thanks, David > > Thanks, > Serguei > > >> >> >> Summary: >> >> This is the review round #3. >> Alan suggested to replace the function GetModuleByPackageName with >> the GetNamedModule. >> New function will return NULL if the package is not in a module >> defined to the class loader. >> It simplifies the API and makes it easier to specify. >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One question that came from the function semantics change. >> I had to implement the Modules::get_named_module() from scratch >> independently of the existing >> Modules::get_module_by_package_name() and Modules::get_module(). >> The issue is that the Modules::get_module() can return the unnamed >> module whereas the >> JVMTI helper Modules::get_named_module() should return NULL instead >> of the unnamed module. >> Please, let me know if it is Ok or if you have better ideas how to >> share the code. >> >> This is the Summary from review round #1: >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> It includes new jtreg test with native JVMTI agent. >> >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Tue Jun 28 08:54:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 01:54:47 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> Message-ID: <57723B57.2010605@oracle.com> Hi David, Thank you for the comments! I agree with you. Updated Hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ Thanks, Serguei On 6/27/16 22:06, David Holmes wrote: > Hi Serguei, > > Overall this looks a lot clearer/simpler. > > On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>> > > Are there intended to be other callers of Module::get_named_module? If > not it seems odd to go to all the trouble of throwing exceptions, just > to have the caller clear them and return an error code. Or you could > move all that argument checking code into the JVMTI function directly > - if called internally you would just assert that arguments are as > expected. > > > src/share/vm/prims/jvmti.xml > > + otherwise the NULL is returned. > > Delete "the". > > Otherwise all looks good to me. > >>> >>> >>> The Jdk webrev is the same: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >> >> Sorry, the Jdk webrev changed as well: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >> > > Looks fine. > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> >>> Summary: >>> >>> This is the review round #3. >>> Alan suggested to replace the function GetModuleByPackageName with >>> the GetNamedModule. >>> New function will return NULL if the package is not in a module >>> defined to the class loader. >>> It simplifies the API and makes it easier to specify. >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One question that came from the function semantics change. >>> I had to implement the Modules::get_named_module() from scratch >>> independently of the existing >>> Modules::get_module_by_package_name() and Modules::get_module(). >>> The issue is that the Modules::get_module() can return the unnamed >>> module whereas the >>> JVMTI helper Modules::get_named_module() should return NULL instead >>> of the unnamed module. >>> Please, let me know if it is Ok or if you have better ideas how to >>> share the code. >>> >>> This is the Summary from review round #1: >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a classloader >>> + package name to a module. >>> We were initially not confident with this approach so we introduced >>> it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> It includes new jtreg test with native JVMTI agent. >>> >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> From yasuenag at gmail.com Tue Jun 28 09:29:55 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 18:29:55 +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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: PING: Could you review and sponsor it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ I've requested FC extension for this. Thanks, Yasumasa On 2016/06/13 13:24, David Holmes wrote: > Hi Yasumasa, > > On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for your comment. >> >>> So options are a distinct property of outputs and so should have been >>> a first class entity in LogOutput all along. >> >> I agree to you. >> But I think we need to discuss about it with logging folks. >> >> I uploaded a new webrev. It removes fixed buffer length and changes the >> order of output. >> Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ > > It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. > > Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? > > Lets wait for other feedback before going further. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 9:05, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> I think "config_string" is different from "option_string". >>>> >>>> -Xlog format (from -Xlog:help message): >>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>> >>>> config_string: "what" (ex. gc=trace) >>>> option_string: "output-options" (ex. filecount=5) >>>> >>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>> It does not contain output options. >>> >>> Okay I'm starting to see the bigger picture here. In terms of the >>> overall logging configuration we might have, for example: >>> >>> gc=trace -> stdout >>> runtime=info -> fileA >>> compiler=trace -> fileB >>> >>> where the LHS is (part of) the configuration, and the RHS is the >>> output. So for each output we set its "configuration" to the >>> associated LHS. >>> >>> So options are a distinct property of outputs and so should have been >>> a first class entity in LogOutput all along. >>> >>> Okay so looking at your v4 I have two comments: >>> >>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>> are so don't know if 100 is adequate. >>> >>> Second, if the logging syntax is: >>> >>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>> >>> then shouldn't the configuration be printed in the same order/format? >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/13 8:14, David Holmes wrote: >>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for your comment. >>>>>> >>>>>>> Is there some reason the option string could not simply become >>>>>>> part of >>>>>>> the existing configuration string? >>>>>> >>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>> (See webrev.01). >>>>>> Marcus commented that option string should be generated from current >>>>>> configuration. >>>>>> >>>>>> I uploaded new webrev. >>>>>> Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>> >>>>> Sorry but I repeat my question - why is the option information not >>>>> simply part of the config_string? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>> actually needs to implement. >>>>>>> >>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>> - we >>>>>>> have getters for all the other "properties" which are then printed by >>>>>>> the describe_current_configuration method. But this is instead a >>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>> two styles seems messy. It probably would have been better to have >>>>>>> had >>>>>>> a print-style API from the start - then adding the options would have >>>>>>> been a trivial extension for those output classes with options. >>>>>>> >>>>>>> In addition the change you made to describe_current_configuration is >>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>> the config string and the decorators) for this one class and so you >>>>>>> added the code to support that format. But that format may not make >>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>> >>>>>>> Is there some reason the option string could not simply become >>>>>>> part of >>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>> these "options" really are part of the configuration. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>> "2015, 2016,". >>>>>>> >>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review it? >>>>>>>> We need a second reviewer. >>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>> >>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>> FileLogOutput configuration. >>>>>>>> So I want to merge it to jdk 9. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>> 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 serguei.spitsyn at oracle.com Tue Jun 28 11:06:04 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 04:06:04 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method Message-ID: <57725A1C.7060404@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159147 Jdk webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ Summary: As noted in JDK-8155207 and elsewhere, one of the outstanding items for java.lang.instrument is whether the new ClassFileTransformer transform method should provider the ClassLoader parameter. After further consideration then this seems useful and avoids agents needing permissions to invoke Module::getClassLoader. The fix is to add the ClassLoader as the second parameter of the ClassFileTransformer#transform() method. This fix also replaces the usage of the JVM_GetModuleByPackageName with the JVMTI GetNamedModule in the JPLISAgent.c. It is why this fix depends on the fix of the JVMTI enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 and so, must be pushed after the JDK-8159145. Testing: Ran the Jtreg java/lang/instrument tests. Ran two updated jtreg j.l.i tests: java/lang/instrument/RetransformAgent.java java/lang/instrument/SingleTransformerTest.java Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Tue Jun 28 11:23:36 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 28 Jun 2016 13:23:36 +0200 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> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> Message-ID: <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> Hi, On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. Thanks, Marcus > > I've requested FC extension for this. > > > Thanks, > > Yasumasa > > > On 2016/06/13 13:24, David Holmes wrote: >> Hi Yasumasa, >> >> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> Thank you for your comment. >>> >>>> So options are a distinct property of outputs and so should have been >>>> a first class entity in LogOutput all along. >>> >>> I agree to you. >>> But I think we need to discuss about it with logging folks. >>> >>> I uploaded a new webrev. It removes fixed buffer length and changes the >>> order of output. >>> Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >> >> It's okay to wait and hear what opinions others may have before >> changing things based on my comments. :) The fixed buffer may be okay >> - as I said I don't know what the potential options are, so don't >> know if it is okay or not. >> >> Using dynamic allocation avoids that but raises other concerns - like >> calling vm_exit_on_out_of_memory on failure; or whether to use malloc >> or resource area? >> >> Lets wait for other feedback before going further. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/13 9:05, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> I think "config_string" is different from "option_string". >>>>> >>>>> -Xlog format (from -Xlog:help message): >>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>> >>>>> config_string: "what" (ex. gc=trace) >>>>> option_string: "output-options" (ex. filecount=5) >>>>> >>>>> Currently, LogOutput handles tags and loglevels only as >>>>> config_string. >>>>> It does not contain output options. >>>> >>>> Okay I'm starting to see the bigger picture here. In terms of the >>>> overall logging configuration we might have, for example: >>>> >>>> gc=trace -> stdout >>>> runtime=info -> fileA >>>> compiler=trace -> fileB >>>> >>>> where the LHS is (part of) the configuration, and the RHS is the >>>> output. So for each output we set its "configuration" to the >>>> associated LHS. >>>> >>>> So options are a distinct property of outputs and so should have been >>>> a first class entity in LogOutput all along. >>>> >>>> Okay so looking at your v4 I have two comments: >>>> >>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>>> are so don't know if 100 is adequate. >>>> >>>> Second, if the logging syntax is: >>>> >>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>> >>>> then shouldn't the configuration be printed in the same order/format? >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for your comment. >>>>>>> >>>>>>>> Is there some reason the option string could not simply become >>>>>>>> part of >>>>>>>> the existing configuration string? >>>>>>> >>>>>>> My first proposal keeps option string at LogOutput and its child >>>>>>> class >>>>>>> (See webrev.01). >>>>>>> Marcus commented that option string should be generated from >>>>>>> current >>>>>>> configuration. >>>>>>> >>>>>>> I uploaded new webrev. >>>>>>> Could you review again? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>> >>>>>> Sorry but I repeat my question - why is the option information not >>>>>> simply part of the config_string? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>> print_option_string seems the wrong name given that the base >>>>>>>> class, >>>>>>>> LogOutput, has no notion of having an "option string". It seems >>>>>>>> to be >>>>>>>> a supposedly generic "print other stuff" function that only one >>>>>>>> class >>>>>>>> actually needs to implement. >>>>>>>> >>>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>>> - we >>>>>>>> have getters for all the other "properties" which are then >>>>>>>> printed by >>>>>>>> the describe_current_configuration method. But this is instead a >>>>>>>> "print" function where we ask the target to print itself. >>>>>>>> Mixing the >>>>>>>> two styles seems messy. It probably would have been better to have >>>>>>>> had >>>>>>>> a print-style API from the start - then adding the options >>>>>>>> would have >>>>>>>> been a trivial extension for those output classes with options. >>>>>>>> >>>>>>>> In addition the change you made to >>>>>>>> describe_current_configuration is >>>>>>>> not at all general purpose - you wanted a given format (print >>>>>>>> between >>>>>>>> the config string and the decorators) for this one class and so >>>>>>>> you >>>>>>>> added the code to support that format. But that format may not >>>>>>>> make >>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>> >>>>>>>> Is there some reason the option string could not simply become >>>>>>>> part of >>>>>>>> the existing configuration string? It seems to me that for a >>>>>>>> LogFile >>>>>>>> these "options" really are part of the configuration. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>>> "2015, 2016,". >>>>>>>> >>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review it? >>>>>>>>> We need a second reviewer. >>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>> >>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>> FileLogOutput configuration. >>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>> 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 yasuenag at gmail.com Tue Jun 28 13:21:14 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 Jun 2016 22:21:14 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> References: <56FBDE2F.60701@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> Message-ID: <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> Hi Marcus, > I don't really like that we need to make dynamic allocations here. Should use resource area? or char array? If we should use char array, how long should we reserve for buffer? > Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. I think this is refactoring of LogOutput and LogConfiguration. Now (after FC date), is this work accepted? IMHO, refactoring is another enhancement from this. If it is needed, I think this enhancement should be started after refactoring. If refactoring and this enhancement can be merged and be accepted, I will start to work for it. Thanks, Yasumasa On 2016/06/28 20:23, Marcus Larsson wrote: > Hi, > > > On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ > > I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. > > Thanks, > Marcus > >> >> I've requested FC extension for this. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/13 13:24, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> Thank you for your comment. >>>> >>>>> So options are a distinct property of outputs and so should have been >>>>> a first class entity in LogOutput all along. >>>> >>>> I agree to you. >>>> But I think we need to discuss about it with logging folks. >>>> >>>> I uploaded a new webrev. It removes fixed buffer length and changes the >>>> order of output. >>>> Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>> >>> It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. >>> >>> Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? >>> >>> Lets wait for other feedback before going further. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/13 9:05, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> I think "config_string" is different from "option_string". >>>>>> >>>>>> -Xlog format (from -Xlog:help message): >>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>> >>>>>> config_string: "what" (ex. gc=trace) >>>>>> option_string: "output-options" (ex. filecount=5) >>>>>> >>>>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>>>> It does not contain output options. >>>>> >>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>> overall logging configuration we might have, for example: >>>>> >>>>> gc=trace -> stdout >>>>> runtime=info -> fileA >>>>> compiler=trace -> fileB >>>>> >>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>> output. So for each output we set its "configuration" to the >>>>> associated LHS. >>>>> >>>>> So options are a distinct property of outputs and so should have been >>>>> a first class entity in LogOutput all along. >>>>> >>>>> Okay so looking at your v4 I have two comments: >>>>> >>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>>>> are so don't know if 100 is adequate. >>>>> >>>>> Second, if the logging syntax is: >>>>> >>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>> >>>>> then shouldn't the configuration be printed in the same order/format? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for your comment. >>>>>>>> >>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>> part of >>>>>>>>> the existing configuration string? >>>>>>>> >>>>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>>>> (See webrev.01). >>>>>>>> Marcus commented that option string should be generated from current >>>>>>>> configuration. >>>>>>>> >>>>>>>> I uploaded new webrev. >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>> >>>>>>> Sorry but I repeat my question - why is the option information not >>>>>>> simply part of the config_string? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>>>> actually needs to implement. >>>>>>>>> >>>>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>>>> - we >>>>>>>>> have getters for all the other "properties" which are then printed by >>>>>>>>> the describe_current_configuration method. But this is instead a >>>>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>>>> two styles seems messy. It probably would have been better to have >>>>>>>>> had >>>>>>>>> a print-style API from the start - then adding the options would have >>>>>>>>> been a trivial extension for those output classes with options. >>>>>>>>> >>>>>>>>> In addition the change you made to describe_current_configuration is >>>>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>>>> the config string and the decorators) for this one class and so you >>>>>>>>> added the code to support that format. But that format may not make >>>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>>> >>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>> part of >>>>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>>>> these "options" really are part of the configuration. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>>>> "2015, 2016,". >>>>>>>>> >>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review it? >>>>>>>>>> We need a second reviewer. >>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>> >>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>> FileLogOutput configuration. >>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>> 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 harold.seigel at oracle.com Tue Jun 28 14:32:39 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Jun 2016 10:32:39 -0400 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57723B57.2010605@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> Message-ID: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Hi Serguei, Looks good. 1. In modules.cpp, the first assert in get_named_module() has the wrong function name: 825 assert(ModuleEntryTable::javabase_defined(), 826 "Attempt to call *get_module_by_package_name* before java.base is defined"); 2. Also, is a check needed to ensure that package_str is not null? 3. Is the ResourceMark(THREAD) needed at line 824? Thanks, Harold On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for the comments! > I agree with you. > > Updated Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ > > > > Thanks, > Serguei > > > > On 6/27/16 22:06, David Holmes wrote: >> Hi Serguei, >> >> Overall this looks a lot clearer/simpler. >> >> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>> >>>> >>>> The Hotspot webrev: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>> >> >> Are there intended to be other callers of Module::get_named_module? >> If not it seems odd to go to all the trouble of throwing exceptions, >> just to have the caller clear them and return an error code. Or you >> could move all that argument checking code into the JVMTI function >> directly - if called internally you would just assert that arguments >> are as expected. >> >> >> src/share/vm/prims/jvmti.xml >> >> + otherwise the NULL is returned. >> >> Delete "the". >> >> Otherwise all looks good to me. >> >>>> >>>> >>>> The Jdk webrev is the same: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>> >>> >>> Sorry, the Jdk webrev changed as well: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>> >> >> Looks fine. >> >> Thanks, >> David >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Summary: >>>> >>>> This is the review round #3. >>>> Alan suggested to replace the function GetModuleByPackageName with >>>> the GetNamedModule. >>>> New function will return NULL if the package is not in a module >>>> defined to the class loader. >>>> It simplifies the API and makes it easier to specify. >>>> JVM TI agents that instrument code in named modules need the Module >>>> at class load time. >>>> >>>> One question that came from the function semantics change. >>>> I had to implement the Modules::get_named_module() from scratch >>>> independently of the existing >>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>> The issue is that the Modules::get_module() can return the unnamed >>>> module whereas the >>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>> of the unnamed module. >>>> Please, let me know if it is Ok or if you have better ideas how to >>>> share the code. >>>> >>>> This is the Summary from review round #1: >>>> >>>> One way to do this is by introducing a new ClassFileLoadHook that >>>> takes an additional parameter but this approach is disruptive. >>>> The alternative option is a JVM TI function that maps a classloader >>>> + package name to a module. >>>> We were initially not confident with this approach so we introduced >>>> it as JVM function JVM_GetModuleByPackageName. >>>> Based on experience to date then this approach seems okay and so >>>> this function needs to be promoted to a JVMTI function. >>>> >>>> It includes new jtreg test with native JVMTI agent. >>>> >>>> >>>> Testing: >>>> Run newly developed jtreg test. >>>> >>>> Thanks, >>>> Serguei >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 28 14:59:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 07:59:39 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Message-ID: <577290DB.5010902@oracle.com> Hi Harold, On 6/28/16 07:32, harold seigel wrote: > > Hi Serguei, > > Looks good. > Thank you for reviewing! > 1. In modules.cpp, the first assert in get_named_module() has the > wrong function name: > > 825 assert(ModuleEntryTable::javabase_defined(), > 826 "Attempt to call *get_module_by_package_name* before java.base is > defined"); Nice catch. Will fix. > > 2. Also, is a check needed to ensure that package_str is not null? The only caller the JVMTI function does this check for both loader and package_str. Maybe worth to add an assert? > > 3. Is the ResourceMark(THREAD) needed at line 824? Does the SymbolTable::new_symbol() needs it? The caller has its own ResourceMark as well. Do you recommend to get rid of it? Thanks, Serguei > > Thanks, Harold > > On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the comments! >> I agree with you. >> >> Updated Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >> >> >> >> Thanks, >> Serguei >> >> >> >> On 6/27/16 22:06, David Holmes wrote: >>> Hi Serguei, >>> >>> Overall this looks a lot clearer/simpler. >>> >>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>> >>> >>> Are there intended to be other callers of Module::get_named_module? >>> If not it seems odd to go to all the trouble of throwing exceptions, >>> just to have the caller clear them and return an error code. Or you >>> could move all that argument checking code into the JVMTI function >>> directly - if called internally you would just assert that arguments >>> are as expected. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> >>> + otherwise the NULL is returned. >>> >>> Delete "the". >>> >>> Otherwise all looks good to me. >>> >>>>> >>>>> >>>>> The Jdk webrev is the same: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>> >>>> Sorry, the Jdk webrev changed as well: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>> >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the review round #3. >>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>> the GetNamedModule. >>>>> New function will return NULL if the package is not in a module >>>>> defined to the class loader. >>>>> It simplifies the API and makes it easier to specify. >>>>> JVM TI agents that instrument code in named modules need the Module >>>>> at class load time. >>>>> >>>>> One question that came from the function semantics change. >>>>> I had to implement the Modules::get_named_module() from scratch >>>>> independently of the existing >>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>> The issue is that the Modules::get_module() can return the unnamed >>>>> module whereas the >>>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>>> of the unnamed module. >>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>> share the code. >>>>> >>>>> This is the Summary from review round #1: >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a classloader >>>>> + package name to a module. >>>>> We were initially not confident with this approach so we introduced >>>>> it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arvind.aprameya at oracle.com Tue Jun 28 16:15:31 2016 From: arvind.aprameya at oracle.com (Arvind Aprameya) Date: Tue, 28 Jun 2016 09:15:31 -0700 (PDT) Subject: Serviceability Agent tools / API usage . Message-ID: Hello Everyone, Writing to this group to understand the following aspects related to Serviceability Agent tools / API's. . Have you been using Serviceability Agent related API's or tools for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? . If the answer for the above question was yes, a very brief explanation of what area's in your project have you been using ? . Do you believe the current capabilities of SA are helpful / important ? . Areas of improvement you would like to see / make in future ? Please share your responses as replies to this thread on the serviceability-dev list or to me directly until 12th July 2016. Thanks for your time in advance . thanks & regards, Arvind -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 28 16:37:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 09:37:31 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> Message-ID: <5772A7CB.6070007@oracle.com> Hi Harold, Thank you again for the comments! This is the updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ Thanks, Serguei On 6/28/16 07:32, harold seigel wrote: > > Hi Serguei, > > Looks good. > > 1. In modules.cpp, the first assert in get_named_module() has the > wrong function name: > > 825 assert(ModuleEntryTable::javabase_defined(), > 826 "Attempt to call *get_module_by_package_name* before java.base is > defined"); > > 2. Also, is a check needed to ensure that package_str is not null? > > 3. Is the ResourceMark(THREAD) needed at line 824? > > Thanks, Harold > > On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for the comments! >> I agree with you. >> >> Updated Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >> >> >> >> Thanks, >> Serguei >> >> >> >> On 6/27/16 22:06, David Holmes wrote: >>> Hi Serguei, >>> >>> Overall this looks a lot clearer/simpler. >>> >>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>> >>>>> >>>>> The Hotspot webrev: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>> >>> >>> Are there intended to be other callers of Module::get_named_module? >>> If not it seems odd to go to all the trouble of throwing exceptions, >>> just to have the caller clear them and return an error code. Or you >>> could move all that argument checking code into the JVMTI function >>> directly - if called internally you would just assert that arguments >>> are as expected. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> >>> + otherwise the NULL is returned. >>> >>> Delete "the". >>> >>> Otherwise all looks good to me. >>> >>>>> >>>>> >>>>> The Jdk webrev is the same: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>> >>>> >>>> Sorry, the Jdk webrev changed as well: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>> >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is the review round #3. >>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>> the GetNamedModule. >>>>> New function will return NULL if the package is not in a module >>>>> defined to the class loader. >>>>> It simplifies the API and makes it easier to specify. >>>>> JVM TI agents that instrument code in named modules need the Module >>>>> at class load time. >>>>> >>>>> One question that came from the function semantics change. >>>>> I had to implement the Modules::get_named_module() from scratch >>>>> independently of the existing >>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>> The issue is that the Modules::get_module() can return the unnamed >>>>> module whereas the >>>>> JVMTI helper Modules::get_named_module() should return NULL instead >>>>> of the unnamed module. >>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>> share the code. >>>>> >>>>> This is the Summary from review round #1: >>>>> >>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>> takes an additional parameter but this approach is disruptive. >>>>> The alternative option is a JVM TI function that maps a classloader >>>>> + package name to a module. >>>>> We were initially not confident with this approach so we introduced >>>>> it as JVM function JVM_GetModuleByPackageName. >>>>> Based on experience to date then this approach seems okay and so >>>>> this function needs to be promoted to a JVMTI function. >>>>> >>>>> It includes new jtreg test with native JVMTI agent. >>>>> >>>>> >>>>> Testing: >>>>> Run newly developed jtreg test. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Jun 28 17:24:25 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 11:24:25 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5771FB19.20009@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> Message-ID: <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> On 6/27/16 10:20 PM, serguei.spitsyn at oracle.com wrote: > On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> >> >> The Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >> >> >> >> The Jdk webrev is the same: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >> > > Sorry, the Jdk webrev changed as well: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ > ' src/java.base/share/native/include/jvmti.h No comments. Thumbs up on the 'jdk' repo change. Dan > > > Thanks, > Serguei > > >> >> >> Summary: >> >> This is the review round #3. >> Alan suggested to replace the function GetModuleByPackageName with >> the GetNamedModule. >> New function will return NULL if the package is not in a module >> defined to the class loader. >> It simplifies the API and makes it easier to specify. >> JVM TI agents that instrument code in named modules need the Module >> at class load time. >> >> One question that came from the function semantics change. >> I had to implement the Modules::get_named_module() from scratch >> independently of the existing >> Modules::get_module_by_package_name() and Modules::get_module(). >> The issue is that the Modules::get_module() can return the unnamed >> module whereas the >> JVMTI helper Modules::get_named_module() should return NULL instead >> of the unnamed module. >> Please, let me know if it is Ok or if you have better ideas how to >> share the code. >> >> This is the Summary from review round #1: >> >> One way to do this is by introducing a new ClassFileLoadHook that >> takes an additional parameter but this approach is disruptive. >> The alternative option is a JVM TI function that maps a classloader >> + package name to a module. >> We were initially not confident with this approach so we introduced >> it as JVM function JVM_GetModuleByPackageName. >> Based on experience to date then this approach seems okay and so >> this function needs to be promoted to a JVMTI function. >> >> It includes new jtreg test with native JVMTI agent. >> >> >> Testing: >> Run newly developed jtreg test. >> >> Thanks, >> Serguei > From harold.seigel at oracle.com Tue Jun 28 17:45:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Jun 2016 13:45:53 -0400 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772A7CB.6070007@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: Hi Serguei, It looks good! Thanks, Harold On 6/28/2016 12:37 PM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > Thank you again for the comments! > This is the updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ > > Thanks, > Serguei > > > On 6/28/16 07:32, harold seigel wrote: >> >> Hi Serguei, >> >> Looks good. >> >> 1. In modules.cpp, the first assert in get_named_module() has the >> wrong function name: >> >> 825 assert(ModuleEntryTable::javabase_defined(), >> 826 "Attempt to call *get_module_by_package_name* before java.base is >> defined"); >> >> 2. Also, is a check needed to ensure that package_str is not null? >> >> 3. Is the ResourceMark(THREAD) needed at line 824? >> >> Thanks, Harold >> >> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the comments! >>> I agree with you. >>> >>> Updated Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/27/16 22:06, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Overall this looks a lot clearer/simpler. >>>> >>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>> >>>>>> >>>>>> The Hotspot webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>> >>>> >>>> Are there intended to be other callers of Module::get_named_module? >>>> If not it seems odd to go to all the trouble of throwing >>>> exceptions, just to have the caller clear them and return an error >>>> code. Or you could move all that argument checking code into the >>>> JVMTI function directly - if called internally you would just >>>> assert that arguments are as expected. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> >>>> + otherwise the NULL is returned. >>>> >>>> Delete "the". >>>> >>>> Otherwise all looks good to me. >>>> >>>>>> >>>>>> >>>>>> The Jdk webrev is the same: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>> >>>>> >>>>> Sorry, the Jdk webrev changed as well: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>> >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the review round #3. >>>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>>> the GetNamedModule. >>>>>> New function will return NULL if the package is not in a module >>>>>> defined to the class loader. >>>>>> It simplifies the API and makes it easier to specify. >>>>>> JVM TI agents that instrument code in named modules need the >>>>>> Module >>>>>> at class load time. >>>>>> >>>>>> One question that came from the function semantics change. >>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>> independently of the existing >>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>> The issue is that the Modules::get_module() can return the unnamed >>>>>> module whereas the >>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>> instead >>>>>> of the unnamed module. >>>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>>> share the code. >>>>>> >>>>>> This is the Summary from review round #1: >>>>>> >>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>> takes an additional parameter but this approach is disruptive. >>>>>> The alternative option is a JVM TI function that maps a >>>>>> classloader >>>>>> + package name to a module. >>>>>> We were initially not confident with this approach so we >>>>>> introduced >>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>> Based on experience to date then this approach seems okay and so >>>>>> this function needs to be promoted to a JVMTI function. >>>>>> >>>>>> It includes new jtreg test with native JVMTI agent. >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run newly developed jtreg test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Jun 28 18:19:51 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 12:19:51 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772A7CB.6070007@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > Thank you again for the comments! > This is the updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ > make/test/JtregNative.gmk No comments. src/share/vm/classfile/modules.hpp No comments. src/share/vm/classfile/modules.cpp L826: assert(h_loader.is_null() || java_lang_ClassLoader::is_subclass(h_loader->klass()), L827: "Class loader is not a subclass of java.lang.ClassLoader"); nit: indent on L827 is off by 1 space I'll have to check the upper layers of this API, but if an agent can pass a bad 'class_loader' parameter and get this assert() to fire, then that's not good. Hopefully a bad 'class_loader' parameter is caught at a higher layer. Update: Yes, passing a non-NULL jobject as the class_loader parameter when the jobject does not refer to a "class loader" is caught at the upper layer. L828: assert(package_str != NULL, "the package_str should not be NULL"); Same concern about the package_str parameter. Update: Yes, the generated JVM/TI glue code should catch a NULL package_name/package_str at the upper layers. src/share/vm/prims/jvmti.xml L6550: L6551: L6552: L6553: On return, points to a java.lang.reflect.Module object. L6554: L6555: The above wording doesn't allow for module_ptr to be NULL which is a mismatch with the description. L2518: function can be used to map class loader and package name to a module. Typo: 'map class loader and package name' -> 'map a class loader and a package name' src/share/vm/prims/jvmtiEnv.cpp L204: // class_loader - NULL is a valid value, must be pre-checked L205: // package_name - pre-checked for NULL L206: // module_ptr - pre-checked for NULL The jvmti.xml file doesn't mark package_name or module_ptr with so both of those should be checked by the generated glue code. class_loader is marked with so a NULL class_loader will get to here: L217: jobject module = Modules::get_named_module(h_loader, package_name, THREAD); and it looks like all the code paths in get_named_module() properly account for both NULL and non-NULL h_loader. Cool. test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java L42: System.err.println("java.library.path:" nit: a space between the ':' and '"' would make the output more readable test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), L82: JVMTI_VERSION_1_1); I was expecting this test to ask for the JVM/TI version that includes support for GetAllModules() and GetNamesModule(). Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. L360: if (module != NULL || mod_name !=NULL) { bit: space after '!=' and before NULL Has someone checked the generated glue code for completeness and proper checks? Dan > > Thanks, > Serguei > > > On 6/28/16 07:32, harold seigel wrote: >> >> Hi Serguei, >> >> Looks good. >> >> 1. In modules.cpp, the first assert in get_named_module() has the >> wrong function name: >> >> 825 assert(ModuleEntryTable::javabase_defined(), >> 826 "Attempt to call *get_module_by_package_name* before java.base is >> defined"); >> >> 2. Also, is a check needed to ensure that package_str is not null? >> >> 3. Is the ResourceMark(THREAD) needed at line 824? >> >> Thanks, Harold >> >> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for the comments! >>> I agree with you. >>> >>> Updated Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/27/16 22:06, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Overall this looks a lot clearer/simpler. >>>> >>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>> >>>>>> >>>>>> The Hotspot webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>> >>>> >>>> Are there intended to be other callers of Module::get_named_module? >>>> If not it seems odd to go to all the trouble of throwing >>>> exceptions, just to have the caller clear them and return an error >>>> code. Or you could move all that argument checking code into the >>>> JVMTI function directly - if called internally you would just >>>> assert that arguments are as expected. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> >>>> + otherwise the NULL is returned. >>>> >>>> Delete "the". >>>> >>>> Otherwise all looks good to me. >>>> >>>>>> >>>>>> >>>>>> The Jdk webrev is the same: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>> >>>>> >>>>> Sorry, the Jdk webrev changed as well: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>> >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is the review round #3. >>>>>> Alan suggested to replace the function GetModuleByPackageName with >>>>>> the GetNamedModule. >>>>>> New function will return NULL if the package is not in a module >>>>>> defined to the class loader. >>>>>> It simplifies the API and makes it easier to specify. >>>>>> JVM TI agents that instrument code in named modules need the >>>>>> Module >>>>>> at class load time. >>>>>> >>>>>> One question that came from the function semantics change. >>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>> independently of the existing >>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>> The issue is that the Modules::get_module() can return the unnamed >>>>>> module whereas the >>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>> instead >>>>>> of the unnamed module. >>>>>> Please, let me know if it is Ok or if you have better ideas how to >>>>>> share the code. >>>>>> >>>>>> This is the Summary from review round #1: >>>>>> >>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>> takes an additional parameter but this approach is disruptive. >>>>>> The alternative option is a JVM TI function that maps a >>>>>> classloader >>>>>> + package name to a module. >>>>>> We were initially not confident with this approach so we >>>>>> introduced >>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>> Based on experience to date then this approach seems okay and so >>>>>> this function needs to be promoted to a JVMTI function. >>>>>> >>>>>> It includes new jtreg test with native JVMTI agent. >>>>>> >>>>>> >>>>>> Testing: >>>>>> Run newly developed jtreg test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jun 28 19:33:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 12:33:46 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> Message-ID: <5772D11A.4010809@oracle.com> Thanks, Harold! Serguei On 6/28/16 10:45, harold seigel wrote: > > Hi Serguei, > > It looks good! > > Thanks, Harold > > > On 6/28/2016 12:37 PM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 28 19:34:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 12:34:56 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <2bf0d051-1fa9-3bbd-2d52-d9b117d366c6@oracle.com> Message-ID: <5772D160.9000002@oracle.com> On 6/28/16 10:24, Daniel D. Daugherty wrote: > On 6/27/16 10:20 PM, serguei.spitsyn at oracle.com wrote: >> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>> >>> >>> The Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>> >>> >>> >>> The Jdk webrev is the same: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>> >> >> Sorry, the Jdk webrev changed as well: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >> ' > > src/java.base/share/native/include/jvmti.h > No comments. > > Thumbs up on the 'jdk' repo change. Thanks, Dan! Serguei > > Dan > > > > >> >> >> Thanks, >> Serguei >> >> >>> >>> >>> Summary: >>> >>> This is the review round #3. >>> Alan suggested to replace the function GetModuleByPackageName with >>> the GetNamedModule. >>> New function will return NULL if the package is not in a module >>> defined to the class loader. >>> It simplifies the API and makes it easier to specify. >>> JVM TI agents that instrument code in named modules need the Module >>> at class load time. >>> >>> One question that came from the function semantics change. >>> I had to implement the Modules::get_named_module() from scratch >>> independently of the existing >>> Modules::get_module_by_package_name() and Modules::get_module(). >>> The issue is that the Modules::get_module() can return the unnamed >>> module whereas the >>> JVMTI helper Modules::get_named_module() should return NULL >>> instead of the unnamed module. >>> Please, let me know if it is Ok or if you have better ideas how to >>> share the code. >>> >>> This is the Summary from review round #1: >>> >>> One way to do this is by introducing a new ClassFileLoadHook that >>> takes an additional parameter but this approach is disruptive. >>> The alternative option is a JVM TI function that maps a >>> classloader + package name to a module. >>> We were initially not confident with this approach so we >>> introduced it as JVM function JVM_GetModuleByPackageName. >>> Based on experience to date then this approach seems okay and so >>> this function needs to be promoted to a JVMTI function. >>> >>> It includes new jtreg test with native JVMTI agent. >>> >>> >>> Testing: >>> Run newly developed jtreg test. >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Tue Jun 28 20:11:42 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:11:42 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> Message-ID: <5772D9FE.5030804@oracle.com> On 6/28/16 11:19, Daniel D. Daugherty wrote: > On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> > > make/test/JtregNative.gmk > No comments. > > src/share/vm/classfile/modules.hpp > No comments. > > src/share/vm/classfile/modules.cpp > L826: assert(h_loader.is_null() || > java_lang_ClassLoader::is_subclass(h_loader->klass()), > L827: "Class loader is not a subclass of > java.lang.ClassLoader"); > nit: indent on L827 is off by 1 space Thanks, will fix. > > I'll have to check the upper layers of this API, but if an > agent can pass a bad 'class_loader' parameter and get this > assert() to fire, then that's not good. Hopefully a bad > 'class_loader' parameter is caught at a higher layer. Not sure, what do you mean. Do you mean the generated JVMTI upper layer or the JvmtiEnv::GetNamedModule? Probably, the generated code. > > Update: Yes, passing a non-NULL jobject as the class_loader > parameter > when the jobject does not refer to a "class loader" is caught > at the upper layer. The upper layer does not check that it is a class loader, just for non-NULL. I think, it is good to have an assert here to double-checks the pre-conditions as other caller can be added later. But I'm Ok to get rid of it if you suggest. > > L828: assert(package_str != NULL, "the package_str should not be > NULL"); > Same concern about the package_str parameter. > > Update: Yes, the generated JVM/TI glue code should catch a > NULL package_name/package_str at the upper layers. Yes, but this assert is intentional as above. > > > src/share/vm/prims/jvmti.xml > L6550: > L6551: > L6552: > L6553: On return, points to a > java.lang.reflect.Module object. > L6554: > L6555: > > The above wording doesn't allow for module_ptr to be NULL which > is a mismatch with the description. I disagree (or maybe I got it incorrectly). Pointing to NULL and be NULL is different. It is not allowed for the module_ptr to be NULL but Ok to pint to NULL on return. > > L2518: function can be used to map class loader and package > name to a module. > Typo: 'map class loader and package name' > -> 'map a class loader and a package name' Good catch, thanks! Will fix. > > > src/share/vm/prims/jvmtiEnv.cpp > L204: // class_loader - NULL is a valid value, must be pre-checked > L205: // package_name - pre-checked for NULL > L206: // module_ptr - pre-checked for NULL > The jvmti.xml file doesn't mark package_name or module_ptr > with so both of those should be checked by the > generated glue code. > > class_loader is marked with so a NULL class_loader > will get to here: > > L217: jobject module = Modules::get_named_module(h_loader, > package_name, THREAD); > > and it looks like all the code paths in get_named_module() > properly account for both NULL and non-NULL h_loader. Cool. Good. Thank you for checking. > > test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java > > L42: System.err.println("java.library.path:" > nit: a space between the ':' and '"' would make the > output more readable Thanks, will fix. > > test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c > L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > L82: JVMTI_VERSION_1_1); > I was expecting this test to ask for the JVM/TI version that > includes support for GetAllModules() and GetNamesModule(). > Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. You are right. Will fix. > > L360: if (module != NULL || mod_name !=NULL) { > bit: space after '!=' and before NULL Thanks, will fix. > > Has someone checked the generated glue code for completeness and > proper checks? I checked it some time ago. But will double-check it. Thank you for the review and detailed comments! Serguei > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Jun 28 20:37:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:37:10 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772D9FE.5030804@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> Message-ID: <5772DFF6.7040907@oracle.com> On 6/28/16 13:11, serguei.spitsyn at oracle.com wrote: > On 6/28/16 11:19, Daniel D. Daugherty wrote: >> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Harold, >>> >>> Thank you again for the comments! >>> This is the updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>> >> . . . >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is >> caught >> at the upper layer. > > The upper layer does not check that it is a class loader, just for > non-NULL. Sorry, I mistyped the above. The upper layer does not check for the NULL which is correct as it is allowed. Thanks, Serguei > I think, it is good to have an assert here to double-checks the > pre-conditions as other caller can be added later. > But I'm Ok to get rid of it if you suggest. > From serguei.spitsyn at oracle.com Tue Jun 28 20:42:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 13:42:24 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> Message-ID: <5772E130.40109@oracle.com> Dan, The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ > Has someone checked the generated glue code for completeness and proper checks? This is the generated upper layer function in the jvmtiEnter.cpp: 3185 static jvmtiError JNICALL 3186 jvmti_GetNamedModule(jvmtiEnv* env, 3187 jobject class_loader, 3188 const char* package_name, 3189 jobject* module_ptr) { 3190 3191 #if !INCLUDE_JVMTI 3192 return JVMTI_ERROR_NOT_AVAILABLE; 3193 #else 3194 if(!JvmtiEnv::is_vm_live()) { 3195 return JVMTI_ERROR_WRONG_PHASE; 3196 } 3197 Thread* this_thread = Thread::current_or_null(); 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { 3199 return JVMTI_ERROR_UNATTACHED_THREAD; 3200 } 3201 JavaThread* current_thread = (JavaThread*)this_thread; 3202 ThreadInVMfromNative __tiv(current_thread); 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) 3204 debug_only(VMNativeEntryWrapper __vew;) 3205 CautiouslyPreserveExceptionMark __em(this_thread); 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); 3207 if (!jvmti_env->is_valid()) { 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; 3209 } 3210 jvmtiError err; 3211 if (package_name == NULL) { 3212 return JVMTI_ERROR_NULL_POINTER; 3213 } 3214 if (module_ptr == NULL) { 3215 return JVMTI_ERROR_NULL_POINTER; 3216 } 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, module_ptr); 3218 return err; 3219 #endif // INCLUDE_JVMTI 3220 } I do not see any problems in the above. Thanks, Serguei On 6/28/16 11:19, Daniel D. Daugherty wrote: > On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> Thank you again for the comments! >> This is the updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >> > > make/test/JtregNative.gmk > No comments. > > src/share/vm/classfile/modules.hpp > No comments. > > src/share/vm/classfile/modules.cpp > L826: assert(h_loader.is_null() || > java_lang_ClassLoader::is_subclass(h_loader->klass()), > L827: "Class loader is not a subclass of > java.lang.ClassLoader"); > nit: indent on L827 is off by 1 space > > I'll have to check the upper layers of this API, but if an > agent can pass a bad 'class_loader' parameter and get this > assert() to fire, then that's not good. Hopefully a bad > 'class_loader' parameter is caught at a higher layer. > > Update: Yes, passing a non-NULL jobject as the class_loader > parameter > when the jobject does not refer to a "class loader" is caught > at the upper layer. > > L828: assert(package_str != NULL, "the package_str should not be > NULL"); > Same concern about the package_str parameter. > > Update: Yes, the generated JVM/TI glue code should catch a > NULL package_name/package_str at the upper layers. > > > src/share/vm/prims/jvmti.xml > L6550: > L6551: > L6552: > L6553: On return, points to a > java.lang.reflect.Module object. > L6554: > L6555: > > The above wording doesn't allow for module_ptr to be NULL which > is a mismatch with the description. > > L2518: function can be used to map class loader and package > name to a module. > Typo: 'map class loader and package name' > -> 'map a class loader and a package name' > > > src/share/vm/prims/jvmtiEnv.cpp > L204: // class_loader - NULL is a valid value, must be pre-checked > L205: // package_name - pre-checked for NULL > L206: // module_ptr - pre-checked for NULL > The jvmti.xml file doesn't mark package_name or module_ptr > with so both of those should be checked by the > generated glue code. > > class_loader is marked with so a NULL class_loader > will get to here: > > L217: jobject module = Modules::get_named_module(h_loader, > package_name, THREAD); > > and it looks like all the code paths in get_named_module() > properly account for both NULL and non-NULL h_loader. Cool. > > test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java > > L42: System.err.println("java.library.path:" > nit: a space between the ':' and '"' would make the > output more readable > > test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c > L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > L82: JVMTI_VERSION_1_1); > I was expecting this test to ask for the JVM/TI version that > includes support for GetAllModules() and GetNamesModule(). > Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. > > L360: if (module != NULL || mod_name !=NULL) { > bit: space after '!=' and before NULL > > Has someone checked the generated glue code for completeness and > proper checks? > > Dan > > >> >> Thanks, >> Serguei >> >> >> On 6/28/16 07:32, harold seigel wrote: >>> >>> Hi Serguei, >>> >>> Looks good. >>> >>> 1. In modules.cpp, the first assert in get_named_module() has the >>> wrong function name: >>> >>> 825 assert(ModuleEntryTable::javabase_defined(), >>> 826 "Attempt to call *get_module_by_package_name* before java.base >>> is defined"); >>> >>> 2. Also, is a check needed to ensure that package_str is not null? >>> >>> 3. Is the ResourceMark(THREAD) needed at line 824? >>> >>> Thanks, Harold >>> >>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for the comments! >>>> I agree with you. >>>> >>>> Updated Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/27/16 22:06, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Overall this looks a lot clearer/simpler. >>>>> >>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>> >>>>>>> >>>>>>> The Hotspot webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>> >>>>> >>>>> Are there intended to be other callers of >>>>> Module::get_named_module? If not it seems odd to go to all the >>>>> trouble of throwing exceptions, just to have the caller clear them >>>>> and return an error code. Or you could move all that argument >>>>> checking code into the JVMTI function directly - if called >>>>> internally you would just assert that arguments are as expected. >>>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> + otherwise the NULL is returned. >>>>> >>>>> Delete "the". >>>>> >>>>> Otherwise all looks good to me. >>>>> >>>>>>> >>>>>>> >>>>>>> The Jdk webrev is the same: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>> >>>>>> >>>>>> Sorry, the Jdk webrev changed as well: >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>> >>>>> >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is the review round #3. >>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>> with >>>>>>> the GetNamedModule. >>>>>>> New function will return NULL if the package is not in a module >>>>>>> defined to the class loader. >>>>>>> It simplifies the API and makes it easier to specify. >>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>> Module >>>>>>> at class load time. >>>>>>> >>>>>>> One question that came from the function semantics change. >>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>> independently of the existing >>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>> The issue is that the Modules::get_module() can return the >>>>>>> unnamed >>>>>>> module whereas the >>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>> instead >>>>>>> of the unnamed module. >>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>> how to >>>>>>> share the code. >>>>>>> >>>>>>> This is the Summary from review round #1: >>>>>>> >>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>> The alternative option is a JVM TI function that maps a >>>>>>> classloader >>>>>>> + package name to a module. >>>>>>> We were initially not confident with this approach so we >>>>>>> introduced >>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>> Based on experience to date then this approach seems okay and so >>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>> >>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> Run newly developed jtreg test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Jun 28 21:02:20 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 15:02:20 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772D9FE.5030804@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> Message-ID: <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 11:19, Daniel D. Daugherty wrote: > >> >> I'll have to check the upper layers of this API, but if an >> agent can pass a bad 'class_loader' parameter and get this >> assert() to fire, then that's not good. Hopefully a bad >> 'class_loader' parameter is caught at a higher layer. > > Not sure, what do you mean. > Do you mean the generated JVMTI upper layer or the > JvmtiEnv::GetNamedModule? > Probably, the generated code. I did mean the generated layer. > >> >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is >> caught >> at the upper layer. > > The upper layer does not check that it is a class loader, just for > non-NULL. > I think, it is good to have an assert here to double-checks the > pre-conditions as other caller can be added later. > But I'm Ok to get rid of it if you suggest. Please keep the asserts. Basically I was mumbling to myself to make sure that the asserts could not be reached by user code and the "Update:" was to indicate that I did do. > >> >> src/share/vm/prims/jvmti.xml >> L6550: >> L6551: >> L6552: >> L6553: On return, points to a >> java.lang.reflect.Module object. >> L6554: >> L6555: >> >> The above wording doesn't allow for module_ptr to be NULL which >> is a mismatch with the description. > > I disagree (or maybe I got it incorrectly). > Pointing to NULL and be NULL is different. > It is not allowed for the module_ptr to be NULL but Ok to pint to NULL > on return. I think the description needs to be: On return, points to a java.lang.reflect.Module object or points to a NULL. Dan From serguei.spitsyn at oracle.com Tue Jun 28 21:09:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 14:09:51 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> Message-ID: <5772E79F.3040504@oracle.com> On 6/28/16 14:02, Daniel D. Daugherty wrote: > On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 11:19, Daniel D. Daugherty wrote: >> >>> >>> I'll have to check the upper layers of this API, but if an >>> agent can pass a bad 'class_loader' parameter and get this >>> assert() to fire, then that's not good. Hopefully a bad >>> 'class_loader' parameter is caught at a higher layer. >> >> Not sure, what do you mean. >> Do you mean the generated JVMTI upper layer or the >> JvmtiEnv::GetNamedModule? >> Probably, the generated code. > > I did mean the generated layer. Ok, thanks. > > >> >>> >>> Update: Yes, passing a non-NULL jobject as the class_loader >>> parameter >>> when the jobject does not refer to a "class loader" is >>> caught >>> at the upper layer. >> >> The upper layer does not check that it is a class loader, just for >> non-NULL. >> I think, it is good to have an assert here to double-checks the >> pre-conditions as other caller can be added later. >> But I'm Ok to get rid of it if you suggest. > > Please keep the asserts. Basically I was mumbling to myself to > make sure that the asserts could not be reached by user code > and the "Update:" was to indicate that I did do. Ok, thanks. > > >> >>> >>> src/share/vm/prims/jvmti.xml >>> L6550: >>> L6551: >>> L6552: >>> L6553: On return, points to a >>> java.lang.reflect.Module object. >>> L6554: >>> L6555: >>> >>> The above wording doesn't allow for module_ptr to be NULL which >>> is a mismatch with the description. >> >> I disagree (or maybe I got it incorrectly). >> Pointing to NULL and be NULL is different. >> It is not allowed for the module_ptr to be NULL but Ok to pint to >> NULL on return. > > I think the description needs to be: > > On return, points to a java.lang.reflect.Module object > or points to a NULL. Agreed, fixed. Thanks, Serguei > > > Dan From daniel.daugherty at oracle.com Tue Jun 28 21:45:31 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Jun 2016 15:45:31 -0600 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <57725A1C.7060404@oracle.com> References: <57725A1C.7060404@oracle.com> Message-ID: <8bce8b70-cc0d-147a-b393-859a3c54b4d3@oracle.com> On 6/28/16 5:06 AM, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159147 > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java No comments. src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java No comments. src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java No comments. src/java.instrument/share/classes/sun/instrument/TransformerManager.java No comments. src/java.instrument/share/native/libinstrument/JPLISAgent.c No comments. src/java.instrument/share/native/libinstrument/JPLISAgent.h No comments. test/java/lang/instrument/ATransformerManagementTestCase.java No comments. test/java/lang/instrument/RetransformAgent.java No comments. test/java/lang/instrument/SimpleIdentityTransformer.java No comments. Thumbs up. Dan > Summary: > > As noted in JDK-8155207 > and elsewhere, one > of the outstanding items for java.lang.instrument is > whether the new ClassFileTransformer transform method should > provider the ClassLoader parameter. > After further consideration then this seems useful and avoids agents > needing permissions to invoke Module::getClassLoader. > The fix is to add the ClassLoader as the second parameter of the > ClassFileTransformer#transform() method. > > This fix also replaces the usage of the JVM_GetModuleByPackageName > with the JVMTI GetNamedModule in the JPLISAgent.c. > It is why this fix depends on the fix of the JVMTI enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > and so, must be pushed after the JDK-8159145. > > > Testing: > Ran the Jtreg java/lang/instrument tests. > Ran two updated jtreg j.l.i tests: > java/lang/instrument/RetransformAgent.java > java/lang/instrument/SingleTransformerTest.java > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jun 28 23:58:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 16:58:00 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <8bce8b70-cc0d-147a-b393-859a3c54b4d3@oracle.com> References: <57725A1C.7060404@oracle.com> <8bce8b70-cc0d-147a-b393-859a3c54b4d3@oracle.com> Message-ID: <57730F08.4020406@oracle.com> Thanks, Dan! Serguei On 6/28/16 14:45, Daniel D. Daugherty wrote: > On 6/28/16 5:06 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159147 >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ > > src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java > No comments. > > src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > No comments. > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java > No comments. > > src/java.instrument/share/classes/sun/instrument/TransformerManager.java > No comments. > > src/java.instrument/share/native/libinstrument/JPLISAgent.c > No comments. > > src/java.instrument/share/native/libinstrument/JPLISAgent.h > No comments. > > test/java/lang/instrument/ATransformerManagementTestCase.java > No comments. > > test/java/lang/instrument/RetransformAgent.java > No comments. > > test/java/lang/instrument/SimpleIdentityTransformer.java > No comments. > > Thumbs up. > > Dan > >> Summary: >> >> As noted in JDK-8155207 >> and elsewhere, one >> of the outstanding items for java.lang.instrument is >> whether the new ClassFileTransformer transform method should >> provider the ClassLoader parameter. >> After further consideration then this seems useful and avoids >> agents needing permissions to invoke Module::getClassLoader. >> The fix is to add the ClassLoader as the second parameter of the >> ClassFileTransformer#transform() method. >> >> This fix also replaces the usage of the JVM_GetModuleByPackageName >> with the JVMTI GetNamedModule in the JPLISAgent.c. >> It is why this fix depends on the fix of the JVMTI enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> and so, must be pushed after the JDK-8159145. >> >> >> Testing: >> Ran the Jtreg java/lang/instrument tests. >> Ran two updated jtreg j.l.i tests: >> java/lang/instrument/RetransformAgent.java >> java/lang/instrument/SingleTransformerTest.java >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jun 29 01:29:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 11:29:58 +1000 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <57725A1C.7060404@oracle.com> References: <57725A1C.7060404@oracle.com> Message-ID: <6bde33e5-a8d0-c9ac-cf37-cc7d018d7daa@oracle.com> Hi Serguei, Changes look good. Just curious why none of the tests actually do anything with the Module or ClassLoader arguments? Thanks, David On 28/06/2016 9:06 PM, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159147 > > > Jdk webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ > > > Summary: > > As noted in JDK-8155207 > and elsewhere, one of > the outstanding items for java.lang.instrument is > whether the new ClassFileTransformer transform method should provider > the ClassLoader parameter. > After further consideration then this seems useful and avoids agents > needing permissions to invoke Module::getClassLoader. > The fix is to add the ClassLoader as the second parameter of the > ClassFileTransformer#transform() method. > > This fix also replaces the usage of the JVM_GetModuleByPackageName with > the JVMTI GetNamedModule in the JPLISAgent.c. > It is why this fix depends on the fix of the JVMTI enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > and so, must be pushed after the JDK-8159145. > > > Testing: > Ran the Jtreg java/lang/instrument tests. > Ran two updated jtreg j.l.i tests: > java/lang/instrument/RetransformAgent.java > java/lang/instrument/SingleTransformerTest.java > > Thanks, > Serguei From david.holmes at oracle.com Wed Jun 29 01:44:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 11:44:49 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772E79F.3040504@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> Message-ID: On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 14:02, Daniel D. Daugherty wrote: >> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>> >>>> >>>> I'll have to check the upper layers of this API, but if an >>>> agent can pass a bad 'class_loader' parameter and get this >>>> assert() to fire, then that's not good. Hopefully a bad >>>> 'class_loader' parameter is caught at a higher layer. >>> >>> Not sure, what do you mean. >>> Do you mean the generated JVMTI upper layer or the >>> JvmtiEnv::GetNamedModule? >>> Probably, the generated code. >> >> I did mean the generated layer. > > Ok, thanks. > >> >> >>> >>>> >>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>> parameter >>>> when the jobject does not refer to a "class loader" is >>>> caught >>>> at the upper layer. >>> >>> The upper layer does not check that it is a class loader, just for >>> non-NULL. >>> I think, it is good to have an assert here to double-checks the >>> pre-conditions as other caller can be added later. >>> But I'm Ok to get rid of it if you suggest. >> >> Please keep the asserts. Basically I was mumbling to myself to >> make sure that the asserts could not be reached by user code >> and the "Update:" was to indicate that I did do. > > Ok, thanks. > > >> >> >>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> L6550: >>>> L6551: >>>> L6552: >>>> L6553: On return, points to a >>>> java.lang.reflect.Module object. >>>> L6554: >>>> L6555: >>>> >>>> The above wording doesn't allow for module_ptr to be NULL which >>>> is a mismatch with the description. >>> >>> I disagree (or maybe I got it incorrectly). >>> Pointing to NULL and be NULL is different. >>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>> NULL on return. >> >> I think the description needs to be: >> >> On return, points to a java.lang.reflect.Module object >> or points to a NULL. > > Agreed, fixed. Disagree. You would say that a pointer is NULL, not that it points to a NULL. David > > Thanks, > Serguei > > >> >> >> Dan > From serguei.spitsyn at oracle.com Wed Jun 29 02:09:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:09:35 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> Message-ID: <57732DDF.4070904@oracle.com> On 6/28/16 18:44, David Holmes wrote: > On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>> >>>>> >>>>> I'll have to check the upper layers of this API, but if an >>>>> agent can pass a bad 'class_loader' parameter and get this >>>>> assert() to fire, then that's not good. Hopefully a bad >>>>> 'class_loader' parameter is caught at a higher layer. >>>> >>>> Not sure, what do you mean. >>>> Do you mean the generated JVMTI upper layer or the >>>> JvmtiEnv::GetNamedModule? >>>> Probably, the generated code. >>> >>> I did mean the generated layer. >> >> Ok, thanks. >> >>> >>> >>>> >>>>> >>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>> parameter >>>>> when the jobject does not refer to a "class loader" is >>>>> caught >>>>> at the upper layer. >>>> >>>> The upper layer does not check that it is a class loader, just for >>>> non-NULL. >>>> I think, it is good to have an assert here to double-checks the >>>> pre-conditions as other caller can be added later. >>>> But I'm Ok to get rid of it if you suggest. >>> >>> Please keep the asserts. Basically I was mumbling to myself to >>> make sure that the asserts could not be reached by user code >>> and the "Update:" was to indicate that I did do. >> >> Ok, thanks. >> >> >>> >>> >>>> >>>>> >>>>> src/share/vm/prims/jvmti.xml >>>>> L6550: >>>>> L6551: >>>>> L6552: >>>>> L6553: On return, points to a >>>>> java.lang.reflect.Module object. >>>>> L6554: >>>>> L6555: >>>>> >>>>> The above wording doesn't allow for module_ptr to be NULL >>>>> which >>>>> is a mismatch with the description. >>>> >>>> I disagree (or maybe I got it incorrectly). >>>> Pointing to NULL and be NULL is different. >>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>> NULL on return. >>> >>> I think the description needs to be: >>> >>> On return, points to a java.lang.reflect.Module object >>> or points to a NULL. >> >> Agreed, fixed. > > Disagree. You would say that a pointer is NULL, not that it points to > a NULL. Why are you disagree? The module_ptr is an out argument, it is not allowed to be NULL. But the returning value by this pointer can be NULL. Thanks, Serguei > > David > > >> >> Thanks, >> Serguei >> >> >>> >>> >>> Dan >> From david.holmes at oracle.com Wed Jun 29 02:17:34 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:17:34 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5772E130.40109@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> Message-ID: <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> Hi Serguei, Looks good to me. A couple of comments ... On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: > Dan, > > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ src/share/vm/classfile/modules.cpp Nit: + const PackageEntry* const pkg_entry = + get_package_entry_by_name(package_sym, h_loader, THREAD); indent on a line continuation should be 4 not 2. (no need to see updated webrev). --- src/share/vm/prims/jvmti.xml + or points to NULL. I would have suggested "or is NULL." as per other email, but I see that this terminology is pre-existing, so ignore that other email. > > >> Has someone checked the generated glue code for completeness and > proper checks? > > This is the generated upper layer function in the jvmtiEnter.cpp: > > 3185 static jvmtiError JNICALL > 3186 jvmti_GetNamedModule(jvmtiEnv* env, > 3187 jobject class_loader, > 3188 const char* package_name, > 3189 jobject* module_ptr) { > 3190 > 3191 #if !INCLUDE_JVMTI > 3192 return JVMTI_ERROR_NOT_AVAILABLE; > 3193 #else > 3194 if(!JvmtiEnv::is_vm_live()) { > 3195 return JVMTI_ERROR_WRONG_PHASE; > 3196 } > 3197 Thread* this_thread = Thread::current_or_null(); > 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { > 3199 return JVMTI_ERROR_UNATTACHED_THREAD; > 3200 } > 3201 JavaThread* current_thread = (JavaThread*)this_thread; > 3202 ThreadInVMfromNative __tiv(current_thread); > 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) > 3204 debug_only(VMNativeEntryWrapper __vew;) > 3205 CautiouslyPreserveExceptionMark __em(this_thread); > 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); > 3207 if (!jvmti_env->is_valid()) { > 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; > 3209 } > 3210 jvmtiError err; > 3211 if (package_name == NULL) { > 3212 return JVMTI_ERROR_NULL_POINTER; > 3213 } > 3214 if (module_ptr == NULL) { > 3215 return JVMTI_ERROR_NULL_POINTER; > 3216 } > 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, > module_ptr); > 3218 return err; > 3219 #endif // INCLUDE_JVMTI > 3220 } > > > I do not see any problems in the above. Looks good to me too. Thanks, David > > Thanks, > Serguei > > > > > On 6/28/16 11:19, Daniel D. Daugherty wrote: >> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Harold, >>> >>> Thank you again for the comments! >>> This is the updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>> >> >> make/test/JtregNative.gmk >> No comments. >> >> src/share/vm/classfile/modules.hpp >> No comments. >> >> src/share/vm/classfile/modules.cpp >> L826: assert(h_loader.is_null() || >> java_lang_ClassLoader::is_subclass(h_loader->klass()), >> L827: "Class loader is not a subclass of >> java.lang.ClassLoader"); >> nit: indent on L827 is off by 1 space >> >> I'll have to check the upper layers of this API, but if an >> agent can pass a bad 'class_loader' parameter and get this >> assert() to fire, then that's not good. Hopefully a bad >> 'class_loader' parameter is caught at a higher layer. >> >> Update: Yes, passing a non-NULL jobject as the class_loader >> parameter >> when the jobject does not refer to a "class loader" is caught >> at the upper layer. >> >> L828: assert(package_str != NULL, "the package_str should not be >> NULL"); >> Same concern about the package_str parameter. >> >> Update: Yes, the generated JVM/TI glue code should catch a >> NULL package_name/package_str at the upper layers. >> >> >> src/share/vm/prims/jvmti.xml >> L6550: >> L6551: >> L6552: >> L6553: On return, points to a >> java.lang.reflect.Module object. >> L6554: >> L6555: >> >> The above wording doesn't allow for module_ptr to be NULL which >> is a mismatch with the description. >> >> L2518: function can be used to map class loader and package >> name to a module. >> Typo: 'map class loader and package name' >> -> 'map a class loader and a package name' >> >> >> src/share/vm/prims/jvmtiEnv.cpp >> L204: // class_loader - NULL is a valid value, must be pre-checked >> L205: // package_name - pre-checked for NULL >> L206: // module_ptr - pre-checked for NULL >> The jvmti.xml file doesn't mark package_name or module_ptr >> with so both of those should be checked by the >> generated glue code. >> >> class_loader is marked with so a NULL class_loader >> will get to here: >> >> L217: jobject module = Modules::get_named_module(h_loader, >> package_name, THREAD); >> >> and it looks like all the code paths in get_named_module() >> properly account for both NULL and non-NULL h_loader. Cool. >> >> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >> >> L42: System.err.println("java.library.path:" >> nit: a space between the ':' and '"' would make the >> output more readable >> >> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >> &jvmti), >> L82: JVMTI_VERSION_1_1); >> I was expecting this test to ask for the JVM/TI version that >> includes support for GetAllModules() and GetNamesModule(). >> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >> >> L360: if (module != NULL || mod_name !=NULL) { >> bit: space after '!=' and before NULL >> >> Has someone checked the generated glue code for completeness and >> proper checks? >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/28/16 07:32, harold seigel wrote: >>>> >>>> Hi Serguei, >>>> >>>> Looks good. >>>> >>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>> wrong function name: >>>> >>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>> is defined"); >>>> >>>> 2. Also, is a check needed to ensure that package_str is not null? >>>> >>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>> >>>> Thanks, Harold >>>> >>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the comments! >>>>> I agree with you. >>>>> >>>>> Updated Hotspot webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Overall this looks a lot clearer/simpler. >>>>>> >>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>> >>>>>>>> >>>>>>>> The Hotspot webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>> >>>>>> >>>>>> Are there intended to be other callers of >>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>> and return an error code. Or you could move all that argument >>>>>> checking code into the JVMTI function directly - if called >>>>>> internally you would just assert that arguments are as expected. >>>>>> >>>>>> >>>>>> src/share/vm/prims/jvmti.xml >>>>>> >>>>>> + otherwise the NULL is returned. >>>>>> >>>>>> Delete "the". >>>>>> >>>>>> Otherwise all looks good to me. >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The Jdk webrev is the same: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>> >>>>>>> >>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>> >>>>>> >>>>>> Looks fine. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> This is the review round #3. >>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>> with >>>>>>>> the GetNamedModule. >>>>>>>> New function will return NULL if the package is not in a module >>>>>>>> defined to the class loader. >>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>> Module >>>>>>>> at class load time. >>>>>>>> >>>>>>>> One question that came from the function semantics change. >>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>> independently of the existing >>>>>>>> Modules::get_module_by_package_name() and Modules::get_module(). >>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>> unnamed >>>>>>>> module whereas the >>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>> instead >>>>>>>> of the unnamed module. >>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>> how to >>>>>>>> share the code. >>>>>>>> >>>>>>>> This is the Summary from review round #1: >>>>>>>> >>>>>>>> One way to do this is by introducing a new ClassFileLoadHook that >>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>> classloader >>>>>>>> + package name to a module. >>>>>>>> We were initially not confident with this approach so we >>>>>>>> introduced >>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>> Based on experience to date then this approach seems okay and so >>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>> >>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run newly developed jtreg test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Jun 29 02:29:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:29:31 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> Message-ID: <5773328B.1090805@oracle.com> Hi David, On 6/28/16 19:17, David Holmes wrote: > Hi Serguei, > > Looks good to me. A couple of comments ... Thank you for reviewing it! > > On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ >> > > src/share/vm/classfile/modules.cpp > > Nit: > > + const PackageEntry* const pkg_entry = > + get_package_entry_by_name(package_sym, h_loader, THREAD); > > indent on a line continuation should be 4 not 2. (no need to see > updated webrev). This fragment was taken from the function get_module() with the pre-existing indent. There are a couple of other fragments with the indent like this. There is a rule to follow the the file style. > > --- > > src/share/vm/prims/jvmti.xml > > + or points to NULL. > > I would have suggested "or is NULL." as per other email, > but I see that this terminology is pre-existing, so ignore that other > email. Ok, thanks! > >> >> >>> Has someone checked the generated glue code for completeness and >> proper checks? >> >> This is the generated upper layer function in the jvmtiEnter.cpp: >> >> 3185 static jvmtiError JNICALL >> 3186 jvmti_GetNamedModule(jvmtiEnv* env, >> 3187 jobject class_loader, >> 3188 const char* package_name, >> 3189 jobject* module_ptr) { >> 3190 >> 3191 #if !INCLUDE_JVMTI >> 3192 return JVMTI_ERROR_NOT_AVAILABLE; >> 3193 #else >> 3194 if(!JvmtiEnv::is_vm_live()) { >> 3195 return JVMTI_ERROR_WRONG_PHASE; >> 3196 } >> 3197 Thread* this_thread = Thread::current_or_null(); >> 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { >> 3199 return JVMTI_ERROR_UNATTACHED_THREAD; >> 3200 } >> 3201 JavaThread* current_thread = (JavaThread*)this_thread; >> 3202 ThreadInVMfromNative __tiv(current_thread); >> 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) >> 3204 debug_only(VMNativeEntryWrapper __vew;) >> 3205 CautiouslyPreserveExceptionMark __em(this_thread); >> 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); >> 3207 if (!jvmti_env->is_valid()) { >> 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; >> 3209 } >> 3210 jvmtiError err; >> 3211 if (package_name == NULL) { >> 3212 return JVMTI_ERROR_NULL_POINTER; >> 3213 } >> 3214 if (module_ptr == NULL) { >> 3215 return JVMTI_ERROR_NULL_POINTER; >> 3216 } >> 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, >> module_ptr); >> 3218 return err; >> 3219 #endif // INCLUDE_JVMTI >> 3220 } >> >> >> I do not see any problems in the above. > > Looks good to me too. Good. Thanks! Serguei > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >> >> >> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Harold, >>>> >>>> Thank you again for the comments! >>>> This is the updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>>> >>>> >>> >>> make/test/JtregNative.gmk >>> No comments. >>> >>> src/share/vm/classfile/modules.hpp >>> No comments. >>> >>> src/share/vm/classfile/modules.cpp >>> L826: assert(h_loader.is_null() || >>> java_lang_ClassLoader::is_subclass(h_loader->klass()), >>> L827: "Class loader is not a subclass of >>> java.lang.ClassLoader"); >>> nit: indent on L827 is off by 1 space >>> >>> I'll have to check the upper layers of this API, but if an >>> agent can pass a bad 'class_loader' parameter and get this >>> assert() to fire, then that's not good. Hopefully a bad >>> 'class_loader' parameter is caught at a higher layer. >>> >>> Update: Yes, passing a non-NULL jobject as the class_loader >>> parameter >>> when the jobject does not refer to a "class loader" is >>> caught >>> at the upper layer. >>> >>> L828: assert(package_str != NULL, "the package_str should not be >>> NULL"); >>> Same concern about the package_str parameter. >>> >>> Update: Yes, the generated JVM/TI glue code should catch a >>> NULL package_name/package_str at the upper layers. >>> >>> >>> src/share/vm/prims/jvmti.xml >>> L6550: >>> L6551: >>> L6552: >>> L6553: On return, points to a >>> java.lang.reflect.Module object. >>> L6554: >>> L6555: >>> >>> The above wording doesn't allow for module_ptr to be NULL which >>> is a mismatch with the description. >>> >>> L2518: function can be used to map class loader and package >>> name to a module. >>> Typo: 'map class loader and package name' >>> -> 'map a class loader and a package name' >>> >>> >>> src/share/vm/prims/jvmtiEnv.cpp >>> L204: // class_loader - NULL is a valid value, must be pre-checked >>> L205: // package_name - pre-checked for NULL >>> L206: // module_ptr - pre-checked for NULL >>> The jvmti.xml file doesn't mark package_name or module_ptr >>> with so both of those should be checked by the >>> generated glue code. >>> >>> class_loader is marked with so a NULL class_loader >>> will get to here: >>> >>> L217: jobject module = Modules::get_named_module(h_loader, >>> package_name, THREAD); >>> >>> and it looks like all the code paths in get_named_module() >>> properly account for both NULL and non-NULL h_loader. Cool. >>> >>> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >>> >>> >>> L42: System.err.println("java.library.path:" >>> nit: a space between the ':' and '"' would make the >>> output more readable >>> >>> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >>> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >>> &jvmti), >>> L82: JVMTI_VERSION_1_1); >>> I was expecting this test to ask for the JVM/TI version that >>> includes support for GetAllModules() and GetNamesModule(). >>> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >>> >>> L360: if (module != NULL || mod_name !=NULL) { >>> bit: space after '!=' and before NULL >>> >>> Has someone checked the generated glue code for completeness and >>> proper checks? >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 6/28/16 07:32, harold seigel wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Looks good. >>>>> >>>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>>> wrong function name: >>>>> >>>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>>> is defined"); >>>>> >>>>> 2. Also, is a check needed to ensure that package_str is not null? >>>>> >>>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for the comments! >>>>>> I agree with you. >>>>>> >>>>>> Updated Hotspot webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Overall this looks a lot clearer/simpler. >>>>>>> >>>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>>> >>>>>>>>> >>>>>>>>> The Hotspot webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> Are there intended to be other callers of >>>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>>> and return an error code. Or you could move all that argument >>>>>>> checking code into the JVMTI function directly - if called >>>>>>> internally you would just assert that arguments are as expected. >>>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> >>>>>>> + otherwise the NULL is returned. >>>>>>> >>>>>>> Delete "the". >>>>>>> >>>>>>> Otherwise all looks good to me. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The Jdk webrev is the same: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Looks fine. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> This is the review round #3. >>>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>>> with >>>>>>>>> the GetNamedModule. >>>>>>>>> New function will return NULL if the package is not in a module >>>>>>>>> defined to the class loader. >>>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>>> Module >>>>>>>>> at class load time. >>>>>>>>> >>>>>>>>> One question that came from the function semantics change. >>>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>>> independently of the existing >>>>>>>>> Modules::get_module_by_package_name() and >>>>>>>>> Modules::get_module(). >>>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>>> unnamed >>>>>>>>> module whereas the >>>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>>> instead >>>>>>>>> of the unnamed module. >>>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>>> how to >>>>>>>>> share the code. >>>>>>>>> >>>>>>>>> This is the Summary from review round #1: >>>>>>>>> >>>>>>>>> One way to do this is by introducing a new ClassFileLoadHook >>>>>>>>> that >>>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>>> classloader >>>>>>>>> + package name to a module. >>>>>>>>> We were initially not confident with this approach so we >>>>>>>>> introduced >>>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>>> Based on experience to date then this approach seems okay >>>>>>>>> and so >>>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>>> >>>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run newly developed jtreg test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Wed Jun 29 02:30:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:30:35 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57732DDF.4070904@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: > On 6/28/16 18:44, David Holmes wrote: >> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>> >>>>>> >>>>>> I'll have to check the upper layers of this API, but if an >>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>> 'class_loader' parameter is caught at a higher layer. >>>>> >>>>> Not sure, what do you mean. >>>>> Do you mean the generated JVMTI upper layer or the >>>>> JvmtiEnv::GetNamedModule? >>>>> Probably, the generated code. >>>> >>>> I did mean the generated layer. >>> >>> Ok, thanks. >>> >>>> >>>> >>>>> >>>>>> >>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>> parameter >>>>>> when the jobject does not refer to a "class loader" is >>>>>> caught >>>>>> at the upper layer. >>>>> >>>>> The upper layer does not check that it is a class loader, just for >>>>> non-NULL. >>>>> I think, it is good to have an assert here to double-checks the >>>>> pre-conditions as other caller can be added later. >>>>> But I'm Ok to get rid of it if you suggest. >>>> >>>> Please keep the asserts. Basically I was mumbling to myself to >>>> make sure that the asserts could not be reached by user code >>>> and the "Update:" was to indicate that I did do. >>> >>> Ok, thanks. >>> >>> >>>> >>>> >>>>> >>>>>> >>>>>> src/share/vm/prims/jvmti.xml >>>>>> L6550: >>>>>> L6551: >>>>>> L6552: >>>>>> L6553: On return, points to a >>>>>> java.lang.reflect.Module object. >>>>>> L6554: >>>>>> L6555: >>>>>> >>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>> which >>>>>> is a mismatch with the description. >>>>> >>>>> I disagree (or maybe I got it incorrectly). >>>>> Pointing to NULL and be NULL is different. >>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>> NULL on return. >>>> >>>> I think the description needs to be: >>>> >>>> On return, points to a java.lang.reflect.Module object >>>> or points to a NULL. >>> >>> Agreed, fixed. >> >> Disagree. You would say that a pointer is NULL, not that it points to >> a NULL. > > Why are you disagree? > The module_ptr is an out argument, it is not allowed to be NULL. > But the returning value by this pointer can be NULL. As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. Thanks, David > > Thanks, > Serguei > > >> >> David >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> >>>> Dan >>> > From serguei.spitsyn at oracle.com Wed Jun 29 02:35:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 19:35:10 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: <577333DE.8090001@oracle.com> On 6/28/16 19:30, David Holmes wrote: > On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >> On 6/28/16 18:44, David Holmes wrote: >>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>> >>>>>>> >>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>> >>>>>> Not sure, what do you mean. >>>>>> Do you mean the generated JVMTI upper layer or the >>>>>> JvmtiEnv::GetNamedModule? >>>>>> Probably, the generated code. >>>>> >>>>> I did mean the generated layer. >>>> >>>> Ok, thanks. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>> parameter >>>>>>> when the jobject does not refer to a "class loader" is >>>>>>> caught >>>>>>> at the upper layer. >>>>>> >>>>>> The upper layer does not check that it is a class loader, just for >>>>>> non-NULL. >>>>>> I think, it is good to have an assert here to double-checks the >>>>>> pre-conditions as other caller can be added later. >>>>>> But I'm Ok to get rid of it if you suggest. >>>>> >>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>> make sure that the asserts could not be reached by user code >>>>> and the "Update:" was to indicate that I did do. >>>> >>>> Ok, thanks. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> L6550: >>>>>>> L6551: >>>>>>> L6552: >>>>>>> L6553: On return, points to a >>>>>>> java.lang.reflect.Module object. >>>>>>> L6554: >>>>>>> L6555: >>>>>>> >>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>> which >>>>>>> is a mismatch with the description. >>>>>> >>>>>> I disagree (or maybe I got it incorrectly). >>>>>> Pointing to NULL and be NULL is different. >>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>> NULL on return. >>>>> >>>>> I think the description needs to be: >>>>> >>>>> On return, points to a java.lang.reflect.Module >>>>> object >>>>> or points to a NULL. >>>> >>>> Agreed, fixed. >>> >>> Disagree. You would say that a pointer is NULL, not that it points to >>> a NULL. >> >> Why are you disagree? >> The module_ptr is an out argument, it is not allowed to be NULL. >> But the returning value by this pointer can be NULL. > > As per later email I see this terminology already exists so is fine, > but I find it confusing to say "points to a NULL" - a NULL is not an > entity. If "foo points to a NULL" that implies to me "foo == &NULL;" > which is nonsense - foo == NULL, and if foo==NULL then foo points to > nothing. But the "pointer to a pointer" aspect here does confuse things. Agreed. It is a little bit confusing but users seems to be Ok with it. So that there is no motivation to improve it as it would touch many fragments. Thanks, Serguei > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> David >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Dan >>>> >> From david.holmes at oracle.com Wed Jun 29 02:37:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jun 2016 12:37:26 +1000 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5773328B.1090805@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772E130.40109@oracle.com> <8bfa102b-48fc-42e3-04f8-efcd7ded3589@oracle.com> <5773328B.1090805@oracle.com> Message-ID: On 29/06/2016 12:29 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 6/28/16 19:17, David Holmes wrote: >> Hi Serguei, >> >> Looks good to me. A couple of comments ... > > Thank you for reviewing it! > > >> >> On 29/06/2016 6:42 AM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ >>> >> >> src/share/vm/classfile/modules.cpp >> >> Nit: >> >> + const PackageEntry* const pkg_entry = >> + get_package_entry_by_name(package_sym, h_loader, THREAD); >> >> indent on a line continuation should be 4 not 2. (no need to see >> updated webrev). > > This fragment was taken from the function get_module() with the > pre-existing indent. > There are a couple of other fragments with the indent like this. > There is a rule to follow the the file style. There are a number of indentation and line-length issues in this new file. David > >> >> --- >> >> src/share/vm/prims/jvmti.xml >> >> + or points to NULL. >> >> I would have suggested "or is NULL." as per other email, >> but I see that this terminology is pre-existing, so ignore that other >> email. > > Ok, thanks! > > >> >>> >>> >>>> Has someone checked the generated glue code for completeness and >>> proper checks? >>> >>> This is the generated upper layer function in the jvmtiEnter.cpp: >>> >>> 3185 static jvmtiError JNICALL >>> 3186 jvmti_GetNamedModule(jvmtiEnv* env, >>> 3187 jobject class_loader, >>> 3188 const char* package_name, >>> 3189 jobject* module_ptr) { >>> 3190 >>> 3191 #if !INCLUDE_JVMTI >>> 3192 return JVMTI_ERROR_NOT_AVAILABLE; >>> 3193 #else >>> 3194 if(!JvmtiEnv::is_vm_live()) { >>> 3195 return JVMTI_ERROR_WRONG_PHASE; >>> 3196 } >>> 3197 Thread* this_thread = Thread::current_or_null(); >>> 3198 if (this_thread == NULL || !this_thread->is_Java_thread()) { >>> 3199 return JVMTI_ERROR_UNATTACHED_THREAD; >>> 3200 } >>> 3201 JavaThread* current_thread = (JavaThread*)this_thread; >>> 3202 ThreadInVMfromNative __tiv(current_thread); >>> 3203 VM_ENTRY_BASE(jvmtiError, jvmti_GetNamedModule , current_thread) >>> 3204 debug_only(VMNativeEntryWrapper __vew;) >>> 3205 CautiouslyPreserveExceptionMark __em(this_thread); >>> 3206 JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); >>> 3207 if (!jvmti_env->is_valid()) { >>> 3208 return JVMTI_ERROR_INVALID_ENVIRONMENT; >>> 3209 } >>> 3210 jvmtiError err; >>> 3211 if (package_name == NULL) { >>> 3212 return JVMTI_ERROR_NULL_POINTER; >>> 3213 } >>> 3214 if (module_ptr == NULL) { >>> 3215 return JVMTI_ERROR_NULL_POINTER; >>> 3216 } >>> 3217 err = jvmti_env->GetNamedModule(class_loader, package_name, >>> module_ptr); >>> 3218 return err; >>> 3219 #endif // INCLUDE_JVMTI >>> 3220 } >>> >>> >>> I do not see any problems in the above. >> >> Looks good to me too. > > Good. > > > Thanks! > Serguei > > >> >> Thanks, >> David >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>> On 6/28/16 10:37 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Harold, >>>>> >>>>> Thank you again for the comments! >>>>> This is the updated webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.5/ >>>>> >>>>> >>>> >>>> make/test/JtregNative.gmk >>>> No comments. >>>> >>>> src/share/vm/classfile/modules.hpp >>>> No comments. >>>> >>>> src/share/vm/classfile/modules.cpp >>>> L826: assert(h_loader.is_null() || >>>> java_lang_ClassLoader::is_subclass(h_loader->klass()), >>>> L827: "Class loader is not a subclass of >>>> java.lang.ClassLoader"); >>>> nit: indent on L827 is off by 1 space >>>> >>>> I'll have to check the upper layers of this API, but if an >>>> agent can pass a bad 'class_loader' parameter and get this >>>> assert() to fire, then that's not good. Hopefully a bad >>>> 'class_loader' parameter is caught at a higher layer. >>>> >>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>> parameter >>>> when the jobject does not refer to a "class loader" is >>>> caught >>>> at the upper layer. >>>> >>>> L828: assert(package_str != NULL, "the package_str should not be >>>> NULL"); >>>> Same concern about the package_str parameter. >>>> >>>> Update: Yes, the generated JVM/TI glue code should catch a >>>> NULL package_name/package_str at the upper layers. >>>> >>>> >>>> src/share/vm/prims/jvmti.xml >>>> L6550: >>>> L6551: >>>> L6552: >>>> L6553: On return, points to a >>>> java.lang.reflect.Module object. >>>> L6554: >>>> L6555: >>>> >>>> The above wording doesn't allow for module_ptr to be NULL which >>>> is a mismatch with the description. >>>> >>>> L2518: function can be used to map class loader and package >>>> name to a module. >>>> Typo: 'map class loader and package name' >>>> -> 'map a class loader and a package name' >>>> >>>> >>>> src/share/vm/prims/jvmtiEnv.cpp >>>> L204: // class_loader - NULL is a valid value, must be pre-checked >>>> L205: // package_name - pre-checked for NULL >>>> L206: // module_ptr - pre-checked for NULL >>>> The jvmti.xml file doesn't mark package_name or module_ptr >>>> with so both of those should be checked by the >>>> generated glue code. >>>> >>>> class_loader is marked with so a NULL class_loader >>>> will get to here: >>>> >>>> L217: jobject module = Modules::get_named_module(h_loader, >>>> package_name, THREAD); >>>> >>>> and it looks like all the code paths in get_named_module() >>>> properly account for both NULL and non-NULL h_loader. Cool. >>>> >>>> test/serviceability/jvmti/GetNamedModule/MyPackage/GetNamedModuleTest.java >>>> >>>> >>>> L42: System.err.println("java.library.path:" >>>> nit: a space between the ':' and '"' would make the >>>> output more readable >>>> >>>> test/serviceability/jvmti/GetNamedModule/libGetNamedModuleTest.c >>>> L81: res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) >>>> &jvmti), >>>> L82: JVMTI_VERSION_1_1); >>>> I was expecting this test to ask for the JVM/TI version that >>>> includes support for GetAllModules() and GetNamesModule(). >>>> Looks like that is version 9.0.0 or newer aka JVMTI_VERSION_9. >>>> >>>> L360: if (module != NULL || mod_name !=NULL) { >>>> bit: space after '!=' and before NULL >>>> >>>> Has someone checked the generated glue code for completeness and >>>> proper checks? >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 6/28/16 07:32, harold seigel wrote: >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Looks good. >>>>>> >>>>>> 1. In modules.cpp, the first assert in get_named_module() has the >>>>>> wrong function name: >>>>>> >>>>>> 825 assert(ModuleEntryTable::javabase_defined(), >>>>>> 826 "Attempt to call *get_module_by_package_name* before java.base >>>>>> is defined"); >>>>>> >>>>>> 2. Also, is a check needed to ensure that package_str is not null? >>>>>> >>>>>> 3. Is the ResourceMark(THREAD) needed at line 824? >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 6/28/2016 4:54 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for the comments! >>>>>>> I agree with you. >>>>>>> >>>>>>> Updated Hotspot webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.4/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 6/27/16 22:06, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> Overall this looks a lot clearer/simpler. >>>>>>>> >>>>>>>> On 28/06/2016 2:20 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/27/16 21:08, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the Jigsaw fix for the enhancement: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159145 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Hotspot webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.3/ >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> Are there intended to be other callers of >>>>>>>> Module::get_named_module? If not it seems odd to go to all the >>>>>>>> trouble of throwing exceptions, just to have the caller clear them >>>>>>>> and return an error code. Or you could move all that argument >>>>>>>> checking code into the JVMTI function directly - if called >>>>>>>> internally you would just assert that arguments are as expected. >>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> >>>>>>>> + otherwise the NULL is returned. >>>>>>>> >>>>>>>> Delete "the". >>>>>>>> >>>>>>>> Otherwise all looks good to me. >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Jdk webrev is the same: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry, the Jdk webrev changed as well: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk3/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Looks fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> This is the review round #3. >>>>>>>>>> Alan suggested to replace the function GetModuleByPackageName >>>>>>>>>> with >>>>>>>>>> the GetNamedModule. >>>>>>>>>> New function will return NULL if the package is not in a module >>>>>>>>>> defined to the class loader. >>>>>>>>>> It simplifies the API and makes it easier to specify. >>>>>>>>>> JVM TI agents that instrument code in named modules need the >>>>>>>>>> Module >>>>>>>>>> at class load time. >>>>>>>>>> >>>>>>>>>> One question that came from the function semantics change. >>>>>>>>>> I had to implement the Modules::get_named_module() from scratch >>>>>>>>>> independently of the existing >>>>>>>>>> Modules::get_module_by_package_name() and >>>>>>>>>> Modules::get_module(). >>>>>>>>>> The issue is that the Modules::get_module() can return the >>>>>>>>>> unnamed >>>>>>>>>> module whereas the >>>>>>>>>> JVMTI helper Modules::get_named_module() should return NULL >>>>>>>>>> instead >>>>>>>>>> of the unnamed module. >>>>>>>>>> Please, let me know if it is Ok or if you have better ideas >>>>>>>>>> how to >>>>>>>>>> share the code. >>>>>>>>>> >>>>>>>>>> This is the Summary from review round #1: >>>>>>>>>> >>>>>>>>>> One way to do this is by introducing a new ClassFileLoadHook >>>>>>>>>> that >>>>>>>>>> takes an additional parameter but this approach is disruptive. >>>>>>>>>> The alternative option is a JVM TI function that maps a >>>>>>>>>> classloader >>>>>>>>>> + package name to a module. >>>>>>>>>> We were initially not confident with this approach so we >>>>>>>>>> introduced >>>>>>>>>> it as JVM function JVM_GetModuleByPackageName. >>>>>>>>>> Based on experience to date then this approach seems okay >>>>>>>>>> and so >>>>>>>>>> this function needs to be promoted to a JVMTI function. >>>>>>>>>> >>>>>>>>>> It includes new jtreg test with native JVMTI agent. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run newly developed jtreg test. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Wed Jun 29 04:10:54 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Jun 2016 21:10:54 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <6bde33e5-a8d0-c9ac-cf37-cc7d018d7daa@oracle.com> References: <57725A1C.7060404@oracle.com> <6bde33e5-a8d0-c9ac-cf37-cc7d018d7daa@oracle.com> Message-ID: <57734A4E.9020306@oracle.com> Hi David, Thank you for reviewing! The updated tests just pass the the arguments through as required. It provides sanity checks that both old and new overloaded transform methods works as needed. There are some tricky dependencies among the Jtreg java/lang/instrument test classes that I have to learn to be fluent with these tests. But I've not got there yet. Thanks, Serguei On 6/28/16 18:29, David Holmes wrote: > Hi Serguei, > > Changes look good. Just curious why none of the tests actually do > anything with the Module or ClassLoader arguments? > > Thanks, > David > > On 28/06/2016 9:06 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159147 >> >> >> Jdk webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >> >> >> >> Summary: >> >> As noted in JDK-8155207 >> and elsewhere, one of >> the outstanding items for java.lang.instrument is >> whether the new ClassFileTransformer transform method should provider >> the ClassLoader parameter. >> After further consideration then this seems useful and avoids agents >> needing permissions to invoke Module::getClassLoader. >> The fix is to add the ClassLoader as the second parameter of the >> ClassFileTransformer#transform() method. >> >> This fix also replaces the usage of the JVM_GetModuleByPackageName with >> the JVMTI GetNamedModule in the JPLISAgent.c. >> It is why this fix depends on the fix of the JVMTI enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> and so, must be pushed after the JDK-8159145. >> >> >> Testing: >> Ran the Jtreg java/lang/instrument tests. >> Ran two updated jtreg j.l.i tests: >> java/lang/instrument/RetransformAgent.java >> java/lang/instrument/SingleTransformerTest.java >> >> Thanks, >> Serguei From jesper.wilhelmsson at oracle.com Wed Jun 29 08:45:00 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 29 Jun 2016 10:45:00 +0200 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: 29 juni 2016 kl. 04:30 skrev David Holmes : > >> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>> On 6/28/16 18:44, David Holmes wrote: >>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>> >>>>>>> >>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>> >>>>>> Not sure, what do you mean. >>>>>> Do you mean the generated JVMTI upper layer or the >>>>>> JvmtiEnv::GetNamedModule? >>>>>> Probably, the generated code. >>>>> >>>>> I did mean the generated layer. >>>> >>>> Ok, thanks. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>> parameter >>>>>>> when the jobject does not refer to a "class loader" is >>>>>>> caught >>>>>>> at the upper layer. >>>>>> >>>>>> The upper layer does not check that it is a class loader, just for >>>>>> non-NULL. >>>>>> I think, it is good to have an assert here to double-checks the >>>>>> pre-conditions as other caller can be added later. >>>>>> But I'm Ok to get rid of it if you suggest. >>>>> >>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>> make sure that the asserts could not be reached by user code >>>>> and the "Update:" was to indicate that I did do. >>>> >>>> Ok, thanks. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> L6550: >>>>>>> L6551: >>>>>>> L6552: >>>>>>> L6553: On return, points to a >>>>>>> java.lang.reflect.Module object. >>>>>>> L6554: >>>>>>> L6555: >>>>>>> >>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>> which >>>>>>> is a mismatch with the description. >>>>>> >>>>>> I disagree (or maybe I got it incorrectly). >>>>>> Pointing to NULL and be NULL is different. >>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>> NULL on return. >>>>> >>>>> I think the description needs to be: >>>>> >>>>> On return, points to a java.lang.reflect.Module object >>>>> or points to a NULL. >>>> >>>> Agreed, fixed. >>> >>> Disagree. You would say that a pointer is NULL, not that it points to >>> a NULL. >> >> Why are you disagree? >> The module_ptr is an out argument, it is not allowed to be NULL. >> But the returning value by this pointer can be NULL. > > As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. I would prefer if it said "points to a NULL pointer", or NULL-pointer. I'm not sure what would be the more correct way to write it. Anyway, a NULL pointer is an entity :-) /Jesper > > Thanks, > David > >> >> Thanks, >> Serguei >> >> >>> >>> David >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> >>>>> Dan >>>> >> From serguei.spitsyn at oracle.com Wed Jun 29 08:53:59 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 01:53:59 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> Message-ID: <57738CA7.2080404@oracle.com> On 6/29/16 01:45, Jesper Wilhelmsson wrote: > 29 juni 2016 kl. 04:30 skrev David Holmes : >>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>> On 6/28/16 18:44, David Holmes wrote: >>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>> >>>>>>>> I'll have to check the upper layers of this API, but if an >>>>>>>> agent can pass a bad 'class_loader' parameter and get this >>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>> Not sure, what do you mean. >>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>> JvmtiEnv::GetNamedModule? >>>>>>> Probably, the generated code. >>>>>> I did mean the generated layer. >>>>> Ok, thanks. >>>>> >>>>>> >>>>>>>> Update: Yes, passing a non-NULL jobject as the class_loader >>>>>>>> parameter >>>>>>>> when the jobject does not refer to a "class loader" is >>>>>>>> caught >>>>>>>> at the upper layer. >>>>>>> The upper layer does not check that it is a class loader, just for >>>>>>> non-NULL. >>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>> pre-conditions as other caller can be added later. >>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>> make sure that the asserts could not be reached by user code >>>>>> and the "Update:" was to indicate that I did do. >>>>> Ok, thanks. >>>>> >>>>> >>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> L6550: >>>>>>>> L6551: >>>>>>>> L6552: >>>>>>>> L6553: On return, points to a >>>>>>>> java.lang.reflect.Module object. >>>>>>>> L6554: >>>>>>>> L6555: >>>>>>>> >>>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>>> which >>>>>>>> is a mismatch with the description. >>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>> Pointing to NULL and be NULL is different. >>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>> NULL on return. >>>>>> I think the description needs to be: >>>>>> >>>>>> On return, points to a java.lang.reflect.Module object >>>>>> or points to a NULL. >>>>> Agreed, fixed. >>>> Disagree. You would say that a pointer is NULL, not that it points to >>>> a NULL. >>> Why are you disagree? >>> The module_ptr is an out argument, it is not allowed to be NULL. >>> But the returning value by this pointer can be NULL. >> As per later email I see this terminology already exists so is fine, but I find it confusing to say "points to a NULL" - a NULL is not an entity. If "foo points to a NULL" that implies to me "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo points to nothing. But the "pointer to a pointer" aspect here does confuse things. > I would prefer if it said "points to a NULL pointer", or NULL-pointer. I'm not sure what would be the more correct way to write it. Anyway, a NULL pointer is an entity :-) Jesper, Thank you for the comment. In fact, I've just used a pattern that is already present in the JVMTI spec. Objections to the existing pattern are minor, so it is better to be more conservative here. Thanks, Serguei > /Jesper > > >> Thanks, >> David >> >>> Thanks, >>> Serguei >>> >>> >>>> David >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> Dan From alexander.kulyakhtin at oracle.com Wed Jun 29 12:22:33 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 29 Jun 2016 05:22:33 -0700 (PDT) Subject: RFR:8153978 :New test to verify the modules info as returned by the JVMTI ((re-review) Message-ID: <5b2b105a-d6d2-4615-b6d6-4ae0869927d4@default> Sergey, Could you, please, re-review the new test you have already reviewed and approved before. I had to change Module.empty() to Module.of() due to the changes in the APIs. Otherwise the test is the same as before. 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_3/index.html Best regards, Alexander From daniel.daugherty at oracle.com Wed Jun 29 14:59:06 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Jun 2016 08:59:06 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57738CA7.2080404@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> Message-ID: <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: > On 6/29/16 01:45, Jesper Wilhelmsson wrote: >> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>> if an >>>>>>>>> agent can pass a bad 'class_loader' parameter and get >>>>>>>>> this >>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>> Not sure, what do you mean. >>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>> Probably, the generated code. >>>>>>> I did mean the generated layer. >>>>>> Ok, thanks. >>>>>> >>>>>>> >>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>> class_loader >>>>>>>>> parameter >>>>>>>>> when the jobject does not refer to a "class >>>>>>>>> loader" is >>>>>>>>> caught >>>>>>>>> at the upper layer. >>>>>>>> The upper layer does not check that it is a class loader, just for >>>>>>>> non-NULL. >>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>> pre-conditions as other caller can be added later. >>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>> make sure that the asserts could not be reached by user code >>>>>>> and the "Update:" was to indicate that I did do. >>>>>> Ok, thanks. >>>>>> >>>>>> >>>>>>> >>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>> L6550: >>>>>>>>> L6551: >>>>>>>>> L6552: >>>>>>>>> L6553: On return, points to a >>>>>>>>> java.lang.reflect.Module object. >>>>>>>>> L6554: >>>>>>>>> L6555: >>>>>>>>> >>>>>>>>> The above wording doesn't allow for module_ptr to be NULL >>>>>>>>> which >>>>>>>>> is a mismatch with the description. >>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>>> NULL on return. >>>>>>> I think the description needs to be: >>>>>>> >>>>>>> On return, points to a java.lang.reflect.Module >>>>>>> object >>>>>>> or points to a NULL. >>>>>> Agreed, fixed. >>>>> Disagree. You would say that a pointer is NULL, not that it points to >>>>> a NULL. >>>> Why are you disagree? >>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>> But the returning value by this pointer can be NULL. >>> As per later email I see this terminology already exists so is fine, >>> but I find it confusing to say "points to a NULL" - a NULL is not an >>> entity. If "foo points to a NULL" that implies to me "foo == &NULL;" >>> which is nonsense - foo == NULL, and if foo==NULL then foo points to >>> nothing. But the "pointer to a pointer" aspect here does confuse >>> things. >> I would prefer if it said "points to a NULL pointer", or >> NULL-pointer. I'm not sure what would be the more correct way to >> write it. Anyway, a NULL pointer is an entity :-) > Jesper, > > Thank you for the comment. > In fact, I've just used a pattern that is already present in the JVMTI > spec. > Objections to the existing pattern are minor, so it is better to be > more conservative here. Perhaps we can use the wording in this JVM/TI function as a model: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor This function takes a "jobject *" as a parameter and returns a monitor pointer via that parameter. Pretty similar to what we're discussing... So here's the existing wording example: Name Type Description =========== ======== =========== monitor_ptr jobject* On return, filled with the current contended monitor, or NULL if there is none. Agent passes a pointer to a jobject. On return, the jobject has been set. The object returned by monitor_ptr is a JNI local reference and must be managed. So for the new function: module_ptr jobject* On return, filled with a java.lang.reflect.Module object or NULL if there is none. This "filled with" style is used for return parameters in ~13 places in the JVM/TI spec. Of course, now that I've found the GetCurrentContendedMonitor example, That second paragraph or something like it is also going to be needed with our new function... Spec wording is very difficult... :-) Dan > > Thanks, > Serguei > > > >> /Jesper >> >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> Dan > From dmitry.samersoff at oracle.com Wed Jun 29 16:12:25 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Jun 2016 19:12:25 +0300 Subject: RFR(S): JDK-8159925 sun/tools/jps/TestJpsJar.java still fails after fix for JDK-8153278 Message-ID: <0832dc3b-1fd6-82d1-b9d3-d7b8c1345c8e@oracle.com> Everybody, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8159925/webrev.01/ The problem: If you run the test from symlinked location user.dir and the output of jps -l may not match to the value returned by File.getAbsolutePath() for the same jar file. Solution: Skip the test if user.dir doesn't match File.getAbsolutePath() -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 Jun 29 19:45:17 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 12:45:17 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <57725A1C.7060404@oracle.com> References: <57725A1C.7060404@oracle.com> Message-ID: <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> > On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: > > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159147 > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ > ClassFileTransformer.java Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined?s class loader != loader or module?s class loader != loader? 209 * @implSpec The default implementation of this method invokes the 210 * {@link #transform(ClassLoader,String,Class,ProtectionDomain,byte[]) transform} 211 * method with the {@link Module#getClassLoader() ClassLoader} for the module. This @implSpec needs update - no longer call Module::getClassLoader. 215 * may be null if the bootstrap loader Nit: replace with {@code null} Other than above, looks fine. Mandy From serguei.spitsyn at oracle.com Wed Jun 29 22:47:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 15:47:25 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> References: <57725A1C.7060404@oracle.com> <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> Message-ID: <57744FFD.9030009@oracle.com> Hi Mandy, Thank you for the review and comments. Nice catch on the @impleSpec. I'll make the changes. Thanks, Serguei On 6/29/16 12:45, Mandy Chung wrote: >> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: >> >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159147 >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >> > ClassFileTransformer.java > > Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined?s class loader != loader or module?s class loader != loader? > > 209 * @implSpec The default implementation of this method invokes the > 210 * {@link #transform(ClassLoader,String,Class,ProtectionDomain,byte[]) transform} > 211 * method with the {@link Module#getClassLoader() ClassLoader} for the module. > > This @implSpec needs update - no longer call Module::getClassLoader. > > 215 * may be null if the bootstrap loader > > Nit: replace with {@code null} > > Other than above, looks fine. > > Mandy > From serguei.spitsyn at oracle.com Wed Jun 29 23:39:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 16:39:05 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <57744FFD.9030009@oracle.com> References: <57725A1C.7060404@oracle.com> <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> <57744FFD.9030009@oracle.com> Message-ID: <57745C19.7050806@oracle.com> On 6/29/16 15:47, serguei.spitsyn at oracle.com wrote: > Hi Mandy, > > Thank you for the review and comments. > Nice catch on the @impleSpec. > I'll make the changes. > > Thanks, > Serguei > > > On 6/29/16 12:45, Mandy Chung wrote: >>> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Please, review the Jigsaw fix for the enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8159147 >>> >>> >>> Jdk webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >>> >> ClassFileTransformer.java >> >> Should the given loader parameter require to be the same as >> Module::getClassLoader? What happens if classBeingRedefined?s class >> loader != loader or module?s class loader != loader? I forgot to answer this question, sorry. The ClassFileTransformer.transform() method should not be called by the user. It is called from the JPLIS implementation, so that, the loader must be correct. Not sure, if the references are equal but the referenced by the loader parameter ClassLoader object must be the same as returned by the Module::getClassLoader(). Do you think we may have a spec problem here? Thanks, Serguei >> >> 209 * @implSpec The default implementation of this method >> invokes the >> 210 * {@link >> #transform(ClassLoader,String,Class,ProtectionDomain,byte[]) transform} >> 211 * method with the {@link Module#getClassLoader() >> ClassLoader} for the module. >> >> This @implSpec needs update - no longer call Module::getClassLoader. >> >> 215 * may be null if the bootstrap loader >> >> Nit: replace with {@code null} >> >> Other than above, looks fine. >> >> Mandy > From mandy.chung at oracle.com Thu Jun 30 00:12:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 17:12:29 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <57745C19.7050806@oracle.com> References: <57725A1C.7060404@oracle.com> <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> <57744FFD.9030009@oracle.com> <57745C19.7050806@oracle.com> Message-ID: <2ECE4ED7-7044-42B9-A95A-9ED3F981DA37@oracle.com> > On Jun 29, 2016, at 4:39 PM, serguei.spitsyn at oracle.com wrote: > > On 6/29/16 15:47, serguei.spitsyn at oracle.com wrote: >> Hi Mandy, >> >> Thank you for the review and comments. >> Nice catch on the @impleSpec. >> I'll make the changes. >> >> Thanks, >> Serguei >> >> >> On 6/29/16 12:45, Mandy Chung wrote: >>>> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: >>>> >>>> Please, review the Jigsaw fix for the enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8159147 >>>> >>>> >>>> Jdk webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >>>> >>> ClassFileTransformer.java >>> >>> Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined?s class loader != loader or module?s class loader != loader? > > I forgot to answer this question, sorry. > > The ClassFileTransformer.transform() method should not be called by the user. > It is called from the JPLIS implementation, so that, the loader must be correct. > Not sure, if the references are equal but the referenced by the loader parameter > ClassLoader object must be the same as returned by the Module::getClassLoader(). > > Do you think we may have a spec problem here? Re-reading it, I think it?s fine. The caller to the transform method has to conform to the spec and supply the right loader. Mandy From serguei.spitsyn at oracle.com Thu Jun 30 00:14:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 17:14:25 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <2ECE4ED7-7044-42B9-A95A-9ED3F981DA37@oracle.com> References: <57725A1C.7060404@oracle.com> <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> <57744FFD.9030009@oracle.com> <57745C19.7050806@oracle.com> <2ECE4ED7-7044-42B9-A95A-9ED3F981DA37@oracle.com> Message-ID: <57746461.30105@oracle.com> On 6/29/16 17:12, Mandy Chung wrote: >> On Jun 29, 2016, at 4:39 PM, serguei.spitsyn at oracle.com wrote: >> >> On 6/29/16 15:47, serguei.spitsyn at oracle.com wrote: >>> Hi Mandy, >>> >>> Thank you for the review and comments. >>> Nice catch on the @impleSpec. >>> I'll make the changes. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/29/16 12:45, Mandy Chung wrote: >>>>> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159147 >>>>> >>>>> >>>>> Jdk webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >>>>> >>>> ClassFileTransformer.java >>>> >>>> Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined?s class loader != loader or module?s class loader != loader? >> I forgot to answer this question, sorry. >> >> The ClassFileTransformer.transform() method should not be called by the user. >> It is called from the JPLIS implementation, so that, the loader must be correct. >> Not sure, if the references are equal but the referenced by the loader parameter >> ClassLoader object must be the same as returned by the Module::getClassLoader(). >> >> Do you think we may have a spec problem here? > Re-reading it, I think it?s fine. The caller to the transform method has to conform to the spec and supply the right loader. Ok. Thanks, Mandy! Serguei > > Mandy From serguei.spitsyn at oracle.com Thu Jun 30 00:21:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 17:21:46 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> Message-ID: <5774661A.3080500@oracle.com> Hi Dan, On 6/29/16 07:59, Daniel D. Daugherty wrote: > On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>>> if an >>>>>>>>>> agent can pass a bad 'class_loader' parameter and get >>>>>>>>>> this >>>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>> Not sure, what do you mean. >>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>> Probably, the generated code. >>>>>>>> I did mean the generated layer. >>>>>>> Ok, thanks. >>>>>>> >>>>>>>> >>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>> class_loader >>>>>>>>>> parameter >>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>> loader" is >>>>>>>>>> caught >>>>>>>>>> at the upper layer. >>>>>>>>> The upper layer does not check that it is a class loader, just >>>>>>>>> for >>>>>>>>> non-NULL. >>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>> Ok, thanks. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>> L6550: >>>>>>>>>> L6551: >>>>>>>>>> L6552: >>>>>>>>>> L6553: On return, points to a >>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>> L6554: >>>>>>>>>> L6555: >>>>>>>>>> >>>>>>>>>> The above wording doesn't allow for module_ptr to be >>>>>>>>>> NULL >>>>>>>>>> which >>>>>>>>>> is a mismatch with the description. >>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to pint to >>>>>>>>> NULL on return. >>>>>>>> I think the description needs to be: >>>>>>>> >>>>>>>> On return, points to a >>>>>>>> java.lang.reflect.Module object >>>>>>>> or points to a NULL. >>>>>>> Agreed, fixed. >>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>> points to >>>>>> a NULL. >>>>> Why are you disagree? >>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>> But the returning value by this pointer can be NULL. >>>> As per later email I see this terminology already exists so is >>>> fine, but I find it confusing to say "points to a NULL" - a NULL is >>>> not an entity. If "foo points to a NULL" that implies to me "foo == >>>> &NULL;" which is nonsense - foo == NULL, and if foo==NULL then foo >>>> points to nothing. But the "pointer to a pointer" aspect here does >>>> confuse things. >>> I would prefer if it said "points to a NULL pointer", or >>> NULL-pointer. I'm not sure what would be the more correct way to >>> write it. Anyway, a NULL pointer is an entity :-) >> Jesper, >> >> Thank you for the comment. >> In fact, I've just used a pattern that is already present in the >> JVMTI spec. >> Objections to the existing pattern are minor, so it is better to be >> more conservative here. > > Perhaps we can use the wording in this JVM/TI function as a model: > > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor > > > This function takes a "jobject *" as a parameter and returns a > monitor pointer via that parameter. Pretty similar to what we're > discussing... > > So here's the existing wording example: > > Name Type Description > =========== ======== =========== > monitor_ptr jobject* On return, filled with the current contended > monitor, > or NULL if there is none. > > Agent passes a pointer to a jobject. On return, > the > jobject has been set. The object returned by > monitor_ptr > is a JNI local reference and must be managed. > > So for the new function: > > module_ptr jobject* On return, filled with a > java.lang.reflect.Module > object or NULL if there is none. > > This "filled with" style is used for return parameters in > ~13 places in the JVM/TI spec. Thank you for pointing to the example. This discussion deviated to the question what the JVMTI pattern is better to copy as a best practice. > > Of course, now that I've found the GetCurrentContendedMonitor > example, That second paragraph or something like it is also > going to be needed with our new function... Just wanted to note that this paragraph is not strictly necessary as it is already covered in the common part of the spec: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs However, the second sentence is auto-generated from the jvmti.xml: "Agent passes a pointer to a |jobject|. On return, the |jobject| has been set. The object returned by |module_ptr| is a JNI local reference and must be managed." Please, find the specdiff in the attachment. Thanks, Serguei > > Spec wording is very difficult... :-) > > Dan > > >> >> Thanks, >> Serguei >> >> >> >>> /Jesper >>> >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Dan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jvmti-specdiff.zip Type: application/zip Size: 257126 bytes Desc: not available URL: From daniel.daugherty at oracle.com Thu Jun 30 02:07:03 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Jun 2016 20:07:03 -0600 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <5774661A.3080500@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> Message-ID: <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> On 6/29/16 6:21 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > On 6/29/16 07:59, Daniel D. Daugherty wrote: >> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >>> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll have to check the upper layers of this API, but >>>>>>>>>>> if an >>>>>>>>>>> agent can pass a bad 'class_loader' parameter and >>>>>>>>>>> get this >>>>>>>>>>> assert() to fire, then that's not good. Hopefully a bad >>>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>>> Not sure, what do you mean. >>>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>>> Probably, the generated code. >>>>>>>>> I did mean the generated layer. >>>>>>>> Ok, thanks. >>>>>>>> >>>>>>>>> >>>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>>> class_loader >>>>>>>>>>> parameter >>>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>>> loader" is >>>>>>>>>>> caught >>>>>>>>>>> at the upper layer. >>>>>>>>>> The upper layer does not check that it is a class loader, >>>>>>>>>> just for >>>>>>>>>> non-NULL. >>>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>>> Ok, thanks. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>> L6550: >>>>>>>>>>> L6551: >>>>>>>>>>> L6552: >>>>>>>>>>> L6553: On return, points to a >>>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>>> L6554: >>>>>>>>>>> L6555: >>>>>>>>>>> >>>>>>>>>>> The above wording doesn't allow for module_ptr to be >>>>>>>>>>> NULL >>>>>>>>>>> which >>>>>>>>>>> is a mismatch with the description. >>>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to >>>>>>>>>> pint to >>>>>>>>>> NULL on return. >>>>>>>>> I think the description needs to be: >>>>>>>>> >>>>>>>>> On return, points to a >>>>>>>>> java.lang.reflect.Module object >>>>>>>>> or points to a NULL. >>>>>>>> Agreed, fixed. >>>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>>> points to >>>>>>> a NULL. >>>>>> Why are you disagree? >>>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>>> But the returning value by this pointer can be NULL. >>>>> As per later email I see this terminology already exists so is >>>>> fine, but I find it confusing to say "points to a NULL" - a NULL >>>>> is not an entity. If "foo points to a NULL" that implies to me >>>>> "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL >>>>> then foo points to nothing. But the "pointer to a pointer" aspect >>>>> here does confuse things. >>>> I would prefer if it said "points to a NULL pointer", or >>>> NULL-pointer. I'm not sure what would be the more correct way to >>>> write it. Anyway, a NULL pointer is an entity :-) >>> Jesper, >>> >>> Thank you for the comment. >>> In fact, I've just used a pattern that is already present in the >>> JVMTI spec. >>> Objections to the existing pattern are minor, so it is better to be >>> more conservative here. >> >> Perhaps we can use the wording in this JVM/TI function as a model: >> >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor >> >> >> This function takes a "jobject *" as a parameter and returns a >> monitor pointer via that parameter. Pretty similar to what we're >> discussing... >> >> So here's the existing wording example: >> >> Name Type Description >> =========== ======== =========== >> monitor_ptr jobject* On return, filled with the current contended >> monitor, >> or NULL if there is none. >> >> Agent passes a pointer to a jobject. On >> return, the >> jobject has been set. The object returned by >> monitor_ptr >> is a JNI local reference and must be managed. >> >> So for the new function: >> >> module_ptr jobject* On return, filled with a >> java.lang.reflect.Module >> object or NULL if there is none. >> >> This "filled with" style is used for return parameters in >> ~13 places in the JVM/TI spec. > > Thank you for pointing to the example. > This discussion deviated to the question what the JVMTI pattern is > better to copy as a best practice. > > >> >> Of course, now that I've found the GetCurrentContendedMonitor >> example, That second paragraph or something like it is also >> going to be needed with our new function... > > Just wanted to note that this paragraph is not strictly necessary as > it is already covered in the common part of the spec: > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs > > However, the second sentence is auto-generated from the jvmti.xml: > "Agent passes a pointer to a |jobject|. On return, the |jobject| > has been set. > The object returned by |module_ptr| is a JNI local reference and must > be managed." > > Please, find the specdiff in the attachment. The specdiff looks good. There is one strange sentence: > If class_loader is NULL, the bootstrap loader. Perhaps "the bootstrap loader is assumed."? Your call. Dan > > Thanks, > Serguei > >> >> Spec wording is very difficult... :-) >> >> Dan >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>>> /Jesper >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Dan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jun 30 03:34:09 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 20:34:09 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> References: <5771F834.2020504@oracle.com> <5771FB19.20009@oracle.com> <1ed085dc-a361-cc27-adae-f10e84c81086@oracle.com> <57723B57.2010605@oracle.com> <41c13f62-5742-7ef7-4036-902ca34780f2@oracle.com> <5772A7CB.6070007@oracle.com> <4c5fe6b4-f2d5-3357-0fdb-9fd45e849038@oracle.com> <5772D9FE.5030804@oracle.com> <9d8f7b6a-0495-4b6c-104c-95a21428d6b7@oracle.com> <5772E79F.3040504@oracle.com> <57732DDF.4070904@oracle.com> <57738CA7.2080404@oracle.com> <4edd4611-6e6b-d61d-22c4-c099f02db2d8@oracle.com> <5774661A.3080500@oracle.com> <263e1aac-5876-111b-0ee8-7ea5a3f9d883@oracle.com> Message-ID: <57749331.2030701@oracle.com> On 6/29/16 19:07, Daniel D. Daugherty wrote: > On 6/29/16 6:21 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> On 6/29/16 07:59, Daniel D. Daugherty wrote: >>> On 6/29/16 2:53 AM, serguei.spitsyn at oracle.com wrote: >>>> On 6/29/16 01:45, Jesper Wilhelmsson wrote: >>>>> 29 juni 2016 kl. 04:30 skrev David Holmes : >>>>>>> On 29/06/2016 12:09 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 6/28/16 18:44, David Holmes wrote: >>>>>>>>> On 29/06/2016 7:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> On 6/28/16 14:02, Daniel D. Daugherty wrote: >>>>>>>>>>> On 6/28/16 2:11 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> On 6/28/16 11:19, Daniel D. Daugherty wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'll have to check the upper layers of this API, >>>>>>>>>>>> but if an >>>>>>>>>>>> agent can pass a bad 'class_loader' parameter and >>>>>>>>>>>> get this >>>>>>>>>>>> assert() to fire, then that's not good. Hopefully a >>>>>>>>>>>> bad >>>>>>>>>>>> 'class_loader' parameter is caught at a higher layer. >>>>>>>>>>> Not sure, what do you mean. >>>>>>>>>>> Do you mean the generated JVMTI upper layer or the >>>>>>>>>>> JvmtiEnv::GetNamedModule? >>>>>>>>>>> Probably, the generated code. >>>>>>>>>> I did mean the generated layer. >>>>>>>>> Ok, thanks. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Update: Yes, passing a non-NULL jobject as the >>>>>>>>>>>> class_loader >>>>>>>>>>>> parameter >>>>>>>>>>>> when the jobject does not refer to a "class >>>>>>>>>>>> loader" is >>>>>>>>>>>> caught >>>>>>>>>>>> at the upper layer. >>>>>>>>>>> The upper layer does not check that it is a class loader, >>>>>>>>>>> just for >>>>>>>>>>> non-NULL. >>>>>>>>>>> I think, it is good to have an assert here to double-checks the >>>>>>>>>>> pre-conditions as other caller can be added later. >>>>>>>>>>> But I'm Ok to get rid of it if you suggest. >>>>>>>>>> Please keep the asserts. Basically I was mumbling to myself to >>>>>>>>>> make sure that the asserts could not be reached by user code >>>>>>>>>> and the "Update:" was to indicate that I did do. >>>>>>>>> Ok, thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>>> L6550: >>>>>>>>>>>> L6551: >>>>>>>>>>>> L6552: >>>>>>>>>>>> L6553: On return, points to a >>>>>>>>>>>> java.lang.reflect.Module object. >>>>>>>>>>>> L6554: >>>>>>>>>>>> L6555: >>>>>>>>>>>> >>>>>>>>>>>> The above wording doesn't allow for module_ptr to >>>>>>>>>>>> be NULL >>>>>>>>>>>> which >>>>>>>>>>>> is a mismatch with the description. >>>>>>>>>>> I disagree (or maybe I got it incorrectly). >>>>>>>>>>> Pointing to NULL and be NULL is different. >>>>>>>>>>> It is not allowed for the module_ptr to be NULL but Ok to >>>>>>>>>>> pint to >>>>>>>>>>> NULL on return. >>>>>>>>>> I think the description needs to be: >>>>>>>>>> >>>>>>>>>> On return, points to a >>>>>>>>>> java.lang.reflect.Module object >>>>>>>>>> or points to a NULL. >>>>>>>>> Agreed, fixed. >>>>>>>> Disagree. You would say that a pointer is NULL, not that it >>>>>>>> points to >>>>>>>> a NULL. >>>>>>> Why are you disagree? >>>>>>> The module_ptr is an out argument, it is not allowed to be NULL. >>>>>>> But the returning value by this pointer can be NULL. >>>>>> As per later email I see this terminology already exists so is >>>>>> fine, but I find it confusing to say "points to a NULL" - a NULL >>>>>> is not an entity. If "foo points to a NULL" that implies to me >>>>>> "foo == &NULL;" which is nonsense - foo == NULL, and if foo==NULL >>>>>> then foo points to nothing. But the "pointer to a pointer" aspect >>>>>> here does confuse things. >>>>> I would prefer if it said "points to a NULL pointer", or >>>>> NULL-pointer. I'm not sure what would be the more correct way to >>>>> write it. Anyway, a NULL pointer is an entity :-) >>>> Jesper, >>>> >>>> Thank you for the comment. >>>> In fact, I've just used a pattern that is already present in the >>>> JVMTI spec. >>>> Objections to the existing pattern are minor, so it is better to be >>>> more conservative here. >>> >>> Perhaps we can use the wording in this JVM/TI function as a model: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#GetCurrentContendedMonitor >>> >>> >>> This function takes a "jobject *" as a parameter and returns a >>> monitor pointer via that parameter. Pretty similar to what we're >>> discussing... >>> >>> So here's the existing wording example: >>> >>> Name Type Description >>> =========== ======== =========== >>> monitor_ptr jobject* On return, filled with the current contended >>> monitor, >>> or NULL if there is none. >>> >>> Agent passes a pointer to a jobject. On >>> return, the >>> jobject has been set. The object returned by >>> monitor_ptr >>> is a JNI local reference and must be managed. >>> >>> So for the new function: >>> >>> module_ptr jobject* On return, filled with a >>> java.lang.reflect.Module >>> object or NULL if there is none. >>> >>> This "filled with" style is used for return parameters in >>> ~13 places in the JVM/TI spec. >> >> Thank you for pointing to the example. >> This discussion deviated to the question what the JVMTI pattern is >> better to copy as a best practice. >> >> >>> >>> Of course, now that I've found the GetCurrentContendedMonitor >>> example, That second paragraph or something like it is also >>> going to be needed with our new function... >> >> Just wanted to note that this paragraph is not strictly necessary as >> it is already covered in the common part of the spec: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#refs >> >> However, the second sentence is auto-generated from the jvmti.xml: >> "Agent passes a pointer to a |jobject|. On return, the |jobject| >> has been set. >> The object returned by |module_ptr| is a JNI local reference and must >> be managed." >> >> Please, find the specdiff in the attachment. > > The specdiff looks good. > > There is one strange sentence: > > > If class_loader is NULL, the bootstrap loader. > > Perhaps "the bootstrap loader is assumed."? > > Your call. Interesting that a part of this sentence is auto-generated. Fixed it, thanks! Thanks, Serguei > > Dan > >> >> Thanks, >> Serguei >> >>> >>> Spec wording is very difficult... :-) >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>>> /Jesper >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jun 30 03:50:32 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 20:50:32 -0700 Subject: Jigsaw Enhancement RFR round #1: 8156147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <2ECE4ED7-7044-42B9-A95A-9ED3F981DA37@oracle.com> References: <57725A1C.7060404@oracle.com> <794C842D-2717-4D4A-BB8D-EFAF6DB3F0EE@oracle.com> <57744FFD.9030009@oracle.com> <57745C19.7050806@oracle.com> <2ECE4ED7-7044-42B9-A95A-9ED3F981DA37@oracle.com> Message-ID: <57749708.30004@oracle.com> It occurred the bug id in subject has a typo: 8156147 => 8159147. I will send the RFR round #2 with the correct bug id. Thanks, Serguei On 6/29/16 17:12, Mandy Chung wrote: >> On Jun 29, 2016, at 4:39 PM, serguei.spitsyn at oracle.com wrote: >> >> On 6/29/16 15:47, serguei.spitsyn at oracle.com wrote: >>> Hi Mandy, >>> >>> Thank you for the review and comments. >>> Nice catch on the @impleSpec. >>> I'll make the changes. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 6/29/16 12:45, Mandy Chung wrote: >>>>> On Jun 28, 2016, at 4:06 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Please, review the Jigsaw fix for the enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8159147 >>>>> >>>>> >>>>> Jdk webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk1/ >>>>> >>>> ClassFileTransformer.java >>>> >>>> Should the given loader parameter require to be the same as Module::getClassLoader? What happens if classBeingRedefined?s class loader != loader or module?s class loader != loader? >> I forgot to answer this question, sorry. >> >> The ClassFileTransformer.transform() method should not be called by the user. >> It is called from the JPLIS implementation, so that, the loader must be correct. >> Not sure, if the references are equal but the referenced by the loader parameter >> ClassLoader object must be the same as returned by the Module::getClassLoader(). >> >> Do you think we may have a spec problem here? > Re-reading it, I think it?s fine. The caller to the transform method has to conform to the spec and supply the right loader. > > Mandy From serguei.spitsyn at oracle.com Thu Jun 30 06:57:28 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Jun 2016 23:57:28 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159147 Add ClassLoader parameter to new ClassFileTransformer transform method Message-ID: <5774C2D8.9090105@oracle.com> Please, review the Jigsaw fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8159147 Just a sanity check is needed. This update has fixes related to the Mandy's comments on the ClassFileTransformer.java: - one of the @implSpec statements is corrected - null has been replaced with {@code null} Jdk webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk2/ Summary: As noted in JDK-8155207 and elsewhere, one of the outstanding items for java.lang.instrument is whether the new ClassFileTransformer transform method should provider the ClassLoader parameter. After further consideration then this seems useful and avoids agents needing permissions to invoke Module::getClassLoader. The fix is to add the ClassLoader as the second parameter of the ClassFileTransformer#transform() method. This fix also replaces the usage of the JVM_GetModuleByPackageName with the JVMTI GetNamedModule in the JPLISAgent.c. It is why this fix depends on the fix of the JVMTI enhancement: https://bugs.openjdk.java.net/browse/JDK-8159145 and so, must be pushed after the JDK-8159145. Testing: Ran the Jtreg java/lang/instrument tests. Ran two updated jtreg j.l.i tests: java/lang/instrument/RetransformAgent.java java/lang/instrument/SingleTransformerTest.java Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Thu Jun 30 09:31:50 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 30 Jun 2016 18:31:50 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> References: <56FBDE2F.60701@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> Message-ID: Hi Marcus, >> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. Ah, I understood. If we refactor that in this enhancement, we do not need to make dynamic memory allocation. I uploaded a new webrev. I hope this webrev matches your suggestion :-) http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ Thanks, Yasumasa On 2016/06/28 22:21, Yasumasa Suenaga wrote: > Hi Marcus, > >> I don't really like that we need to make dynamic allocations here. > > Should use resource area? or char array? > If we should use char array, how long should we reserve for buffer? > > >> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. > > I think this is refactoring of LogOutput and LogConfiguration. > Now (after FC date), is this work accepted? > > IMHO, refactoring is another enhancement from this. > If it is needed, I think this enhancement should be started after > refactoring. > > > If refactoring and this enhancement can be merged and be accepted, > I will start to work for it. > > > Thanks, > > Yasumasa > > > On 2016/06/28 20:23, Marcus Larsson wrote: >> Hi, >> >> >> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >> >> I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >> >> Thanks, >> Marcus >> >>> >>> I've requested FC extension for this. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/13 13:24, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> Thank you for your comment. >>>>> >>>>>> So options are a distinct property of outputs and so should have been >>>>>> a first class entity in LogOutput all along. >>>>> >>>>> I agree to you. >>>>> But I think we need to discuss about it with logging folks. >>>>> >>>>> I uploaded a new webrev. It removes fixed buffer length and changes the >>>>> order of output. >>>>> Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>> >>>> It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. >>>> >>>> Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? >>>> >>>> Lets wait for other feedback before going further. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I think "config_string" is different from "option_string". >>>>>>> >>>>>>> -Xlog format (from -Xlog:help message): >>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>> >>>>>>> config_string: "what" (ex. gc=trace) >>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>> >>>>>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>>>>> It does not contain output options. >>>>>> >>>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>>> overall logging configuration we might have, for example: >>>>>> >>>>>> gc=trace -> stdout >>>>>> runtime=info -> fileA >>>>>> compiler=trace -> fileB >>>>>> >>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>> output. So for each output we set its "configuration" to the >>>>>> associated LHS. >>>>>> >>>>>> So options are a distinct property of outputs and so should have been >>>>>> a first class entity in LogOutput all along. >>>>>> >>>>>> Okay so looking at your v4 I have two comments: >>>>>> >>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>>>>> are so don't know if 100 is adequate. >>>>>> >>>>>> Second, if the logging syntax is: >>>>>> >>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>> >>>>>> then shouldn't the configuration be printed in the same order/format? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for your comment. >>>>>>>>> >>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>> part of >>>>>>>>>> the existing configuration string? >>>>>>>>> >>>>>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>>>>> (See webrev.01). >>>>>>>>> Marcus commented that option string should be generated from current >>>>>>>>> configuration. >>>>>>>>> >>>>>>>>> I uploaded new webrev. >>>>>>>>> Could you review again? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>> >>>>>>>> Sorry but I repeat my question - why is the option information not >>>>>>>> simply part of the config_string? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>>>>> actually needs to implement. >>>>>>>>>> >>>>>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>>>>> - we >>>>>>>>>> have getters for all the other "properties" which are then printed by >>>>>>>>>> the describe_current_configuration method. But this is instead a >>>>>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>>>>> two styles seems messy. It probably would have been better to have >>>>>>>>>> had >>>>>>>>>> a print-style API from the start - then adding the options would have >>>>>>>>>> been a trivial extension for those output classes with options. >>>>>>>>>> >>>>>>>>>> In addition the change you made to describe_current_configuration is >>>>>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>>>>> the config string and the decorators) for this one class and so you >>>>>>>>>> added the code to support that format. But that format may not make >>>>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>>>> >>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>> part of >>>>>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>>>>> "2015, 2016,". >>>>>>>>>> >>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> PING: Could you review it? >>>>>>>>>>> We need a second reviewer. >>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>> 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 marcus.larsson at oracle.com Thu Jun 30 09:38:33 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 30 Jun 2016 11:38:33 +0200 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@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> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> Message-ID: Hi, On 2016-06-30 11:31, Yasumasa Suenaga wrote: > Hi Marcus, > >>> Therefore I suggest that we introduce a describe() function in >>> LogOutput as part of this change, and move the code currently in >>> LogConfiguration::describe to this function, adding the option text >>> to it as well. > > Ah, I understood. > If we refactor that in this enhancement, we do not need to make > dynamic memory allocation. > > I uploaded a new webrev. > I hope this webrev matches your suggestion :-) > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ Looks good! Just a nit: Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.) Thanks, Marcus > > > Thanks, > > Yasumasa > > > On 2016/06/28 22:21, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>> I don't really like that we need to make dynamic allocations here. >> >> Should use resource area? or char array? >> If we should use char array, how long should we reserve for buffer? >> >> >>> Therefore I suggest that we introduce a describe() function in >>> LogOutput as part of this change, and move the code currently in >>> LogConfiguration::describe to this function, adding the option text >>> to it as well. >> >> I think this is refactoring of LogOutput and LogConfiguration. >> Now (after FC date), is this work accepted? >> >> IMHO, refactoring is another enhancement from this. >> If it is needed, I think this enhancement should be started after >> refactoring. >> >> >> If refactoring and this enhancement can be merged and be accepted, >> I will start to work for it. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/28 20:23, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>> >>> I don't really like that we need to make dynamic allocations here. I >>> would prefer to have the outputs be responsible for describing >>> themselves just like David mentions. The current design of >>> LogConfiguration::describe doesn't follow that pattern, but I really >>> think it should. Therefore I suggest that we introduce a describe() >>> function in LogOutput as part of this change, and move the code >>> currently in LogConfiguration::describe to this function, adding the >>> option text to it as well. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> I've requested FC extension for this. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/13 13:24, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for your comment. >>>>>> >>>>>>> So options are a distinct property of outputs and so should have >>>>>>> been >>>>>>> a first class entity in LogOutput all along. >>>>>> >>>>>> I agree to you. >>>>>> But I think we need to discuss about it with logging folks. >>>>>> >>>>>> I uploaded a new webrev. It removes fixed buffer length and >>>>>> changes the >>>>>> order of output. >>>>>> Could you review again? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>> >>>>> It's okay to wait and hear what opinions others may have before >>>>> changing things based on my comments. :) The fixed buffer may be >>>>> okay - as I said I don't know what the potential options are, so >>>>> don't know if it is okay or not. >>>>> >>>>> Using dynamic allocation avoids that but raises other concerns - >>>>> like calling vm_exit_on_out_of_memory on failure; or whether to >>>>> use malloc or resource area? >>>>> >>>>> Lets wait for other feedback before going further. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I think "config_string" is different from "option_string". >>>>>>>> >>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>> >>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>> >>>>>>>> Currently, LogOutput handles tags and loglevels only as >>>>>>>> config_string. >>>>>>>> It does not contain output options. >>>>>>> >>>>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>>>> overall logging configuration we might have, for example: >>>>>>> >>>>>>> gc=trace -> stdout >>>>>>> runtime=info -> fileA >>>>>>> compiler=trace -> fileB >>>>>>> >>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>> output. So for each output we set its "configuration" to the >>>>>>> associated LHS. >>>>>>> >>>>>>> So options are a distinct property of outputs and so should have >>>>>>> been >>>>>>> a first class entity in LogOutput all along. >>>>>>> >>>>>>> Okay so looking at your v4 I have two comments: >>>>>>> >>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible >>>>>>> options >>>>>>> are so don't know if 100 is adequate. >>>>>>> >>>>>>> Second, if the logging syntax is: >>>>>>> >>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>> >>>>>>> then shouldn't the configuration be printed in the same >>>>>>> order/format? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for your comment. >>>>>>>>>> >>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>> part of >>>>>>>>>>> the existing configuration string? >>>>>>>>>> >>>>>>>>>> My first proposal keeps option string at LogOutput and its >>>>>>>>>> child class >>>>>>>>>> (See webrev.01). >>>>>>>>>> Marcus commented that option string should be generated from >>>>>>>>>> current >>>>>>>>>> configuration. >>>>>>>>>> >>>>>>>>>> I uploaded new webrev. >>>>>>>>>> Could you review again? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>> >>>>>>>>> Sorry but I repeat my question - why is the option information >>>>>>>>> not >>>>>>>>> simply part of the config_string? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>> print_option_string seems the wrong name given that the base >>>>>>>>>>> class, >>>>>>>>>>> LogOutput, has no notion of having an "option string". It >>>>>>>>>>> seems to be >>>>>>>>>>> a supposedly generic "print other stuff" function that only >>>>>>>>>>> one class >>>>>>>>>>> actually needs to implement. >>>>>>>>>>> >>>>>>>>>>> Secondly it inverts the style of the API used for everything >>>>>>>>>>> else >>>>>>>>>>> - we >>>>>>>>>>> have getters for all the other "properties" which are then >>>>>>>>>>> printed by >>>>>>>>>>> the describe_current_configuration method. But this is >>>>>>>>>>> instead a >>>>>>>>>>> "print" function where we ask the target to print itself. >>>>>>>>>>> Mixing the >>>>>>>>>>> two styles seems messy. It probably would have been better >>>>>>>>>>> to have >>>>>>>>>>> had >>>>>>>>>>> a print-style API from the start - then adding the options >>>>>>>>>>> would have >>>>>>>>>>> been a trivial extension for those output classes with options. >>>>>>>>>>> >>>>>>>>>>> In addition the change you made to >>>>>>>>>>> describe_current_configuration is >>>>>>>>>>> not at all general purpose - you wanted a given format >>>>>>>>>>> (print between >>>>>>>>>>> the config string and the decorators) for this one class and >>>>>>>>>>> so you >>>>>>>>>>> added the code to support that format. But that format may >>>>>>>>>>> not make >>>>>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>>>>> >>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>> part of >>>>>>>>>>> the existing configuration string? It seems to me that for a >>>>>>>>>>> LogFile >>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> PS. The two hpp files would need their copyright years >>>>>>>>>>> updated to >>>>>>>>>>> "2015, 2016,". >>>>>>>>>>> >>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>> 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 yasuenag at gmail.com Thu Jun 30 13:01:09 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 30 Jun 2016 22:01:09 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@gmail.com> <1f7489b4-779d-bf65-0e5e-d4ec88eb680c@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> Message-ID: <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> Hi Marcus, > Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.) I've fixed it. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/ Thanks, Yasumasa On 2016/06/30 18:38, Marcus Larsson wrote: > Hi, > > > On 2016-06-30 11:31, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >> >> Ah, I understood. >> If we refactor that in this enhancement, we do not need to make dynamic memory allocation. >> >> I uploaded a new webrev. >> I hope this webrev matches your suggestion :-) >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ > > Looks good! Just a nit: Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.) > > Thanks, > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/28 22:21, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>> I don't really like that we need to make dynamic allocations here. >>> >>> Should use resource area? or char array? >>> If we should use char array, how long should we reserve for buffer? >>> >>> >>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >>> >>> I think this is refactoring of LogOutput and LogConfiguration. >>> Now (after FC date), is this work accepted? >>> >>> IMHO, refactoring is another enhancement from this. >>> If it is needed, I think this enhancement should be started after >>> refactoring. >>> >>> >>> If refactoring and this enhancement can be merged and be accepted, >>> I will start to work for it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/28 20:23, Marcus Larsson wrote: >>>> Hi, >>>> >>>> >>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>> >>>> I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> I've requested FC extension for this. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/13 13:24, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for your comment. >>>>>>> >>>>>>>> So options are a distinct property of outputs and so should have been >>>>>>>> a first class entity in LogOutput all along. >>>>>>> >>>>>>> I agree to you. >>>>>>> But I think we need to discuss about it with logging folks. >>>>>>> >>>>>>> I uploaded a new webrev. It removes fixed buffer length and changes the >>>>>>> order of output. >>>>>>> Could you review again? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>> >>>>>> It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. >>>>>> >>>>>> Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? >>>>>> >>>>>> Lets wait for other feedback before going further. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> I think "config_string" is different from "option_string". >>>>>>>>> >>>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>> >>>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>>> >>>>>>>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>>>>>>> It does not contain output options. >>>>>>>> >>>>>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>>>>> overall logging configuration we might have, for example: >>>>>>>> >>>>>>>> gc=trace -> stdout >>>>>>>> runtime=info -> fileA >>>>>>>> compiler=trace -> fileB >>>>>>>> >>>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>>> output. So for each output we set its "configuration" to the >>>>>>>> associated LHS. >>>>>>>> >>>>>>>> So options are a distinct property of outputs and so should have been >>>>>>>> a first class entity in LogOutput all along. >>>>>>>> >>>>>>>> Okay so looking at your v4 I have two comments: >>>>>>>> >>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>>>>>>> are so don't know if 100 is adequate. >>>>>>>> >>>>>>>> Second, if the logging syntax is: >>>>>>>> >>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>> >>>>>>>> then shouldn't the configuration be printed in the same order/format? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thank you for your comment. >>>>>>>>>>> >>>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>>> part of >>>>>>>>>>>> the existing configuration string? >>>>>>>>>>> >>>>>>>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>>>>>>> (See webrev.01). >>>>>>>>>>> Marcus commented that option string should be generated from current >>>>>>>>>>> configuration. >>>>>>>>>>> >>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>> Could you review again? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>>> >>>>>>>>>> Sorry but I repeat my question - why is the option information not >>>>>>>>>> simply part of the config_string? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>>>>>>> actually needs to implement. >>>>>>>>>>>> >>>>>>>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>>>>>>> - we >>>>>>>>>>>> have getters for all the other "properties" which are then printed by >>>>>>>>>>>> the describe_current_configuration method. But this is instead a >>>>>>>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>>>>>>> two styles seems messy. It probably would have been better to have >>>>>>>>>>>> had >>>>>>>>>>>> a print-style API from the start - then adding the options would have >>>>>>>>>>>> been a trivial extension for those output classes with options. >>>>>>>>>>>> >>>>>>>>>>>> In addition the change you made to describe_current_configuration is >>>>>>>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>>>>>>> the config string and the decorators) for this one class and so you >>>>>>>>>>>> added the code to support that format. But that format may not make >>>>>>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>>>>>> >>>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>>> part of >>>>>>>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>>>>>>> "2015, 2016,". >>>>>>>>>>>> >>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>> >>>>>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> 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 marcus.larsson at oracle.com Thu Jun 30 13:10:21 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 30 Jun 2016 15:10:21 +0200 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> References: <56FBDE2F.60701@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> Message-ID: <34e0b47d-8809-3d19-e788-40bb6a8fd1a4@oracle.com> Hi On 2016-06-30 15:01, Yasumasa Suenaga wrote: > Hi Marcus, > >> Can we keep the printing of the index # in LogConfiguration? That >> would save us from passing it as a parameter to describe. (So, print >> index, call describe, and then print newline.) > > I've fixed it. > Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/ Looks good, thanks for fixing this. Marcus > > > Thanks, > > Yasumasa > > > On 2016/06/30 18:38, Marcus Larsson wrote: >> Hi, >> >> >> On 2016-06-30 11:31, Yasumasa Suenaga wrote: >>> Hi Marcus, >>> >>>>> Therefore I suggest that we introduce a describe() function in >>>>> LogOutput as part of this change, and move the code currently in >>>>> LogConfiguration::describe to this function, adding the option >>>>> text to it as well. >>> >>> Ah, I understood. >>> If we refactor that in this enhancement, we do not need to make >>> dynamic memory allocation. >>> >>> I uploaded a new webrev. >>> I hope this webrev matches your suggestion :-) >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ >> >> Looks good! Just a nit: Can we keep the printing of the index # in >> LogConfiguration? That would save us from passing it as a parameter >> to describe. (So, print index, call describe, and then print newline.) >> >> Thanks, >> Marcus >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/06/28 22:21, Yasumasa Suenaga wrote: >>>> Hi Marcus, >>>> >>>>> I don't really like that we need to make dynamic allocations here. >>>> >>>> Should use resource area? or char array? >>>> If we should use char array, how long should we reserve for buffer? >>>> >>>> >>>>> Therefore I suggest that we introduce a describe() function in >>>>> LogOutput as part of this change, and move the code currently in >>>>> LogConfiguration::describe to this function, adding the option >>>>> text to it as well. >>>> >>>> I think this is refactoring of LogOutput and LogConfiguration. >>>> Now (after FC date), is this work accepted? >>>> >>>> IMHO, refactoring is another enhancement from this. >>>> If it is needed, I think this enhancement should be started after >>>> refactoring. >>>> >>>> >>>> If refactoring and this enhancement can be merged and be accepted, >>>> I will start to work for it. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/28 20:23, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> >>>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>> >>>>> I don't really like that we need to make dynamic allocations here. >>>>> I would prefer to have the outputs be responsible for describing >>>>> themselves just like David mentions. The current design of >>>>> LogConfiguration::describe doesn't follow that pattern, but I >>>>> really think it should. Therefore I suggest that we introduce a >>>>> describe() function in LogOutput as part of this change, and move >>>>> the code currently in LogConfiguration::describe to this function, >>>>> adding the option text to it as well. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> I've requested FC extension for this. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/06/13 13:24, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for your comment. >>>>>>>> >>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>> have been >>>>>>>>> a first class entity in LogOutput all along. >>>>>>>> >>>>>>>> I agree to you. >>>>>>>> But I think we need to discuss about it with logging folks. >>>>>>>> >>>>>>>> I uploaded a new webrev. It removes fixed buffer length and >>>>>>>> changes the >>>>>>>> order of output. >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>> >>>>>>> It's okay to wait and hear what opinions others may have before >>>>>>> changing things based on my comments. :) The fixed buffer may be >>>>>>> okay - as I said I don't know what the potential options are, so >>>>>>> don't know if it is okay or not. >>>>>>> >>>>>>> Using dynamic allocation avoids that but raises other concerns - >>>>>>> like calling vm_exit_on_out_of_memory on failure; or whether to >>>>>>> use malloc or resource area? >>>>>>> >>>>>>> Lets wait for other feedback before going further. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I think "config_string" is different from "option_string". >>>>>>>>>> >>>>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>> >>>>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>>>> >>>>>>>>>> Currently, LogOutput handles tags and loglevels only as >>>>>>>>>> config_string. >>>>>>>>>> It does not contain output options. >>>>>>>>> >>>>>>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>>>>>> overall logging configuration we might have, for example: >>>>>>>>> >>>>>>>>> gc=trace -> stdout >>>>>>>>> runtime=info -> fileA >>>>>>>>> compiler=trace -> fileB >>>>>>>>> >>>>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>>>> output. So for each output we set its "configuration" to the >>>>>>>>> associated LHS. >>>>>>>>> >>>>>>>>> So options are a distinct property of outputs and so should >>>>>>>>> have been >>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>> >>>>>>>>> Okay so looking at your v4 I have two comments: >>>>>>>>> >>>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible >>>>>>>>> options >>>>>>>>> are so don't know if 100 is adequate. >>>>>>>>> >>>>>>>>> Second, if the logging syntax is: >>>>>>>>> >>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>> >>>>>>>>> then shouldn't the configuration be printed in the same >>>>>>>>> order/format? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>> >>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>> become >>>>>>>>>>>>> part of >>>>>>>>>>>>> the existing configuration string? >>>>>>>>>>>> >>>>>>>>>>>> My first proposal keeps option string at LogOutput and its >>>>>>>>>>>> child class >>>>>>>>>>>> (See webrev.01). >>>>>>>>>>>> Marcus commented that option string should be generated >>>>>>>>>>>> from current >>>>>>>>>>>> configuration. >>>>>>>>>>>> >>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>> Could you review again? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>>>> >>>>>>>>>>> Sorry but I repeat my question - why is the option >>>>>>>>>>> information not >>>>>>>>>>> simply part of the config_string? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>>>> print_option_string seems the wrong name given that the >>>>>>>>>>>>> base class, >>>>>>>>>>>>> LogOutput, has no notion of having an "option string". It >>>>>>>>>>>>> seems to be >>>>>>>>>>>>> a supposedly generic "print other stuff" function that >>>>>>>>>>>>> only one class >>>>>>>>>>>>> actually needs to implement. >>>>>>>>>>>>> >>>>>>>>>>>>> Secondly it inverts the style of the API used for >>>>>>>>>>>>> everything else >>>>>>>>>>>>> - we >>>>>>>>>>>>> have getters for all the other "properties" which are then >>>>>>>>>>>>> printed by >>>>>>>>>>>>> the describe_current_configuration method. But this is >>>>>>>>>>>>> instead a >>>>>>>>>>>>> "print" function where we ask the target to print itself. >>>>>>>>>>>>> Mixing the >>>>>>>>>>>>> two styles seems messy. It probably would have been better >>>>>>>>>>>>> to have >>>>>>>>>>>>> had >>>>>>>>>>>>> a print-style API from the start - then adding the options >>>>>>>>>>>>> would have >>>>>>>>>>>>> been a trivial extension for those output classes with >>>>>>>>>>>>> options. >>>>>>>>>>>>> >>>>>>>>>>>>> In addition the change you made to >>>>>>>>>>>>> describe_current_configuration is >>>>>>>>>>>>> not at all general purpose - you wanted a given format >>>>>>>>>>>>> (print between >>>>>>>>>>>>> the config string and the decorators) for this one class >>>>>>>>>>>>> and so you >>>>>>>>>>>>> added the code to support that format. But that format may >>>>>>>>>>>>> not make >>>>>>>>>>>>> sense for other classes that might have "extra stuff" to >>>>>>>>>>>>> print. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there some reason the option string could not simply >>>>>>>>>>>>> become >>>>>>>>>>>>> part of >>>>>>>>>>>>> the existing configuration string? It seems to me that for >>>>>>>>>>>>> a LogFile >>>>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> PS. The two hpp files would need their copyright years >>>>>>>>>>>>> updated to >>>>>>>>>>>>> "2015, 2016,". >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> 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 yasuenag at gmail.com Thu Jun 30 13:13:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 30 Jun 2016 22:13:54 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <34e0b47d-8809-3d19-e788-40bb6a8fd1a4@oracle.com> References: <56FBDE2F.60701@gmail.com> <817db54a-682a-48e4-6ebf-fb76300a668f@gmail.com> <18c82735-b247-fb2e-f7a2-5e3d23a7fb7d@gmail.com> <9e5350d9-3eca-9384-46d5-0e3f52fd821c@gmail.com> <31a90c37-b569-3a26-ebd4-9e1f6b2a88fe@gmail.com> <84b17af0-07d3-89cd-1641-05ec5ec6c1d8@oracle.com> <65bee8ba-6fb5-d647-b143-827b4a76e0d9@gmail.com> <429ec280-d783-f798-55c8-8fd816e66130@oracle.com> <9622e4e4-8dbd-0e16-969b-5aab2806b990@gmail.com> <233a5477-0a8c-0aac-71f5-02b1b7d9eb2e@gmail.com> <34e0b47d-8809-3d19-e788-40bb6a8fd1a4@oracle.com> Message-ID: <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> Hi Marcus, > Looks good, thanks for fixing this. Thanks! I'm waiting a second reviewer and accepting FC extension request. Yasumasa On 2016/06/30 22:10, Marcus Larsson wrote: > Hi > > > On 2016-06-30 15:01, Yasumasa Suenaga wrote: >> Hi Marcus, >> >>> Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.) >> >> I've fixed it. >> Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/ > > Looks good, thanks for fixing this. > > Marcus > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/06/30 18:38, Marcus Larsson wrote: >>> Hi, >>> >>> >>> On 2016-06-30 11:31, Yasumasa Suenaga wrote: >>>> Hi Marcus, >>>> >>>>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >>>> >>>> Ah, I understood. >>>> If we refactor that in this enhancement, we do not need to make dynamic memory allocation. >>>> >>>> I uploaded a new webrev. >>>> I hope this webrev matches your suggestion :-) >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/ >>> >>> Looks good! Just a nit: Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.) >>> >>> Thanks, >>> Marcus >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/06/28 22:21, Yasumasa Suenaga wrote: >>>>> Hi Marcus, >>>>> >>>>>> I don't really like that we need to make dynamic allocations here. >>>>> >>>>> Should use resource area? or char array? >>>>> If we should use char array, how long should we reserve for buffer? >>>>> >>>>> >>>>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >>>>> >>>>> I think this is refactoring of LogOutput and LogConfiguration. >>>>> Now (after FC date), is this work accepted? >>>>> >>>>> IMHO, refactoring is another enhancement from this. >>>>> If it is needed, I think this enhancement should be started after >>>>> refactoring. >>>>> >>>>> >>>>> If refactoring and this enhancement can be merged and be accepted, >>>>> I will start to work for it. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/06/28 20:23, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>> >>>>>> I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> I've requested FC extension for this. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/06/13 13:24, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for your comment. >>>>>>>>> >>>>>>>>>> So options are a distinct property of outputs and so should have been >>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>> >>>>>>>>> I agree to you. >>>>>>>>> But I think we need to discuss about it with logging folks. >>>>>>>>> >>>>>>>>> I uploaded a new webrev. It removes fixed buffer length and changes the >>>>>>>>> order of output. >>>>>>>>> Could you review again? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/ >>>>>>>> >>>>>>>> It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not. >>>>>>>> >>>>>>>> Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area? >>>>>>>> >>>>>>>> Lets wait for other feedback before going further. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/06/13 9:05, David Holmes wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> I think "config_string" is different from "option_string". >>>>>>>>>>> >>>>>>>>>>> -Xlog format (from -Xlog:help message): >>>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>>> >>>>>>>>>>> config_string: "what" (ex. gc=trace) >>>>>>>>>>> option_string: "output-options" (ex. filecount=5) >>>>>>>>>>> >>>>>>>>>>> Currently, LogOutput handles tags and loglevels only as config_string. >>>>>>>>>>> It does not contain output options. >>>>>>>>>> >>>>>>>>>> Okay I'm starting to see the bigger picture here. In terms of the >>>>>>>>>> overall logging configuration we might have, for example: >>>>>>>>>> >>>>>>>>>> gc=trace -> stdout >>>>>>>>>> runtime=info -> fileA >>>>>>>>>> compiler=trace -> fileB >>>>>>>>>> >>>>>>>>>> where the LHS is (part of) the configuration, and the RHS is the >>>>>>>>>> output. So for each output we set its "configuration" to the >>>>>>>>>> associated LHS. >>>>>>>>>> >>>>>>>>>> So options are a distinct property of outputs and so should have been >>>>>>>>>> a first class entity in LogOutput all along. >>>>>>>>>> >>>>>>>>>> Okay so looking at your v4 I have two comments: >>>>>>>>>> >>>>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options >>>>>>>>>> are so don't know if 100 is adequate. >>>>>>>>>> >>>>>>>>>> Second, if the logging syntax is: >>>>>>>>>> >>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]] >>>>>>>>>> >>>>>>>>>> then shouldn't the configuration be printed in the same order/format? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/06/13 8:14, David Holmes wrote: >>>>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>> >>>>>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>>>>> part of >>>>>>>>>>>>>> the existing configuration string? >>>>>>>>>>>>> >>>>>>>>>>>>> My first proposal keeps option string at LogOutput and its child class >>>>>>>>>>>>> (See webrev.01). >>>>>>>>>>>>> Marcus commented that option string should be generated from current >>>>>>>>>>>>> configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/ >>>>>>>>>>>> >>>>>>>>>>>> Sorry but I repeat my question - why is the option information not >>>>>>>>>>>> simply part of the config_string? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First >>>>>>>>>>>>>> print_option_string seems the wrong name given that the base class, >>>>>>>>>>>>>> LogOutput, has no notion of having an "option string". It seems to be >>>>>>>>>>>>>> a supposedly generic "print other stuff" function that only one class >>>>>>>>>>>>>> actually needs to implement. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Secondly it inverts the style of the API used for everything else >>>>>>>>>>>>>> - we >>>>>>>>>>>>>> have getters for all the other "properties" which are then printed by >>>>>>>>>>>>>> the describe_current_configuration method. But this is instead a >>>>>>>>>>>>>> "print" function where we ask the target to print itself. Mixing the >>>>>>>>>>>>>> two styles seems messy. It probably would have been better to have >>>>>>>>>>>>>> had >>>>>>>>>>>>>> a print-style API from the start - then adding the options would have >>>>>>>>>>>>>> been a trivial extension for those output classes with options. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In addition the change you made to describe_current_configuration is >>>>>>>>>>>>>> not at all general purpose - you wanted a given format (print between >>>>>>>>>>>>>> the config string and the decorators) for this one class and so you >>>>>>>>>>>>>> added the code to support that format. But that format may not make >>>>>>>>>>>>>> sense for other classes that might have "extra stuff" to print. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there some reason the option string could not simply become >>>>>>>>>>>>>> part of >>>>>>>>>>>>>> the existing configuration string? It seems to me that for a LogFile >>>>>>>>>>>>>> these "options" really are part of the configuration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> PS. The two hpp files would need their copyright years updated to >>>>>>>>>>>>>> "2015, 2016,". >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> PING: Could you review it? >>>>>>>>>>>>>>> We need a second reviewer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This change is small fix, and it helps us to confirm current >>>>>>>>>>>>>>> FileLogOutput configuration. >>>>>>>>>>>>>>> So I want to merge it to jdk 9. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> 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 daniel.daugherty at oracle.com Thu Jun 30 20:35:31 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 30 Jun 2016 14:35:31 -0600 Subject: Jigsaw Enhancement RFR round #2: 8159147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: <5774C2D8.9090105@oracle.com> References: <5774C2D8.9090105@oracle.com> Message-ID: On 6/30/16 12:57 AM, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw fix for the enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159147 > > Just a sanity check is needed. > > This update has fixes related to the Mandy's comments on the > ClassFileTransformer.java: > - one of the @implSpec statements is corrected > - null has been replaced with {@code null} > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk2/ Thumbs up. Don't know if I qualify as sane though... :-) Dan > > > Summary: > > As noted in JDK-8155207 > and elsewhere, one > of the outstanding items for java.lang.instrument is > whether the new ClassFileTransformer transform method should > provider the ClassLoader parameter. > After further consideration then this seems useful and avoids agents > needing permissions to invoke Module::getClassLoader. > The fix is to add the ClassLoader as the second parameter of the > ClassFileTransformer#transform() method. > > This fix also replaces the usage of the JVM_GetModuleByPackageName > with the JVMTI GetNamedModule in the JPLISAgent.c. > It is why this fix depends on the fix of the JVMTI enhancement: > https://bugs.openjdk.java.net/browse/JDK-8159145 > and so, must be pushed after the JDK-8159145. > > > Testing: > Ran the Jtreg java/lang/instrument tests. > Ran two updated jtreg j.l.i tests: > java/lang/instrument/RetransformAgent.java > java/lang/instrument/SingleTransformerTest.java > > Thanks, > Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jun 30 20:42:31 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Jun 2016 13:42:31 -0700 Subject: Jigsaw Enhancement RFR round #2: 8159147 Add ClassLoader parameter to new ClassFileTransformer transform method In-Reply-To: References: <5774C2D8.9090105@oracle.com> Message-ID: <57758437.8080305@oracle.com> On 6/30/16 13:35, Daniel D. Daugherty wrote: > > On 6/30/16 12:57 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw fix for the enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159147 >> >> Just a sanity check is needed. >> >> This update has fixes related to the Mandy's comments on the >> ClassFileTransformer.java: >> - one of the @implSpec statements is corrected >> - null has been replaced with {@code null} >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8159147-Jigsaw-jli.jdk2/ > > Thumbs up. Thanks, Dan! > > Don't know if I qualify as sane though... :-) Of course, you do! :-) Thanks, Serguei > > Dan > >> >> >> Summary: >> >> As noted in JDK-8155207 >> and elsewhere, one >> of the outstanding items for java.lang.instrument is >> whether the new ClassFileTransformer transform method should >> provider the ClassLoader parameter. >> After further consideration then this seems useful and avoids >> agents needing permissions to invoke Module::getClassLoader. >> The fix is to add the ClassLoader as the second parameter of the >> ClassFileTransformer#transform() method. >> >> This fix also replaces the usage of the JVM_GetModuleByPackageName >> with the JVMTI GetNamedModule in the JPLISAgent.c. >> It is why this fix depends on the fix of the JVMTI enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8159145 >> and so, must be pushed after the JDK-8159145. >> >> >> Testing: >> Ran the Jtreg java/lang/instrument tests. >> Ran two updated jtreg j.l.i tests: >> java/lang/instrument/RetransformAgent.java >> java/lang/instrument/SingleTransformerTest.java >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: