From david.holmes at oracle.com Fri Jul 1 02:22:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jul 2016 12:22:15 +1000 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> References: <56FBDE2F.60701@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> <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> Message-ID: On 30/06/2016 11:13 PM, Yasumasa Suenaga wrote: > Hi Marcus, > >> Looks good, thanks for fixing this. > > Thanks! > I'm waiting a second reviewer and accepting FC extension request. Reviewed. This looks much neater. Thanks. David ----- > > 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 david.holmes at oracle.com Fri Jul 1 03:10:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Jul 2016 13:10:54 +1000 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: Looks good to me too! Thanks, David On 30/06/2016 4:57 PM, 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/ > > > 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 yasuenag at gmail.com Fri Jul 1 03:16:07 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Jul 2016 12:16:07 +0900 Subject: PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd In-Reply-To: References: <56FBDE2F.60701@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> <2891ca67-a09a-40b6-e4ae-f2cb3374bc34@gmail.com> Message-ID: Thanks David! I'm waiting to approve FC extension request. Marcus, David, could you be a sponsor for this? Yasumasa 2016/07/01 11:22 "David Holmes" : > On 30/06/2016 11:13 PM, Yasumasa Suenaga wrote: > >> Hi Marcus, >> >> Looks good, thanks for fixing this. >>> >> >> Thanks! >> I'm waiting a second reviewer and accepting FC extension request. >> > > Reviewed. This looks much neater. Thanks. > > David > ----- > > > >> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 1 03:45:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Jun 2016 20:45:10 -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: <5775E746.8070702@oracle.com> Thanks, David! Serguei On 6/30/16 20:10, David Holmes wrote: > Looks good to me too! > > Thanks, > David > > On 30/06/2016 4:57 PM, 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/ >> >> >> >> 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 kubota.yuji at gmail.com Sun Jul 3 15:30:56 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 4 Jul 2016 00:30:56 +0900 Subject: Serviceability Agent tools / API usage . In-Reply-To: References: Message-ID: Hi Arvind, May I ask what Serviceability Agent tools / API (which you want to survey) means? I think that it includes jdb, jinfo, jmap, jstack and Dynamic Attach. If this is right, my answers are below. 2016-06-29 1:15 GMT+09:00 Arvind Aprameya : > ? Have you been using Serviceability Agent related API's or tools > for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? Yes. Exactly. I believe SA is great treasure! > ? If the answer for the above question was yes, a very brief > explanation of what area's in your project have you been using ? I'm one of OpenJDK technical support engineers in Japan. I used hard these tools for troubleshooting many times. For example of corner case, I wrote a reproducer of jvm networking bug by using jdb. https://bugs.openjdk.java.net/browse/JDK-8151212 (reproducer-raw.txt) http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/testProgram/src/main/java/debugcontrol/DebugController.java#l114 In addition, Yasumasa and I developed HeapStats [1] which aims to improve after-the-fact analysis by using JVM TI agent for collecting java runtime information. HeapStats uses socket to AttachListener to get thread dump. [1]: http://icedtea.classpath.org/wiki/HeapStats/ > ? Do you believe the current capabilities of SA are helpful / > important ? Exactly. > ? Areas of improvement you would like to see / make in future ? By jdk9, we will use jcmd / jhsdb instead of jstack / jmap. I think it's a right way. I want to contribute serviceability groups as possible as before. > 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 Thanks, Yuji From yasuenag at gmail.com Sun Jul 3 23:17:32 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 4 Jul 2016 08:17:32 +0900 Subject: Serviceability Agent tools / API usage . In-Reply-To: References: Message-ID: Hi, >> ? Have you been using Serviceability Agent related API's or tools >> for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? > > Yes. Exactly. I believe SA is great treasure! > >> ? If the answer for the above question was yes, a very brief >> explanation of what area's in your project have you been using ? > > I'm one of OpenJDK technical support engineers in Japan. I used hard these tools > for troubleshooting many times. We often use HSDB/CLHSDB to analyze core images. SA tools are very important for us ! So we've contributed patches to serviceability group :-) Yasumasa On 2016/07/04 0:30, KUBOTA Yuji wrote: > Hi Arvind, > > May I ask what Serviceability Agent tools / API (which you want to > survey) means? > I think that it includes jdb, jinfo, jmap, jstack and Dynamic Attach. > > If this is right, my answers are below. > > 2016-06-29 1:15 GMT+09:00 Arvind Aprameya : >> ? Have you been using Serviceability Agent related API's or tools >> for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? > > Yes. Exactly. I believe SA is great treasure! > >> ? If the answer for the above question was yes, a very brief >> explanation of what area's in your project have you been using ? > > I'm one of OpenJDK technical support engineers in Japan. I used hard these tools > for troubleshooting many times. > For example of corner case, I wrote a reproducer of jvm networking bug > by using jdb. > https://bugs.openjdk.java.net/browse/JDK-8151212 (reproducer-raw.txt) > http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/testProgram/src/main/java/debugcontrol/DebugController.java#l114 > > In addition, Yasumasa and I developed HeapStats [1] which aims to improve > after-the-fact analysis by using JVM TI agent for collecting java > runtime information. > HeapStats uses socket to AttachListener to get thread dump. > [1]: http://icedtea.classpath.org/wiki/HeapStats/ > >> ? Do you believe the current capabilities of SA are helpful / >> important ? > Exactly. > >> ? Areas of improvement you would like to see / make in future ? > By jdk9, we will use jcmd / jhsdb instead of jstack / jmap. I think > it's a right way. > I want to contribute serviceability groups as possible as before. > >> 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 > > Thanks, > Yuji > From arvind.aprameya at oracle.com Mon Jul 4 14:57:06 2016 From: arvind.aprameya at oracle.com (Arvind Aprameya) Date: Mon, 4 Jul 2016 14:57:06 +0000 (UTC) Subject: Serviceability Agent tools / API usage . In-Reply-To: References: Message-ID: Hi Yuji, Thank you very much for your response, please do find my responses inline. Regards, Arvind -----Original Message----- From: KUBOTA Yuji [mailto:kubota.yuji at gmail.com] Sent: Sunday, July 03, 2016 9:01 PM To: Arvind Aprameya Cc: serviceability-dev; Yasumasa Suenaga Subject: Re: Serviceability Agent tools / API usage . Hi Arvind, May I ask what Serviceability Agent tools / API (which you want to survey) means? I think that it includes jdb, jinfo, jmap, jstack and Dynamic Attach. AA>> This is correct, hsdb or clhsdb are also other tools If this is right, my answers are below. 2016-06-29 1:15 GMT+09:00 Arvind Aprameya : > ? Have you been using Serviceability Agent related API's or tools > for any of your debugging or analysis purpose (e.g. core dump / heapdump ) ? Yes. Exactly. I believe SA is great treasure! > ? If the answer for the above question was yes, a very brief > explanation of what area's in your project have you been using ? I'm one of OpenJDK technical support engineers in Japan. I used hard these tools for troubleshooting many times. For example of corner case, I wrote a reproducer of jvm networking bug by using jdb. https://bugs.openjdk.java.net/browse/JDK-8151212 (reproducer-raw.txt) http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/testProgram/src/main/java/debugcontrol/DebugController.java#l114 In addition, Yasumasa and I developed HeapStats [1] which aims to improve after-the-fact analysis by using JVM TI agent for collecting java runtime information. HeapStats uses socket to AttachListener to get thread dump. [1]: http://icedtea.classpath.org/wiki/HeapStats/ > ? Do you believe the current capabilities of SA are helpful / > important ? Exactly. > ? Areas of improvement you would like to see / make in future ? By jdk9, we will use jcmd / jhsdb instead of jstack / jmap. I think it's a right way. I want to contribute serviceability groups as possible as before. AA>>Thank you very much and please do continue with all your valuable contributions. > 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 Thanks, Yuji From Alan.Bateman at oracle.com Tue Jul 5 13:11:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 14:11:01 +0100 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <57749331.2030701@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> <57749331.2030701@oracle.com> Message-ID: <64011c81-d4b1-80dd-181b-6321f782d496@oracle.com> Just catching up on this thread, I assume this is the current patch: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ For the description then it might be clearer to say "for a named module" rather than "for a module" so that the first paragraph is clear than this is function to obtain a reference to a named module. For the class_loader description then it might be clearer to say is not NULL and a not a subclass of ... At some point then I assume the version="9.0.0" changes should be collapsed into one change element. The rest looks okay to me. -Alan From Alan.Bateman at oracle.com Tue Jul 5 15:42:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 16:42:55 +0100 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 30/06/2016 07:57, 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/ > This version looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Jul 5 16:24:17 2016 From: jini.george at oracle.com (Jini George) Date: Tue, 5 Jul 2016 09:24:17 -0700 (PDT) Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Message-ID: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> Hi all, Please review the fix in Serviceability Agent (SA) for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) The webrev is at: http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ The modifications include the fix and 2 tests to check the InstanceKlass sizes representing some well known classes and that of an interface. The tests compare the sizes returned by SA to those returned by jcmd. At this point, SA cannot view the InstanceKlasses representing anonymous classes. (This issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160228"JDK-8160228 (SA cannot view the LambdaMetaFactory generated anonymous instanceKlasses)). Hence the current fix does not include the size addition for InstanceKlasses representing anonymous classes. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jul 5 16:38:11 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Jul 2016 09:38:11 -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: <577BE273.3060708@oracle.com> Thanks, Alan! Serguei On 7/5/16 08:42, Alan Bateman wrote: > > > > On 30/06/2016 07:57, 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/ >> > This version looks good to me. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jul 5 16:55:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Jul 2016 09:55:33 -0700 Subject: Jigsaw Enhancement RFR round #3: 8159145 Add JVMTI function GetNamedModule In-Reply-To: <64011c81-d4b1-80dd-181b-6321f782d496@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> <57749331.2030701@oracle.com> <64011c81-d4b1-80dd-181b-6321f782d496@oracle.com> Message-ID: <577BE685.7010101@oracle.com> On 7/5/16 06:11, Alan Bateman wrote: > Just catching up on this thread, I assume this is the current patch: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.6/ > > > For the description then it might be clearer to say "for a named > module" rather than "for a module" so that the first paragraph is > clear than this is function to obtain a reference to a named module. Fixed. > > For the class_loader description then it might be clearer to say is > not NULL and a not a subclass of ... Fixed. > > At some point then I assume the version="9.0.0" changes should be > collapsed into one change element. Fixed. > > The rest looks okay to me. Thanks, Alan! Serguei > > -Alan > > From daniel.daugherty at oracle.com Wed Jul 6 14:44:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 08:44:11 -0600 Subject: Result: New Serviceability Group Member: Staffan Larsen Message-ID: <434e7b29-163b-104e-4708-d750a7aba537@oracle.com> The vote for Staffan Larsen [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Daniel Daugherty [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-June/019793.html From dmitry.samersoff at oracle.com Wed Jul 6 16:24:15 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Jul 2016 19:24:15 +0300 Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase Message-ID: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ All credentials belongs to Richard Reingruber, see mail thread (below) for details. http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html -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 ivan.gerasimov at oracle.com Wed Jul 6 16:55:45 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 6 Jul 2016 19:55:45 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out Message-ID: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(GetCurrentThread()), 4) Now, the thread B will have to wait for all the registered threads, including the thread A, which will never wake up. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ With kind regards, Ivan From ivan.gerasimov at oracle.com Wed Jul 6 16:57:04 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 6 Jul 2016 19:57:04 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out Message-ID: Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(GetCurrentThread()), 4) Now, the thread B will have to wait for all the registered threads, including the thread A, which will never wake up. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ With kind regards, Ivan From daniel.daugherty at oracle.com Wed Jul 6 21:21:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jul 2016 15:21:11 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: References: Message-ID: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> On 7/6/16 10:57 AM, Ivan Gerasimov wrote: > Hello! > > When fixing JDK-8069048 a potential race was overlooked: > 1) Thread A wants to call _endthreadex() and registers itself, > 2) Thread B wants to call exit(), takes its turn and raises the flag > `process_exiting`, > 3) Thread A continues, and gets captured in the loop at 4020, in > SuspendThread(GetCurrentThread()), > 4) Now, the thread B will have to wait for all the registered threads, > including the thread A, which will never wake up. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ src/os/windows/vm/os_windows.cpp Just to make sure the race is clear (in my mind at least): Thread A - executes if-block at L3913-3968; in particular it registers itself on L3957 - executes if-block at L4017-4027; in the old code, the thread would block for ever in L4022-4026; in the new code, the thread will only block if it did not register itself. Thread B: - executes if-block at L3906-3910 and succeeds in setting the process_exiting flag - executes if-block at L3969-4012; in particular Thread B calls WaitForMultipleObjects() on L3994; in the old code, WaitForMultipleObjects() times out because Thread A is blocked. L3963: registered_itself = true; L3964: } L3965: L3966: // The current exiting thread has stored its handle in the array, and now L3967: // should leave the critical section before calling _endthreadex(). The existing comment on L3966-3967 belongs after L3963 and before L3964, i.e., at the end of the else-block. If you agree with moving the comment on L3966-3967, then consider this next request: L3959: warning("DuplicateHandle failed (%u) in %s: %d\n", L3960: GetLastError(), __FILE__, __LINE__); Please consider adding the following comment after the warning: // We can't register this thread (no more handles) so this thread // may be racing with a thread that is calling exit(). If the thread // that is calling exit() has managed to set the process_exiting // flag, then this thread will be caught in the SuspendThread() // infinite loop below which closes that race. A small timing // window remains before the process_exiting flag is set, but it // is only exposed when we are out of handles. L4021: // don't let the current thread proceed to exit() or _endthreadex() Clarify comment: 'current thread' -> 'current unregistered thread' Very nice and very quick job in finding this race! Thumbs up on what you have since my comments are only related to moving/adding comments. Dan > > With kind regards, > Ivan > From ivan.gerasimov at oracle.com Wed Jul 6 23:09:56 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Jul 2016 02:09:56 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> References: <96448437-61c1-f4a2-922b-f4a9477ad460@oracle.com> Message-ID: Thanks Daniel! I'll rearrange comments as you suggest. With kind regards, Ivan On 07.07.2016 0:21, Daniel D. Daugherty wrote: > On 7/6/16 10:57 AM, Ivan Gerasimov wrote: >> Hello! >> >> When fixing JDK-8069048 a potential race was overlooked: >> 1) Thread A wants to call _endthreadex() and registers itself, >> 2) Thread B wants to call exit(), takes its turn and raises the flag >> `process_exiting`, >> 3) Thread A continues, and gets captured in the loop at 4020, in >> SuspendThread(GetCurrentThread()), >> 4) Now, the thread B will have to wait for all the registered >> threads, including the thread A, which will never wake up. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ > > src/os/windows/vm/os_windows.cpp > Just to make sure the race is clear (in my mind at least): > > Thread A > - executes if-block at L3913-3968; in particular it > registers itself on L3957 > - executes if-block at L4017-4027; in the old code, > the thread would block for ever in L4022-4026; in > the new code, the thread will only block if it did > not register itself. > > Thread B: > - executes if-block at L3906-3910 and succeeds in > setting the process_exiting flag > - executes if-block at L3969-4012; in particular > Thread B calls WaitForMultipleObjects() on L3994; > in the old code, WaitForMultipleObjects() times > out because Thread A is blocked. > > L3963: registered_itself = true; > L3964: } > L3965: > L3966: // The current exiting thread has stored its handle > in the array, and now > L3967: // should leave the critical section before calling > _endthreadex(). > The existing comment on L3966-3967 belongs after L3963 and before > L3964, i.e., at the end of the else-block. > > If you agree with moving the comment on L3966-3967, then > consider this next request: > > L3959: warning("DuplicateHandle failed (%u) in %s: %d\n", > L3960: GetLastError(), __FILE__, __LINE__); > > Please consider adding the following comment after the warning: > > // We can't register this thread (no more handles) so this thread > // may be racing with a thread that is calling exit(). If the > thread > // that is calling exit() has managed to set the process_exiting > // flag, then this thread will be caught in the SuspendThread() > // infinite loop below which closes that race. A small timing > // window remains before the process_exiting flag is set, but it > // is only exposed when we are out of handles. > > L4021: // don't let the current thread proceed to exit() or > _endthreadex() > Clarify comment: 'current thread' > -> 'current unregistered thread' > > Very nice and very quick job in finding this race! > > Thumbs up on what you have since my comments are only related > to moving/adding comments. > > Dan > > >> >> With kind regards, >> Ivan >> > > From daniel.daugherty at oracle.com Thu Jul 7 23:45:09 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Jul 2016 17:45:09 -0600 Subject: resigning as Serviceability Group Lead Message-ID: <5e61503c-1e26-4a46-e76c-39aa1437ca8e@oracle.com> Greetings, Since I have changed jobs (back in 2010) and Serviceability is no longer the focus of my day-to-day work, I feel it's best to give up the role of Serviceability Group Lead. Please consider this my resignation. Regards, Daniel Daugherty From daniel.daugherty at oracle.com Thu Jul 7 23:48:14 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Jul 2016 17:48:14 -0600 Subject: CFV: New Serviceability Group Lead: Staffan Larsen Message-ID: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. 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 July 25, 2016 18:00 PDT. Only current Members of the Serviceability Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Simple Majority voting instructions, see [3]. Thanks, Daniel Daugherty [1]: http://openjdk.java.net/bylaws#group-lead [2]: http://openjdk.java.net/census#serviceability [3]: http://openjdk.java.net/groups#lead-vote From daniel.daugherty at oracle.com Fri Jul 8 00:00:12 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Jul 2016 18:00:12 -0600 Subject: CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: <7b206867-71f2-af2c-4d22-39dc8d30fcf0@oracle.com> Vote: yes Dan On 7/7/16 5:48 PM, Daniel D. Daugherty wrote: > I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. > > 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 July 25, 2016 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote > From serguei.spitsyn at oracle.com Fri Jul 8 00:12:26 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Jul 2016 17:12:26 -0700 Subject: CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: <577EEFEA.5070007@oracle.com> Vote: yes On 7/7/16 16:48, Daniel D. Daugherty wrote: > I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. > > 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 July 25, 2016 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote From tim.bell at oracle.com Fri Jul 8 00:12:32 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 7 Jul 2016 17:12:32 -0700 Subject: CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: <577EEFF0.7000706@oracle.com> Vote: yes On 07/07/16 16:48, Daniel D. Daugherty wrote: > I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. Tim From ioi.lam at oracle.com Fri Jul 8 01:56:54 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 07 Jul 2016 18:56:54 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> Message-ID: <577F0866.2050606@oracle.com> (Adding serviceability-dev at openjdk.java.net) Hi Jiangli, I think the two blocks of if (RequireSharedSpaces) { tty->print_cr("An error has occurred while loading shared class."); tty->print_cr("Tool agent requires sharing to be disabled."); vm_exit(1); } should be removed. If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like jvmtiError JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { ... if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { + if (RequireSharedSpaces && !universe::is_bootstraping()) { + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); + return JVMTI_ERROR_ILLEGAL_ARGUMENT; + } record_class_file_load_hook_enabled(); } ... } Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: > Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. > > webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ > bug: JDK-8141341 > > With -Xshare:on > If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. > > With -Xshare:auto > The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. > > The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. > > Thanks, > Jiangli > > From sharath.ballal at oracle.com Fri Jul 8 04:57:12 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Jul 2016 21:57:12 -0700 (PDT) Subject: RFR: 8158050: Remove SA-JDI Message-ID: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> Hello, Please review the fix for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8158050"JDK-8158050 - Remove SA-JDI The webrev is at: http://cr.openjdk.java.net/~sballal/8158050/webrev.01/index.html The fix is for removing the SA-JDI code and jsadebugd. Jsadebugd is being moved to jhsdb as part of another bug (review will be sent next). -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Jul 8 06:32:49 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Jul 2016 06:32:49 +0000 Subject: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: <76f86dd5548e4008a25f2bc411be6d08@DEWDFE13DE09.global.corp.sap> Vote: yes Best regards, Goetz. > -----Original Message----- > From: serviceability-dev [mailto:serviceability-dev- > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty > Sent: Freitag, 8. Juli 2016 01:48 > To: serviceability-dev at openjdk.java.net > Subject: CFV: New Serviceability Group Lead: Staffan Larsen > > I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. > > 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 July 25, 2016 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote From Alan.Bateman at oracle.com Fri Jul 8 07:09:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Jul 2016 08:09:30 +0100 Subject: CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: <07550c76-fd8f-6278-b4db-8146be914de1@oracle.com> Vote: yes From karen.kinnear at oracle.com Fri Jul 8 13:38:47 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Jul 2016 09:38:47 -0400 Subject: CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> References: <84a28850-328a-dd95-2427-da0d59a3a347@oracle.com> Message-ID: Vote: yes > On Jul 7, 2016, at 7:48 PM, Daniel D. Daugherty wrote: > > I hereby nominate Staffan Larsen to Serviceability Group Lead [1]. > > 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 July 25, 2016 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote From karen.kinnear at oracle.com Fri Jul 8 14:55:27 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Jul 2016 10:55:27 -0400 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Jiangli, Thank you so much for picking up this bug fix, I very much appreciate that. I agree with not quitting the vm on agent attach. I actually think we also want the agent attach to succeed - see below. > On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: > > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, but no forcing of using the shared spaces if there is an agent. > > If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. > > If the agent is attached later, after the VM has started, I think we should not quit the VM. Totally agree - we should not quit the VM. > Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ? > } > I was expecting the vm to continue running, letting the agent attach (customers really want to use these). Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. > > Thanks > - Ioi Jiangli: Minor code review comments: metaspace.cpp line 3181: CFHL-> CFLH metaspace.cpp: I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. I think it would make sense to do a bit more of that - e.g. cds_address appears to only be use locally, so it also could be inside the #if INCLUDE_CDS. Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? thanks, Karen > > > > On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >> bug: JDK-8141341 >> >> With -Xshare:on >> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >> >> With -Xshare:auto >> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >> >> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >> >> Thanks, >> Jiangli >> >> > From sharath.ballal at oracle.com Fri Jul 8 15:06:11 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 8 Jul 2016 15:06:11 +0000 (UTC) Subject: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb Message-ID: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> Hello, Please review the fix for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160817"JDK-8160817 - Add jsadebugd and classLoaderStat functionality to jhsdb Webrev is at: http://cr.openjdk.java.net/~sballal/8160817/webrev.00/index.html This fix moves the jsadebugd and classLoaderStat functionality to jhsdb and move the TestClassLoaderStats.java functionality to BasicLauncherTest.java. -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Fri Jul 8 18:13:22 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 11:13:22 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: Hi Ioi, Thanks for the comments. > On Jul 7, 2016, at 6:56 PM, Ioi Lam wrote: > > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. > > If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp I noticed in some cases the JvmtiExport::should_post_class_file_load_hook is not enabled very early during VM initialization, but rather at a later time for agent specified in the command line. When agent has SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_CLASS_FILE_LOAD_HOOK?), the enabling of the JvmtiExport::should_post_class_file_load_hook is done early and can be handled by the check in meatspace.cpp. In other case, the capability is enabled later, which is after the mapping of the shared spaces and initializing of the preloaded classes. Here is the stack trace of the later case: #0 JvmtiExport::set_should_post_class_file_load_hook(bool) () #1 0x00007ffff617fe3e in JvmtiEventControllerPrivate::recompute_enabled() () #2 0x00007ffff6180607 in JvmtiEventControllerPrivate::set_event_callbacks(JvmtiEnvBase*, jvmtiEventCallbacks const*, int) () #3 0x00007ffff6181557 in JvmtiEventController::set_event_callbacks(JvmtiEnvBase*, jvmtiEventCallbacks const*, int) () #4 0x00007ffff6169ca2 in JvmtiEnv::SetEventCallbacks(jvmtiEventCallbacks const*, int) () #5 0x00007ffff61206d1 in jvmti_SetEventCallbacks () #6 0x00007ffff47bed27 in setLivePhaseEventHandlers () #7 0x00007ffff47be47f in processJavaStart () #8 0x00007ffff47bd0fe in eventHandlerVMInit () #9 0x00007ffff6183727 in JvmtiExport::post_vm_initialized() () #10 0x00007ffff65d560c in Threads::create_vm(JavaVMInitArgs*, bool*) () #11 0x00007ffff607fc6f in JNI_CreateJavaVM_inner(JavaVM_**, void**, void*) () #12 0x00007ffff607fffd in JNI_CreateJavaVM () #13 0x00007ffff7798c9e in InitializeJVM () #14 0x00007ffff77960ba in JavaMain () #15 0x00007ffff79ade9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #16 0x00007ffff72c34bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #17 0x0000000000000000 in ?? () If we don?t want to abort the VM running -Xshare:on with dynamically attached agent, maybe we can do the JvmtiExport::should_post_class_file_load_hook check after JvmtiExport::post_vm_initialized(). Then we can remove the 'if (RequireSharedSpaces) {? blocks from the load_shared_class(). Thanks, Jiangli > > If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ... > } > > > Thanks > - Ioi > > > > On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >> bug: JDK-8141341 >> >> With -Xshare:on >> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >> >> With -Xshare:auto >> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >> >> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >> >> Thanks, >> Jiangli >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Fri Jul 8 18:18:41 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 11:18:41 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Message-ID: Hi Karen, Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. Thanks, Jiangli > On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: > > Jiangli, > > Thank you so much for picking up this bug fix, I very much appreciate that. > > I agree with not quitting the vm on agent attach. > I actually think we also want the agent attach to succeed - see below. >> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >> >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. > I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, > but no forcing of using the shared spaces if there is an agent. >> >> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp > Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >> >> If the agent is attached later, after the VM has started, I think we should not quit the VM. > Totally agree - we should not quit the VM. > >> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ? >> } >> > I was expecting the vm to continue running, letting the agent attach (customers really want to use these). > Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. > I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the > two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >> >> Thanks >> - Ioi > Jiangli: > > Minor code review comments: > > metaspace.cpp line 3181: CFHL-> CFLH > > metaspace.cpp: > I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. > I think it would make sense to do a bit more of that - e.g. cds_address appears to only be > use locally, so it also could be inside the #if INCLUDE_CDS. > Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? > > thanks, > Karen > >> >> >> >> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>> bug: JDK-8141341 >>> >>> With -Xshare:on >>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>> >>> With -Xshare:auto >>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>> >>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>> >>> Thanks, >>> Jiangli >>> >>> >> > From serguei.spitsyn at oracle.com Fri Jul 8 19:59:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 12:59:24 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <577F0866.2050606@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> Message-ID: <5780061C.9020500@oracle.com> Hi Jiangli, src/share/vm/memory/metaspace.cpp 3177 if (UseSharedSpaces) { 3178 FileMapInfo* mapinfo = new FileMapInfo(); 3179 3180 if (JvmtiExport::should_post_class_file_load_hook()) { 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, 3183 // just disable UseSharedSpaces. 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); 3185 } else { I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? Also, there is a comment below. On 7/7/16 18:56, Ioi Lam wrote: > (Adding serviceability-dev at openjdk.java.net) > > Hi Jiangli, > > I think the two blocks of > > if (RequireSharedSpaces) { > tty->print_cr("An error has occurred while loading shared class."); > tty->print_cr("Tool agent requires sharing to be disabled."); > vm_exit(1); > } > > should be removed. > > If the agent is specified in the command line, the JVM start would be > aborted. This is already handled by your changes to > src/share/vm/memory/metaspace.cpp > > If the agent is attached later, after the VM has started, I think we > should not quit the VM. Consider this scenario -- a production server > could be running for a long time without issues using -Xshare:on, then > when the user attaches a diagnostic agent the JVM suddenly quits. I > think it's better to cause the agent attachment to fail with something > like > > jvmtiError > JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent > event_type, jthread event_thread, ...) { > > ... > if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { > + if (RequireSharedSpaces && !universe::is_bootstraping()) { > + tty->print_cr("Tool agent that requires > JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after > JVM has started"); > + return JVMTI_ERROR_ILLEGAL_ARGUMENT; > + } > record_class_file_load_hook_enabled(); > } > ... > } This is a good concern and suggestion. We may need more sophisticated handling for this. Sorry, I did not notice it earlier. There is a capability can_generate_all_class_hook_events. We already have this in the prims/jvmtiManageCapabilities.cpp: // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei > Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >> Please review the following webrev that disables CDS when >> JvmtiExport::should_post_class_file_load_hook() is enabled at >> runtime. webrev: >> http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: >> JDK-8141341 With >> -Xshare:on If -Xshare:on is used and >> JvmtiExport::should_post_class_file_load_hook() is required, the VM >> now reports "Tool agent requires sharing to be disabled? and >> terminates. This is the same behavior as jdk8. With -Xshare:auto The >> change in meatspace.cpp is to detect the case where >> JvmtiExport::should_post_class_file_load_hook() is enabled very early >> during JVM initialization. In that case, we disable CDS entirely, >> including all shared classes, symbols, and Strings objects. The >> change in systemDictionary.cpp is to detect the cases where >> JvmtiExport::should_post_class_file_load_hook() is enabled late, >> which include agent dynamically attached at runtime. In those cases, >> JVM does not allow loading classes from the shared archive. The >> shared symbols and Strings can still be used. Thanks, Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 8 20:57:06 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 13:57:06 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780061C.9020500@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> Message-ID: <578013A2.9000103@oracle.com> On 7/8/16 12:59, serguei.spitsyn at oracle.com wrote: > Hi Jiangli, > > > src/share/vm/memory/metaspace.cpp > > 3177 if (UseSharedSpaces) { > 3178 FileMapInfo* mapinfo = new FileMapInfo(); > 3179 > 3180 if (JvmtiExport::should_post_class_file_load_hook()) { > 3181 // Currently CDS does not support JVMTI CFHL when loading shared > class. > 3182 // If JvmtiExport::should_post_class_file_load_hook is already > enabled, > 3183 // just disable UseSharedSpaces. > 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be > disabled."); > 3185 } else { > > I understood, the FileMapInfo::fail_continue() will fail if the > RequireSharedSpaces is enabled which is expected. > Should the mapinfo be deallocated in the case > FileMapInfo::fail_continue() is called? > > Also, there is a comment below. > > > On 7/7/16 18:56, Ioi Lam wrote: >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared >> class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. >> >> If the agent is specified in the command line, the JVM start would be >> aborted. This is already handled by your changes to >> src/share/vm/memory/metaspace.cpp >> >> If the agent is attached later, after the VM has started, I think we >> should not quit the VM. Consider this scenario -- a production server >> could be running for a long time without issues using -Xshare:on, >> then when the user attaches a diagnostic agent the JVM suddenly >> quits. I think it's better to cause the agent attachment to fail >> with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent >> event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires >> JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after >> JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ... >> } > > > This is a good concern and suggestion. > We may need more sophisticated handling for this. > Sorry, I did not notice it earlier. > > There is a capability can_generate_all_class_hook_events. > We already have this in the prims/jvmtiManageCapabilities.cpp: > > // if the capability sets are initialized in the onload phase then // > it happens before class data sharing (CDS) is initialized. If it // > turns out that CDS gets disabled then we must adjust the always // > capabilities. To ensure a consistent view of the capabililties // > anything we add here should already be in the onload set. void > JvmtiManageCapabilities::recompute_always_capabilities() { if > (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; > jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } > } If enabled can_generate_all_class_hook_events sets the > flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: > JvmtiExport::set_can_modify_any_class( > avail.can_generate_breakpoint_events || > avail.can_generate_all_class_hook_events); The flag > JvmtiExport::can_modify_any_class() is used here: > > char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in > use (debugging enabled), we must map the address space RW if > (JvmtiExport::can_modify_any_class() || > JvmtiExport::can_walk_any_space()) { si->_read_only = false; } > So, I'm thinking if we could just skip the CFLH events for the shared > classes if the capability can_generate_all_class_hook_events is not > enabled and continue posting the events for non-shared classes. Then > we do not need to tweak the SetEventNotificationMode() implementation. > Otherwise, the fragment above may need to be updated too. > To summarize, I understood that the current approach/plan for JDK 9 is: > - Disable the CDS if detected early that the CFLH events are enabled > - Skip the CFLH events for shared classes if CFLH is enabled late > Is this right? Is it the same as in the JDK 8? I realized, it is not correct. Sorry for the confusion. The above contradicts with the statement from Jiangli: > The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. So, we want to disallow loading classes from the shared archive if the CFLH events are enabled late. I'm still in process of reviewing. Thanks, Serguei > Thanks, Serguei >> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when >>> JvmtiExport::should_post_class_file_load_hook() is enabled at >>> runtime. webrev: >>> http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: >>> JDK-8141341 With >>> -Xshare:on If -Xshare:on is used and >>> JvmtiExport::should_post_class_file_load_hook() is required, the VM >>> now reports "Tool agent requires sharing to be disabled? and >>> terminates. This is the same behavior as jdk8. With -Xshare:auto The >>> change in meatspace.cpp is to detect the case where >>> JvmtiExport::should_post_class_file_load_hook() is enabled very >>> early during JVM initialization. In that case, we disable CDS >>> entirely, including all shared classes, symbols, and Strings >>> objects. The change in systemDictionary.cpp is to detect the cases >>> where JvmtiExport::should_post_class_file_load_hook() is enabled >>> late, which include agent dynamically attached at runtime. In those >>> cases, JVM does not allow loading classes from the shared archive. >>> The shared symbols and Strings can still be used. Thanks, Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Sat Jul 9 00:47:27 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 08 Jul 2016 17:47:27 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> Message-ID: <5780499F.3020304@oracle.com> Hi Jiangli, I agree what what Karen has said. If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. Also, maybe this check can also be removed? 1247 instanceKlassHandle SystemDictionary::load_shared_class( 1248 Symbol* class_name, Handle class_loader, TRAPS) { 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< Since the same check is already done in the "inner" load_shared_class() method. Thanks - Ioi On 7/8/16 11:18 AM, Jiangli Zhou wrote: > Hi Karen, > > Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. > > Thanks, > Jiangli > >> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >> >> Jiangli, >> >> Thank you so much for picking up this bug fix, I very much appreciate that. >> >> I agree with not quitting the vm on agent attach. >> I actually think we also want the agent attach to succeed - see below. >>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>> >>> (Adding serviceability-dev at openjdk.java.net) >>> >>> Hi Jiangli, >>> >>> I think the two blocks of >>> >>> if (RequireSharedSpaces) { >>> tty->print_cr("An error has occurred while loading shared class."); >>> tty->print_cr("Tool agent requires sharing to be disabled."); >>> vm_exit(1); >>> } >>> >>> should be removed. >> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >> but no forcing of using the shared spaces if there is an agent. >>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >> Totally agree - we should not quit the VM. >> >>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>> >>> jvmtiError >>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>> >>> ... >>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>> + } >>> record_class_file_load_hook_enabled(); >>> } >>> ? >>> } >>> >> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>> Thanks >>> - Ioi >> Jiangli: >> >> Minor code review comments: >> >> metaspace.cpp line 3181: CFHL-> CFLH >> >> metaspace.cpp: >> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >> use locally, so it also could be inside the #if INCLUDE_CDS. >> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >> >> thanks, >> Karen >> >>> >>> >>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>> >>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>> bug: JDK-8141341 >>>> >>>> With -Xshare:on >>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>> >>>> With -Xshare:auto >>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>> >>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> From jiangli.zhou at oracle.com Sat Jul 9 01:04:48 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 18:04:48 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780061C.9020500@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> Message-ID: <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> Hi Serguei, Thank you for looking into the changes. With Ioi and Karen?s suggestion for dynamically attached agent and -Xshare:on, I?m reworking the changes. I?m planning to remove the check below and do that in a later place. I?ll post the new webrev next week. Thanks, Jiangli > On Jul 8, 2016, at 12:59 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jiangli, > > > src/share/vm/memory/metaspace.cpp > > 3177 if (UseSharedSpaces) { > 3178 FileMapInfo* mapinfo = new FileMapInfo(); > 3179 > 3180 if (JvmtiExport::should_post_class_file_load_hook()) { > 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. > 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, > 3183 // just disable UseSharedSpaces. > 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); > 3185 } else { > > > I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. > Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? > > Also, there is a comment below. > > > On 7/7/16 18:56, Ioi Lam wrote: >> (Adding serviceability-dev at openjdk.java.net) >> >> Hi Jiangli, >> >> I think the two blocks of >> >> if (RequireSharedSpaces) { >> tty->print_cr("An error has occurred while loading shared class."); >> tty->print_cr("Tool agent requires sharing to be disabled."); >> vm_exit(1); >> } >> >> should be removed. >> >> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >> >> If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >> >> jvmtiError >> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >> >> ... >> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >> + } >> record_class_file_load_hook_enabled(); >> } >> ... >> } > > > This is a good concern and suggestion. > We may need more sophisticated handling for this. > Sorry, I did not notice it earlier. > > There is a capability can_generate_all_class_hook_events. > We already have this in the prims/jvmtiManageCapabilities.cpp: > > // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: > JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: > > char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } > > So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei >> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: JDK-8141341 With -Xshare:on If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. With -Xshare:auto The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. Thanks, Jiangli From jiangli.zhou at oracle.com Sat Jul 9 01:14:05 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Jul 2016 18:14:05 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <5780499F.3020304@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <98017E2A-7880-4E2A-A540-A1732360E75E@oracle.com> <5780499F.3020304@oracle.com> Message-ID: Hi Ioi, > On Jul 8, 2016, at 5:47 PM, Ioi Lam wrote: > > Hi Jiangli, > > I agree what what Karen has said. > > If the user runs with -Xshare:on, but later attaches an agent, we just pretend that the user had specified -Xshare:auto -- allow the agent to receive all CFLH events, and stop loading from the shared archive. > > We should probably print out a warning message during the first load_share_class() call after the agent attachment, saying that CDS has been disabled due to attaching agent. Agreed. > > Also, maybe this check can also be removed? > > 1247 instanceKlassHandle SystemDictionary::load_shared_class( > 1248 Symbol* class_name, Handle class_loader, TRAPS) { > 1249 if (!JvmtiExport::should_post_class_file_load_hook()) { <<<<<<<<<<<<<<< > > Since the same check is already done in the "inner" load_shared_class() method. I ran into issue with the find_shared_class() before the inner load_shared_class() is called earlier. That?s why the check was done in both load_shared_class. With updated approach, we might no longer need the check here. Thanks, Jiangli > > Thanks > - Ioi > > > On 7/8/16 11:18 AM, Jiangli Zhou wrote: >> Hi Karen, >> >> Thank you for the feedback. I think Ioi and your comments regarding the dynamically attached agent is very reasonable. I will rework the changes. >> >> Thanks, >> Jiangli >> >>> On Jul 8, 2016, at 7:55 AM, Karen Kinnear wrote: >>> >>> Jiangli, >>> >>> Thank you so much for picking up this bug fix, I very much appreciate that. >>> >>> I agree with not quitting the vm on agent attach. >>> I actually think we also want the agent attach to succeed - see below. >>>> On Jul 7, 2016, at 9:56 PM, Ioi Lam wrote: >>>> >>>> (Adding serviceability-dev at openjdk.java.net) >>>> >>>> Hi Jiangli, >>>> >>>> I think the two blocks of >>>> >>>> if (RequireSharedSpaces) { >>>> tty->print_cr("An error has occurred while loading shared class."); >>>> tty->print_cr("Tool agent requires sharing to be disabled."); >>>> vm_exit(1); >>>> } >>>> >>>> should be removed. >>> I agree with this part. I was expecting the else to return a null instanceklasshandle as if the shared class was not found, >>> but no forcing of using the shared spaces if there is an agent. >>>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>> Yes, here it makes sense to do the fail_continue such that RequireSharedSpaces will prevent starting the JVM. >>>> If the agent is attached later, after the VM has started, I think we should not quit the VM. >>> Totally agree - we should not quit the VM. >>> >>>> Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>>> >>>> jvmtiError >>>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>>> >>>> ... >>>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>>> + } >>>> record_class_file_load_hook_enabled(); >>>> } >>>> ? >>>> } >>>> >>> I was expecting the vm to continue running, letting the agent attach (customers really want to use these). >>> Jiangli - if I read your code correctly, that is what you do if UseSharedSpaces but not if RequireSharedSpaces. >>> I would propose that you do the same behavior for both cases once we are up and running - i.e. get rid of the >>> two blocks Ioi suggested removing and just fall through as if the file was not found in the archive regardless of RequireSharedSpaces. >>>> Thanks >>>> - Ioi >>> Jiangli: >>> >>> Minor code review comments: >>> >>> metaspace.cpp line 3181: CFHL-> CFLH >>> >>> metaspace.cpp: >>> I appreciated your moving the if (UseSharedSpaces) into the #INCLUDE_CDS. >>> I think it would make sense to do a bit more of that - e.g. cds_address appears to only be >>> use locally, so it also could be inside the #if INCLUDE_CDS. >>> Would it make sense to have the entire if (DumpSharedSpaces) etc. all be inside a single #if INCLUDE_CDS? >>> >>> thanks, >>> Karen >>> >>>> >>>> >>>> On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ >>>>> bug: JDK-8141341 >>>>> >>>>> With -Xshare:on >>>>> If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. >>>>> >>>>> With -Xshare:auto >>>>> The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. >>>>> >>>>> The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> > From serguei.spitsyn at oracle.com Sat Jul 9 04:39:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Jul 2016 21:39:25 -0700 Subject: RFR: 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true In-Reply-To: <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> References: <8998B669-698D-42E8-9EC5-C5E0C75571DD@oracle.com> <577F0866.2050606@oracle.com> <5780061C.9020500@oracle.com> <6E898B08-564E-454E-9586-D50F2744E714@oracle.com> Message-ID: <57807FFD.1030100@oracle.com> Hi Jiangli, Ok, I'll wait for the next webrev version. Thanks, Serguei On 7/8/16 18:04, Jiangli Zhou wrote: > Hi Serguei, > > Thank you for looking into the changes. With Ioi and Karen?s suggestion for dynamically attached agent and -Xshare:on, I?m reworking the changes. I?m planning to remove the check below and do that in a later place. I?ll post the new webrev next week. > > Thanks, > Jiangli > >> On Jul 8, 2016, at 12:59 PM, serguei.spitsyn at oracle.com wrote: >> >> Hi Jiangli, >> >> >> src/share/vm/memory/metaspace.cpp >> >> 3177 if (UseSharedSpaces) { >> 3178 FileMapInfo* mapinfo = new FileMapInfo(); >> 3179 >> 3180 if (JvmtiExport::should_post_class_file_load_hook()) { >> 3181 // Currently CDS does not support JVMTI CFHL when loading shared class. >> 3182 // If JvmtiExport::should_post_class_file_load_hook is already enabled, >> 3183 // just disable UseSharedSpaces. >> 3184 FileMapInfo::fail_continue("Tool agent requires sharing to be disabled."); >> 3185 } else { >> >> >> I understood, the FileMapInfo::fail_continue() will fail if the RequireSharedSpaces is enabled which is expected. >> Should the mapinfo be deallocated in the case FileMapInfo::fail_continue() is called? >> >> Also, there is a comment below. >> >> >> On 7/7/16 18:56, Ioi Lam wrote: >>> (Adding serviceability-dev at openjdk.java.net) >>> >>> Hi Jiangli, >>> >>> I think the two blocks of >>> >>> if (RequireSharedSpaces) { >>> tty->print_cr("An error has occurred while loading shared class."); >>> tty->print_cr("Tool agent requires sharing to be disabled."); >>> vm_exit(1); >>> } >>> >>> should be removed. >>> >>> If the agent is specified in the command line, the JVM start would be aborted. This is already handled by your changes to src/share/vm/memory/metaspace.cpp >>> >>> If the agent is attached later, after the VM has started, I think we should not quit the VM. Consider this scenario -- a production server could be running for a long time without issues using -Xshare:on, then when the user attaches a diagnostic agent the JVM suddenly quits. I think it's better to cause the agent attachment to fail with something like >>> >>> jvmtiError >>> JvmtiEnv::SetEventNotificationMode(jvmtiEventMode mode, jvmtiEvent event_type, jthread event_thread, ...) { >>> >>> ... >>> if (event_type == JVMTI_EVENT_CLASS_FILE_LOAD_HOOK && enabled) { >>> + if (RequireSharedSpaces && !universe::is_bootstraping()) { >>> + tty->print_cr("Tool agent that requires JVMTI_EVENT_CLASS_FILE_LOAD_HOOK cannot be dynamically loaded after JVM has started"); >>> + return JVMTI_ERROR_ILLEGAL_ARGUMENT; >>> + } >>> record_class_file_load_hook_enabled(); >>> } >>> ... >>> } >> >> This is a good concern and suggestion. >> We may need more sophisticated handling for this. >> Sorry, I did not notice it earlier. >> >> There is a capability can_generate_all_class_hook_events. >> We already have this in the prims/jvmtiManageCapabilities.cpp: >> >> // if the capability sets are initialized in the onload phase then // it happens before class data sharing (CDS) is initialized. If it // turns out that CDS gets disabled then we must adjust the always // capabilities. To ensure a consistent view of the capabililties // anything we add here should already be in the onload set. void JvmtiManageCapabilities::recompute_always_capabilities() { if (!UseSharedSpaces) { jvmtiCapabilities jc = always_capabilities; jc.can_generate_all_class_hook_events = 1; always_capabilities = jc; } } If enabled can_generate_all_class_hook_events sets the flagJvmtiExport::can_modify_any_class() in jvmtiManageCapabilities.cpp: >> JvmtiExport::set_can_modify_any_class( avail.can_generate_breakpoint_events || avail.can_generate_all_class_hook_events); The flag JvmtiExport::can_modify_any_class() is used here: >> >> char* FileMapInfo::map_region(int i) { . . . // If a tool agent is in use (debugging enabled), we must map the address space RW if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) { si->_read_only = false; } >> >> So, I'm thinking if we could just skip the CFLH events for the shared classes if the capability can_generate_all_class_hook_events is not enabled and continue posting the events for non-shared classes. Then we do not need to tweak the SetEventNotificationMode() implementation. Otherwise, the fragment above may need to be updated too. To summarize, I understood that the current approach/plan for JDK 9 is: - Disable the CDS if detected early that the CFLH events are enabled - Skip the CFLH events for shared classes if CFLH is enabled late Is this right? Is it the same as in the JDK 8? Thanks, Serguei >>> Thanks - Ioi On 7/7/16 6:08 PM, Jiangli Zhou wrote: >>>> Please review the following webrev that disables CDS when JvmtiExport::should_post_class_file_load_hook() is enabled at runtime. webrev: http://cr.openjdk.java.net/~jiangli/8141341/webrev.00/ bug: JDK-8141341 With -Xshare:on If -Xshare:on is used and JvmtiExport::should_post_class_file_load_hook() is required, the VM now reports "Tool agent requires sharing to be disabled? and terminates. This is the same behavior as jdk8. With -Xshare:auto The change in meatspace.cpp is to detect the case where JvmtiExport::should_post_class_file_load_hook() is enabled very early during JVM initialization. In that case, we disable CDS entirely, including all shared classes, symbols, and Strings objects. The change in systemDictionary.cpp is to detect the cases where JvmtiExport::should_post_class_file_load_hook() is enabled late, which include agent dynamically attached at runtime. In those cases, JVM does not allow loading classes from the shared archive. The shared symbols and Strings can still be used. Thanks, Jiangli From Alan.Bateman at oracle.com Sun Jul 10 08:34:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 10 Jul 2016 09:34:30 +0100 Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> Message-ID: <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> On 08/07/2016 05:57, Sharath Ballal wrote: > > Hello, > > Please review the fix for: > > JDK-8158050 - > *Remove SA-JDI* > > The webrev is at: > > http://cr.openjdk.java.net/~sballal/8158050/webrev.01/index.html > > > The fix is for removing the SA-JDI code and jsadebugd. Jsadebugd is > being moved to jhsdb as part of another bug (review will be sent next). > > This looks good. One surprise is that I assumed there would be more updates or removal of tests needed but it seems not to be the case. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Sun Jul 10 11:11:09 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 10 Jul 2016 14:11:09 +0300 Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> Message-ID: <1717b259-c67e-656f-b778-69a4da1bd8d0@oracle.com> Sharath, Looks good for me. -Dmitry On 2016-07-08 07:57, Sharath Ballal wrote: > Hello, > > Please review the fix for: > > JDK-8158050 - > *Remove SA-JDI* > > > > The webrev is at: > > http://cr.openjdk.java.net/~sballal/8158050/webrev.01/index.html > > > > The fix is for removing the SA-JDI code and jsadebugd. Jsadebugd is > being moved to jhsdb as part of another bug (review will be sent next). > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sun Jul 10 19:14:46 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 10 Jul 2016 22:14:46 +0300 Subject: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb In-Reply-To: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> References: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> Message-ID: Sharath, Looks good for me. -Dmitry On 2016-07-08 18:06, Sharath Ballal wrote: > Hello, > > Please review the fix for: > > JDK-8160817 - *Add > jsadebugd and classLoaderStat functionality to jhsdb* > > Webrev is at: > > http://cr.openjdk.java.net/~sballal/8160817/webrev.00/index.html > > > > This fix moves the jsadebugd and classLoaderStat functionality to jhsdb > and move the TestClassLoaderStats.java functionality to > BasicLauncherTest.java. > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Mon Jul 11 02:07:11 2016 From: jini.george at oracle.com (Jini George) Date: Sun, 10 Jul 2016 19:07:11 -0700 (PDT) Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> Message-ID: <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> Hi, Gentle Reminder! Thanks, Jini. From: Jini George Sent: Tuesday, July 05, 2016 9:54 PM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi all, Please review the fix in Serviceability Agent (SA) for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) The webrev is at: http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ The modifications include the fix and 2 tests to check the InstanceKlass sizes representing some well known classes and that of an interface. The tests compare the sizes returned by SA to those returned by jcmd. At this point, SA cannot view the InstanceKlasses representing anonymous classes. (This issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160228"JDK-8160228 (SA cannot view the LambdaMetaFactory generated anonymous instanceKlasses)). Hence the current fix does not include the size addition for InstanceKlasses representing anonymous classes. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Jul 11 08:22:38 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Jul 2016 11:22:38 +0300 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> Message-ID: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> PING ... -------- Forwarded Message -------- Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase Date: Wed, 6 Jul 2016 19:24:15 +0300 From: Dmitry Samersoff To: serviceability-dev at openjdk.java.net Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ All credentials belongs to Richard Reingruber, see mail thread (below) for details. http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Mon Jul 11 09:31:16 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Jul 2016 09:31:16 +0000 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> Message-ID: <51cd5f93473b44eeb889fb5c5212f5ad@DEWDFE13DE09.global.corp.sap> Hi Dmitry, thanks for looking at this issue. I think your fix will crash if thread->jvmti_thread_state(); returns NULL. Also, please add the #include with leading directory prims/ at the proper alphabetic position. Also, you could add the test Richard supplied, see below. Best regards, Goetz. --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/serviceability/jvmti/ExceptionCaughtOutOfPhaseAssertion.java Mon Jul 11 11:30:12 2016 +0200 @@ -0,0 +1,55 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import java.security.AccessController; +import java.security.PrivilegedAction; + +/* + * @test + * @bug 8134434 + * @summary JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase + * @run main/othervm -agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch ExceptionCaughtOutOfPhaseAssertion + */ + +public class ExceptionCaughtOutOfPhaseAssertion { + public static void main(String[] args) { + PrivilegedAction action = new HotThrowingAction(); + System.out.println("### Warm-up"); + for(int i=0; i<11000; i++) { + try { + action.run(); // call run() to get it compiled + } catch(Throwable t) { /* ignored */ } + } + System.out.println("### Warm-up done"); + System.out.println("### Executing privileged action"); + try { + AccessController.doPrivileged(action); + } catch (Error e) { + } + } + public static class HotThrowingAction implements PrivilegedAction { + public Object run() { + throw new Error(); + } + } +} > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Dmitry Samersoff > Sent: Montag, 11. Juli 2016 10:23 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev runtime-dev at openjdk.java.net> > Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > > PING ... > > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > Date: Wed, 6 Jul 2016 19:24:15 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > > All credentials belongs to Richard Reingruber, see mail thread (below) > for details. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- > August/019613.html > > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Mon Jul 11 13:35:35 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 11 Jul 2016 09:35:35 -0400 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> Message-ID: <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> Adding hotspot-compiler-dev since the change is in opto/runtime.cpp Coleen On 7/11/16 4:22 AM, Dmitry Samersoff wrote: > PING ... > > > -------- Forwarded Message -------- > Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > Date: Wed, 6 Jul 2016 19:24:15 +0300 > From: Dmitry Samersoff > To: serviceability-dev at openjdk.java.net > > > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > > All credentials belongs to Richard Reingruber, see mail thread (below) > for details. > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html > > > -Dmitry > From dmitry.samersoff at oracle.com Mon Jul 11 13:51:02 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 11 Jul 2016 16:51:02 +0300 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> Message-ID: <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Everybody, Updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ Testcase added. Goetz's concerns addressed. -Dmitry On 2016-07-11 16:35, Coleen Phillimore wrote: > Adding hotspot-compiler-dev since the change is in opto/runtime.cpp > > Coleen > > On 7/11/16 4:22 AM, Dmitry Samersoff wrote: >> PING ... >> >> >> -------- Forwarded Message -------- >> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires >> assert(_exception_caught == false) failed: _exception_caught is out of >> phase >> Date: Wed, 6 Jul 2016 19:24:15 +0300 >> From: Dmitry Samersoff >> To: serviceability-dev at openjdk.java.net >> >> >> Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ >> >> All credentials belongs to Richard Reingruber, see mail thread (below) >> for details. >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-August/019613.html >> >> >> >> -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 goetz.lindenmaier at sap.com Mon Jul 11 14:06:17 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 11 Jul 2016 14:06:17 +0000 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Message-ID: Hi Dmitry, thanks fort he fixed, looks good now. Best regards, Goetz. > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Montag, 11. Juli 2016 15:51 > To: Coleen Phillimore ; serviceability- > dev at openjdk.java.net; hotspot-runtime-dev dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net; > Lindenmaier, Goetz > Subject: Re: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires > assert(_exception_caught == false) failed: _exception_caught is out of phase > > Everybody, > > Updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ > > Testcase added. Goetz's concerns addressed. > > -Dmitry > > > On 2016-07-11 16:35, Coleen Phillimore wrote: > > Adding hotspot-compiler-dev since the change is in opto/runtime.cpp > > > > Coleen > > > > On 7/11/16 4:22 AM, Dmitry Samersoff wrote: > >> PING ... > >> > >> > >> -------- Forwarded Message -------- > >> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires > >> assert(_exception_caught == false) failed: _exception_caught is out of > >> phase > >> Date: Wed, 6 Jul 2016 19:24:15 +0300 > >> From: Dmitry Samersoff > >> To: serviceability-dev at openjdk.java.net > >> > >> > >> Everybody, > >> > >> Please review the fix. > >> > >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ > >> > >> All credentials belongs to Richard Reingruber, see mail thread (below) > >> for details. > >> > >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- > August/019613.html > >> > >> > >> > >> -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 sharath.ballal at oracle.com Mon Jul 11 17:17:34 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 11 Jul 2016 10:17:34 -0700 (PDT) Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> Message-ID: Alan, I have updated the review by removing certain tests from the 'src' directory (which I believe are obsolete). The SQE will be removing the tests owned by them separately, they have already quarantined the relevant tests. http://cr.openjdk.java.net/~sballal/8158050/webrev.02/index.html -Sharath Ballal From: Alan Bateman Sent: Sunday, July 10, 2016 2:04 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8158050: Remove SA-JDI On 08/07/2016 05:57, Sharath Ballal wrote: Hello, Please review the fix for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8158050"JDK-8158050 - Remove SA-JDI The webrev is at: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8158050/webrev.01/index.html"http://cr.openjdk.java.net/~sballal/8158050/webrev.01/index.html The fix is for removing the SA-JDI code and jsadebugd. Jsadebugd is being moved to jhsdb as part of another bug (review will be sent next). This looks good. One surprise is that I assumed there would be more updates or removal of tests needed but it seems not to be the case. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Mon Jul 11 17:17:45 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 11 Jul 2016 10:17:45 -0700 (PDT) Subject: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb In-Reply-To: References: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> Message-ID: I have updated the review by adding SADebugDTest.java http://cr.openjdk.java.net/~sballal/8160817/webrev.01/index.html -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Monday, July 11, 2016 12:45 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb Sharath, Looks good for me. -Dmitry On 2016-07-08 18:06, Sharath Ballal wrote: > Hello, > > Please review the fix for: > > JDK-8160817 - *Add > jsadebugd and classLoaderStat functionality to jhsdb* > > Webrev is at: > > http://cr.openjdk.java.net/~sballal/8160817/webrev.00/index.html > > > > This fix moves the jsadebugd and classLoaderStat functionality to > jhsdb and move the TestClassLoaderStats.java functionality to > BasicLauncherTest.java. > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Mon Jul 11 17:21:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Jul 2016 18:21:20 +0100 Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> Message-ID: <532ea808-a020-b5fe-e58a-e1b535e157d4@oracle.com> On 11/07/2016 18:17, Sharath Ballal wrote: > > Alan, > > I have updated the review by removing certain tests from the ?src? > directory (which I believe are obsolete). The SQE will be removing > the tests owned by them separately, they have already quarantined the > relevant tests. > > http://cr.openjdk.java.net/~sballal/8158050/webrev.02/index.html > > > Okay. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Jul 12 04:01:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2016 14:01:48 +1000 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> Message-ID: <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> Hi Ivan, On 7/07/2016 2:55 AM, Ivan Gerasimov wrote: > Hello! > > When fixing JDK-8069048 a potential race was overlooked: > 1) Thread A wants to call _endthreadex() and registers itself, > 2) Thread B wants to call exit(), takes its turn and raises the flag > `process_exiting`, > 3) Thread A continues, and gets captured in the loop at 4020, in > SuspendThread(GetCurrentThread()), > 4) Now, the thread B will have to wait for all the registered threads, > including the thread A, which will never wake up. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892 > WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/ Nit: can we change 'registered_itself" to just "registered" please. Can you explain under what conditions a thread will now reach the self-suspension code. Is that only if an error occurred such that we were unable to register our handle for the process-exiting thread to wait on? If so some commentary on that block seems appropriate - perhaps more appropriate there than back up at the place where it failed to get the handle (as Dan requested). Given we keep missing conditions I'm only cautiously optimistic about this. And I'd like to understand how we still sometimes end up exiting with an "error code" that seems to be the value of an exception! :( Thanks, David > With kind regards, > Ivan > From serguei.spitsyn at oracle.com Tue Jul 12 15:37:17 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Jul 2016 08:37:17 -0700 Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: References: <2ddf4f78-f7ff-a11a-8ccb-156cc540ffaf@oracle.com> <5ab71cc9-3c9d-6284-adaa-84293e1ad6c8@oracle.com> <679d1b14-aa8d-ccdc-05c0-21b7a06ad60f@oracle.com> <31dfef13-af59-18f5-4bc4-20fab1287c8e@oracle.com> Message-ID: <57850EAD.7060203@oracle.com> Hi Dmitry, The fix and test look good. Thanks, Serguei On 7/11/16 07:06, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks fort he fixed, looks good now. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Montag, 11. Juli 2016 15:51 >> To: Coleen Phillimore ; serviceability- >> dev at openjdk.java.net; hotspot-runtime-dev > dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net; >> Lindenmaier, Goetz >> Subject: Re: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires >> assert(_exception_caught == false) failed: _exception_caught is out of phase >> >> Everybody, >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/ >> >> Testcase added. Goetz's concerns addressed. >> >> -Dmitry >> >> >> On 2016-07-11 16:35, Coleen Phillimore wrote: >>> Adding hotspot-compiler-dev since the change is in opto/runtime.cpp >>> >>> Coleen >>> >>> On 7/11/16 4:22 AM, Dmitry Samersoff wrote: >>>> PING ... >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires >>>> assert(_exception_caught == false) failed: _exception_caught is out of >>>> phase >>>> Date: Wed, 6 Jul 2016 19:24:15 +0300 >>>> From: Dmitry Samersoff >>>> To: serviceability-dev at openjdk.java.net >>>> >>>> >>>> Everybody, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/ >>>> >>>> All credentials belongs to Richard Reingruber, see mail thread (below) >>>> for details. >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015- >> August/019613.html >>>> >>>> >>>> -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 amit.sapre at oracle.com Wed Jul 13 10:56:04 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 13 Jul 2016 03:56:04 -0700 (PDT) Subject: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. Message-ID: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> Hello, Please review the fix Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Wed Jul 13 11:01:28 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 13 Jul 2016 04:01:28 -0700 (PDT) Subject: RFR : JDK-8158350 Table in ThreadInfo.from(CompositeData) may need updates for new stack trace attributes Message-ID: Hello, Please review the javadoc update Bug ID : https://bugs.openjdk.java.net/browse/JDK-8158350 webrev : http://cr.openjdk.java.net/~hb/sponsorship/8158350/webrev.01/ Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Jul 13 11:06:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Jul 2016 19:06:22 +0800 Subject: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. In-Reply-To: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> References: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> Message-ID: > On Jul 13, 2016, at 6:56 PM, Amit Sapre wrote: > > Hello, > Please review the fix > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ Looks okay. You could rename the method to load_and_initialize_klass_or_null to follow the existing naming convention. This patch needs to include the test attached in the bug report. Mandy From david.holmes at oracle.com Thu Jul 14 00:55:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Jul 2016 10:55:19 +1000 Subject: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. In-Reply-To: References: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> Message-ID: <42e2bf24-10cd-dfc2-05bf-8e3a83f000e4@oracle.com> On 13/07/2016 9:06 PM, Mandy Chung wrote: > >> On Jul 13, 2016, at 6:56 PM, Amit Sapre wrote: >> >> Hello, >> Please review the fix >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 >> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ > > Looks okay. > > You could rename the method to load_and_initialize_klass_or_null to follow the existing naming convention. +1 on that "softload" is not suitable. My concern is that the code that calls Management::com_sun_management_internal_GarbageCollectorExtImpl_klass does not seem to handle getting NULL correctly: ./share/vm/services/memoryManager.cpp ./share/vm/services/gcNotifier.cpp Thanks, David ----- > This patch needs to include the test attached in the bug report. > > Mandy > From mandy.chung at oracle.com Thu Jul 14 06:01:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Jul 2016 14:01:54 +0800 Subject: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. In-Reply-To: <42e2bf24-10cd-dfc2-05bf-8e3a83f000e4@oracle.com> References: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> <42e2bf24-10cd-dfc2-05bf-8e3a83f000e4@oracle.com> Message-ID: > On Jul 14, 2016, at 8:55 AM, David Holmes wrote: > > On 13/07/2016 9:06 PM, Mandy Chung wrote: >> >>> On Jul 13, 2016, at 6:56 PM, Amit Sapre wrote: >>> >>> Hello, >>> Please review the fix >>> >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 >>> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ >> >> Looks okay. >> >> You could rename the method to load_and_initialize_klass_or_null to follow the existing naming convention. > > +1 on that "softload" is not suitable. > > My concern is that the code that calls Management::com_sun_management_internal_GarbageCollectorExtImpl_klass > does not seem to handle getting NULL correctly: > > ./share/vm/services/memoryManager.cpp > ./share/vm/services/gcNotifier.cpp Thanks for pointing this out. We will need to make sure that when jdk.management is present, it will create com.sun.management.internal.GarbageCollectorExtImpl as the GC memory manager objects for jmm_GetMemoryManagers. That implements com.sun.management.GarbageCollectorMXBean. When jdk.management is not present, it should return sun.management.GarbageCollectorImpl instead that implements java.lang.management.GarbageCollectorMXBean. gcNotifier implements both com.sun.management.GcInfo as well as java.lang.management.MemoryPoolMXBean notification. More surgery might need to be done to make sure the implementation handles properly when jdk.management is present and absent. Mandy From egor.ushakov at jetbrains.com Thu Jul 14 09:33:59 2016 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Thu, 14 Jul 2016 12:33:59 +0300 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: References: Message-ID: Hi, I'm a developer from IDEA debugger (we have company OCA). We've increased usage of ReferenceTypeImpl.constantPool and now facing JDK-6822627 more often. Please review and sponsor the fix. The problem was that constantPoolBytesRef SoftReference value coud be GCed and there was no check for that. I've added it to the check inside getConstantPoolInfo to request the bytes again in this case. BUGURL: https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From amit.sapre at oracle.com Thu Jul 14 11:50:55 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Thu, 14 Jul 2016 11:50:55 +0000 (UTC) Subject: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. In-Reply-To: References: <4b054323-ac92-4e70-8f80-bb7af91729dc@default> <42e2bf24-10cd-dfc2-05bf-8e3a83f000e4@oracle.com> Message-ID: <4fd1a295-4210-4615-b5d4-bef822242aa4@default> Thanks Alan & Mandy for your review comments. I will incorporate your comments and send a fresh review. Amit -----Original Message----- From: Mandy Chung Sent: Thursday, July 14, 2016 11:32 AM To: David Holmes Cc: Amit Sapre; serviceability-dev; Daniel Fuchs Subject: Re: RFR : JDK-8151099 : java.lang.management.ManagementFactory.getPlatformMXBeans() should work even if jdk.management is not present. > On Jul 14, 2016, at 8:55 AM, David Holmes wrote: > > On 13/07/2016 9:06 PM, Mandy Chung wrote: >> >>> On Jul 13, 2016, at 6:56 PM, Amit Sapre wrote: >>> >>> Hello, >>> Please review the fix >>> >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8151099 >>> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8151099/webrev.00/ >> >> Looks okay. >> >> You could rename the method to load_and_initialize_klass_or_null to follow the existing naming convention. > > +1 on that "softload" is not suitable. > > My concern is that the code that calls Management::com_sun_management_internal_GarbageCollectorExtImpl_klass > does not seem to handle getting NULL correctly: > > ./share/vm/services/memoryManager.cpp > ./share/vm/services/gcNotifier.cpp Thanks for pointing this out. We will need to make sure that when jdk.management is present, it will create com.sun.management.internal.GarbageCollectorExtImpl as the GC memory manager objects for jmm_GetMemoryManagers. That implements com.sun.management.GarbageCollectorMXBean. When jdk.management is not present, it should return sun.management.GarbageCollectorImpl instead that implements java.lang.management.GarbageCollectorMXBean. gcNotifier implements both com.sun.management.GcInfo as well as java.lang.management.MemoryPoolMXBean notification. More surgery might need to be done to make sure the implementation handles properly when jdk.management is present and absent. Mandy From martinrb at google.com Thu Jul 14 17:06:41 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 14 Jul 2016 10:06:41 -0700 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: References: Message-ID: The lack of volatile or synchronization, plus the use of multiple mutable fields, suggests that a deeper fix is necessary to be truly correct. For comparison, much of the similar code implementing reflection has been changed to use volatile. But that's a big job, for the serviceability team. On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov wrote: > Hi, > > I'm a developer from IDEA debugger (we have company OCA). > We've increased usage of ReferenceTypeImpl.constantPool and now facing > JDK-6822627 more often. > Please review and sponsor the fix. > > The problem was that constantPoolBytesRef SoftReference value coud be > GCed and there was no check for that. > I've added it to the check inside getConstantPoolInfo to request the > bytes again in this case. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6822627 > WEBREV: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ > > Thanks! > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Jul 14 18:46:19 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 14 Jul 2016 21:46:19 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> Message-ID: <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> Thank you David for looking into this! Here's the webrev updated in accordance with your and Daniel's suggestions: http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Please see my answers inline > Nit: can we change 'registered_itself" to just "registered" please. Done. > > Can you explain under what conditions a thread will now reach the > self-suspension code. Is that only if an error occurred such that we > were unable to register our handle for the process-exiting thread to > wait on? If so some commentary on that block seems appropriate - > perhaps more appropriate there than back up at the place where it > failed to get the handle (as Dan requested). > There are three kinds of threads, which can be caught in that self-suspension loop: 1) All threads that want to end (by calling _endthreadex()) *after* some process-exiting thread raised the flag `process_exiting`. The rationale here is that we know that the whole process is going to be terminated quite soon, so we do not allow any thread to call _endthreadex(), which seems to have the concurrency bug. 2) Any thread that wants to end the whole process, after some other thread raised the flag `process_exiting`. If more than one threads want to end the process, we let to do it only the thread that could raise the flag `process_exiting`. All other such threads will have to suspend themselves. 3) (Unlikely to happen in practice) Any thread that wants to end by calling _endthreadex(), but which failed to register itself due to failure of DuplicateHandle(). Here we still have a race, which can result in a wrong exit code of the process. > Given we keep missing conditions I'm only cautiously optimistic about > this. > And I'd like to understand how we still sometimes end up exiting with > an "error code" that seems to be the value of an exception! :( The last time the sentinel exit code =20115 was reported almost a year ago. After that the fix for JDK-8145127 had gone in, and I didn't see any more reports about wrong exit codes since then. In particular, that fix worked around the situation when more than one threads concurrently call System.exit(), which might have caused a race. With kind regards, Ivan > > Thanks, > David > >> With kind regards, >> Ivan >> > From Alan.Bateman at oracle.com Thu Jul 14 21:27:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jul 2016 22:27:58 +0100 Subject: RFR : JDK-8158350 Table in ThreadInfo.from(CompositeData) may need updates for new stack trace attributes In-Reply-To: References: Message-ID: <6ad5a4d8-2e40-3ec1-f526-a8c1d3c6d4c3@oracle.com> On 13/07/2016 12:01, Amit Sapre wrote: > > Hello, > > Please review the javadoc update > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8158350 > > webrev : http://cr.openjdk.java.net/~hb/sponsorship/8158350/webrev.01/ > > > Looks good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Jul 14 21:31:12 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 15:31:12 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> Message-ID: <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: > Thank you David for looking into this! > > Here's the webrev updated in accordance with your and Daniel's > suggestions: > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ src/os/windows/vm/os_windows.cpp L3900: bool registered = false; Please consider adding a comment above this variable: // We only attempt to register threads until a process exiting // thread manages to set the process_exiting flag. Any threads // that come through here after the process_exiting flag is set // are unregistered and will be caught in the SuspendThread() // infinite loop below. My request is different than David's. I prefer the comment up here by the 'registered' variable because that variable is key for getting into the SuspendThread() infinite loop. The comment also occurs before all the code paths that you have trace out with the different Ept types and flags states. I'm really hoping that this is the last tweak we need to make to clearly comment what we're doing to alleviate this OS race. The number of occurrences of the underlying bug keep going down with every iteration so we're getting close. Dan > > Please see my answers inline > > >> Nit: can we change 'registered_itself" to just "registered" please. > Done. > >> >> Can you explain under what conditions a thread will now reach the >> self-suspension code. Is that only if an error occurred such that we >> were unable to register our handle for the process-exiting thread to >> wait on? If so some commentary on that block seems appropriate - >> perhaps more appropriate there than back up at the place where it >> failed to get the handle (as Dan requested). >> > There are three kinds of threads, which can be caught in that > self-suspension loop: > 1) All threads that want to end (by calling _endthreadex()) *after* > some process-exiting thread raised the flag `process_exiting`. > The rationale here is that we know that the whole process is going to > be terminated quite soon, so we do not allow any thread to call > _endthreadex(), which seems to have the concurrency bug. > 2) Any thread that wants to end the whole process, after some other > thread raised the flag `process_exiting`. > If more than one threads want to end the process, we let to do it only > the thread that could raise the flag `process_exiting`. All other > such threads will have to suspend themselves. > 3) (Unlikely to happen in practice) Any thread that wants to end by > calling _endthreadex(), but which failed to register itself due to > failure of DuplicateHandle(). > Here we still have a race, which can result in a wrong exit code of > the process. > >> Given we keep missing conditions I'm only cautiously optimistic about >> this. >> And I'd like to understand how we still sometimes end up exiting with >> an "error code" that seems to be the value of an exception! :( > > The last time the sentinel exit code =20115 was reported almost a year > ago. > After that the fix for JDK-8145127 had gone in, and I didn't see any > more reports about wrong exit codes since then. > In particular, that fix worked around the situation when more than one > threads concurrently call System.exit(), which might have caused a race. > > With kind regards, > Ivan > >> >> Thanks, >> David >> >>> With kind regards, >>> Ivan >>> >> > From ivan.gerasimov at oracle.com Thu Jul 14 22:57:22 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 15 Jul 2016 01:57:22 +0300 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> Message-ID: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Hey! I've updated the webrev in place at http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ On 15.07.2016 0:31, Daniel D. Daugherty wrote: > On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >> Thank you David for looking into this! >> >> Here's the webrev updated in accordance with your and Daniel's >> suggestions: >> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ > > src/os/windows/vm/os_windows.cpp > L3900: bool registered = false; > Please consider adding a comment above this variable: > > // We only attempt to register threads until a process exiting > // thread manages to set the process_exiting flag. Any threads > // that come through here after the process_exiting flag is set > // are unregistered and will be caught in the SuspendThread() > // infinite loop below. > Sure. Added this comment. > My request is different than David's. I prefer the comment up > here by the 'registered' variable because that variable is > key for getting into the SuspendThread() infinite loop. The > comment also occurs before all the code paths that you have > trace out with the different Ept types and flags states. > > I'm really hoping that this is the last tweak we need to make to > clearly comment what we're doing to alleviate this OS race. > The number of occurrences of the underlying bug keep going down > with every iteration so we're getting close. > Yes. This is my hope too. With kind regards, Ivan From daniel.daugherty at oracle.com Thu Jul 14 23:01:53 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2016 17:01:53 -0600 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Message-ID: <81e46d34-a40a-421f-0fed-fe825999e91c@oracle.com> On 7/14/16 4:57 PM, Ivan Gerasimov wrote: > Hey! > > I've updated the webrev in place at > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Thumbs up! Dan > > On 15.07.2016 0:31, Daniel D. Daugherty wrote: >> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >>> Thank you David for looking into this! >>> >>> Here's the webrev updated in accordance with your and Daniel's >>> suggestions: >>> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> L3900: bool registered = false; >> Please consider adding a comment above this variable: >> >> // We only attempt to register threads until a process exiting >> // thread manages to set the process_exiting flag. Any threads >> // that come through here after the process_exiting flag is set >> // are unregistered and will be caught in the SuspendThread() >> // infinite loop below. >> > Sure. Added this comment. > >> My request is different than David's. I prefer the comment up >> here by the 'registered' variable because that variable is >> key for getting into the SuspendThread() infinite loop. The >> comment also occurs before all the code paths that you have >> trace out with the different Ept types and flags states. >> >> I'm really hoping that this is the last tweak we need to make to >> clearly comment what we're doing to alleviate this OS race. >> The number of occurrences of the underlying bug keep going down >> with every iteration so we're getting close. >> > Yes. This is my hope too. > > With kind regards, > Ivan > From david.holmes at oracle.com Fri Jul 15 03:13:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2016 13:13:18 +1000 Subject: RFR 8160892: VM warning: WaitForMultipleObjects timed out In-Reply-To: <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> References: <78049fca-b889-3741-5a99-58bbb9dec782@oracle.com> <244fd6d5-0f97-0522-6932-2bae3ee85fd0@oracle.com> <8361b005-8896-caa4-e207-8e33bee8db13@oracle.com> <8f195c06-741a-5bb9-b979-f04ccf091ccc@oracle.com> <58f8ef00-3379-0f11-867b-013609bda32d@oracle.com> Message-ID: <13836979-c602-bc80-1af4-ef2a2bf5bef4@oracle.com> On 15/07/2016 8:57 AM, Ivan Gerasimov wrote: > Hey! > > I've updated the webrev in place at > http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Thanks Ivan - looks good. See also: https://bugs.openjdk.java.net/browse/JDK-8160596 https://bugs.openjdk.java.net/browse/JDK-8079441 regarding strange exit code values being seen. David > On 15.07.2016 0:31, Daniel D. Daugherty wrote: >> On 7/14/16 12:46 PM, Ivan Gerasimov wrote: >>> Thank you David for looking into this! >>> >>> Here's the webrev updated in accordance with your and Daniel's >>> suggestions: >>> http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ >> >> src/os/windows/vm/os_windows.cpp >> L3900: bool registered = false; >> Please consider adding a comment above this variable: >> >> // We only attempt to register threads until a process exiting >> // thread manages to set the process_exiting flag. Any threads >> // that come through here after the process_exiting flag is set >> // are unregistered and will be caught in the SuspendThread() >> // infinite loop below. >> > Sure. Added this comment. > >> My request is different than David's. I prefer the comment up >> here by the 'registered' variable because that variable is >> key for getting into the SuspendThread() infinite loop. The >> comment also occurs before all the code paths that you have >> trace out with the different Ept types and flags states. >> >> I'm really hoping that this is the last tweak we need to make to >> clearly comment what we're doing to alleviate this OS race. >> The number of occurrences of the underlying bug keep going down >> with every iteration so we're getting close. >> > Yes. This is my hope too. > > With kind regards, > Ivan > From egor.ushakov at jetbrains.com Fri Jul 15 07:03:42 2016 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 15 Jul 2016 10:03:42 +0300 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: References: Message-ID: Thanks for your comments! I totally agree that the code there requires major refactoring. In the fix I tried not to make it worse and fix the NPE. On 14.07.2016 20:06, Martin Buchholz wrote: > The lack of volatile or synchronization, plus the use of multiple > mutable fields, suggests that a deeper fix is necessary to be truly > correct. For comparison, much of the similar code implementing > reflection has been changed to use volatile. But that's a big job, > for the serviceability team. > > On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov > > wrote: > > Hi, > > I'm a developer from IDEA debugger (we have company OCA). > We've increased usage of ReferenceTypeImpl.constantPool and now facing > JDK-6822627 more often. > Please review and sponsor the fix. > > The problem was that constantPoolBytesRef SoftReference value coud be > GCed and there was no check for that. > I've added it to the check inside getConstantPoolInfo to request the > bytes again in this case. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6822627 > WEBREV: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ > > > Thanks! > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 15 09:22:26 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Jul 2016 02:22:26 -0700 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: References: Message-ID: <5788AB52.40605@oracle.com> Hi Egor, The fix looks good modulo the synchronization issue. Do you have a jtreg unit test reproducing this failure mode? We have a rule to provide a test coverage for the fixes. Thanks, Serguei On 7/15/16 00:03, Egor Ushakov wrote: > > Thanks for your comments! > > I totally agree that the code there requires major refactoring. In the > fix I tried not to make it worse and fix the NPE. > > > On 14.07.2016 20:06, Martin Buchholz wrote: >> The lack of volatile or synchronization, plus the use of multiple >> mutable fields, suggests that a deeper fix is necessary to be truly >> correct. For comparison, much of the similar code implementing >> reflection has been changed to use volatile. But that's a big job, >> for the serviceability team. >> >> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >> > wrote: >> >> Hi, >> >> I'm a developer from IDEA debugger (we have company OCA). >> We've increased usage of ReferenceTypeImpl.constantPool and now >> facing >> JDK-6822627 more often. >> Please review and sponsor the fix. >> >> The problem was that constantPoolBytesRef SoftReference value coud be >> GCed and there was no check for that. >> I've added it to the check inside getConstantPoolInfo to request the >> bytes again in this case. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6822627 >> WEBREV: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >> >> >> Thanks! >> >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop >> >> > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jul 15 09:50:39 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Jul 2016 02:50:39 -0700 Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> Message-ID: <5788B1EF.1030303@oracle.com> Hi Jini, Some questions. Is the call of the method alignSize(size) necessary? It seems that the size is already aligned by the way it is calculated as the number of words is multiplied to wordLength. But I'm not exactly sure because the wordLength is returned by VM.getVM().getAddressSize() but the VM.getVM().getBytesPerWord() is used in the alignSize: public static long alignSize(long size) { // natural word size return VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); } So, the question is why did you use the getAddressSize() but not the getBytesPerWord()? Do they always return the same number? Just would like to understand your reasoning. :) Some nits: test/serviceability/sa/TestInstanceKlassSize.java 138 for (String s:output.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), ... 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { A space is needed after the ':' sign at L138, L166. Space is not needed after the 'contains' at L139, L141. test/serviceability/sa/TestInstanceKlassSizeForInterface.java 138 for (String s:SAOutput.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), A space is needed after the ':' sign at L138. Space is not needed after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, Jini George wrote: > > Hi, > > Gentle Reminder! > > Thanks, > > Jini. > > *From:*Jini George *Sent:* Tuesday, July 05, 2016 9:54 PM *To:* > serviceability-dev at openjdk.java.net *Subject:* RFR: JDK-8145627 > (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect > size and has no test) > > Hi all, > > Please review the fix in Serviceability Agent (SA) for: > > JDK-8145627 > (sun.jvm.hotspot.oops.InstanceKlass::getSize() > returns the incorrect size and has no test) > > The webrev is at: > > http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ > > > The modifications include the fix and 2 tests to check the > InstanceKlass sizes representing some well known classes and that of > an interface. The tests compare the sizes returned by SA to those > returned by jcmd. At this point, SA cannot view the InstanceKlasses > representing anonymous classes. (This issue will be addressed in > JDK-8160228 (SA > cannot view the LambdaMetaFactory generated anonymous > instanceKlasses)). Hence the current fix does not include the size > addition for InstanceKlasses representing anonymous classes. > > Thanks, > > - Jini Susan George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Jul 19 05:12:48 2016 From: jini.george at oracle.com (Jini George) Date: Mon, 18 Jul 2016 22:12:48 -0700 (PDT) Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <5788B1EF.1030303@oracle.com> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> Message-ID: <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> Thank you, Serguei, for the review. You are right, getBytesPerWord() makes more sense. Hence I modified the code to use getBytesPerWord(), though both those (getAddressSize() and getBytesPerWord()) seem to return the same value. I have retained the call to alignSize() since the header size is not multiplied by word size. I have addressed the comments related to the test cases. Here is a modified webrev: http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ Would you please take a relook ? Thank you, Jini. From: Serguei Spitsyn Sent: Friday, July 15, 2016 3:21 PM To: Jini George; serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi Jini, Some questions. Is the call of the method alignSize(size) necessary? It seems that the size is already aligned by the way it is calculated as the number of words is multiplied to wordLength. But I'm not exactly sure because the wordLength is returned by VM.getVM().getAddressSize() but the VM.getVM().getBytesPerWord() is used in the alignSize: public static long alignSize(long size) { // natural word size return VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); } So, the question is why did you use the getAddressSize() but not the getBytesPerWord()? Do they always return the same number? Just would like to understand your reasoning. :) Some nits: test/serviceability/sa/TestInstanceKlassSize.java 138 for (String s:output.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), ... 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { A space is needed after the ':' sign at L138, L166. Space is not needed after the 'contains' at L139, L141. test/serviceability/sa/TestInstanceKlassSizeForInterface.java 138 for (String s:SAOutput.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), A space is needed after the ':' sign at L138. Space is not needed after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, Jini George wrote: Hi, Gentle Reminder! Thanks, Jini. From: Jini George Sent: Tuesday, July 05, 2016 9:54 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi all, Please review the fix in Serviceability Agent (SA) for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) The webrev is at: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/sponsorship/8145627/webrev.00/"http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ The modifications include the fix and 2 tests to check the InstanceKlass sizes representing some well known classes and that of an interface. The tests compare the sizes returned by SA to those returned by jcmd. At this point, SA cannot view the InstanceKlasses representing anonymous classes. (This issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160228"JDK-8160228 (SA cannot view the LambdaMetaFactory generated anonymous instanceKlasses)). Hence the current fix does not include the size addition for InstanceKlasses representing anonymous classes. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Tue Jul 19 07:07:05 2016 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Tue, 19 Jul 2016 10:07:05 +0300 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: <5788AB52.40605@oracle.com> References: <5788AB52.40605@oracle.com> Message-ID: Hi Serguei, here's a new webrev with a test included: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ Egor On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: > Hi Egor, > > The fix looks good modulo the synchronization issue. > Do you have a jtreg unit test reproducing this failure mode? > We have a rule to provide a test coverage for the fixes. > > Thanks, > Serguei > > > On 7/15/16 00:03, Egor Ushakov wrote: >> >> Thanks for your comments! >> >> I totally agree that the code there requires major refactoring. In >> the fix I tried not to make it worse and fix the NPE. >> >> >> On 14.07.2016 20:06, Martin Buchholz wrote: >>> The lack of volatile or synchronization, plus the use of multiple >>> mutable fields, suggests that a deeper fix is necessary to be truly >>> correct. For comparison, much of the similar code implementing >>> reflection has been changed to use volatile. But that's a big job, >>> for the serviceability team. >>> >>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>> > wrote: >>> >>> Hi, >>> >>> I'm a developer from IDEA debugger (we have company OCA). >>> We've increased usage of ReferenceTypeImpl.constantPool and now >>> facing >>> JDK-6822627 more often. >>> Please review and sponsor the fix. >>> >>> The problem was that constantPoolBytesRef SoftReference value >>> coud be >>> GCed and there was no check for that. >>> I've added it to the check inside getConstantPoolInfo to request the >>> bytes again in this case. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6822627 >>> WEBREV: http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>> >>> >>> Thanks! >>> >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop >>> >>> >> >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Burlison at oracle.com Tue Jul 19 17:19:34 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Tue, 19 Jul 2016 18:19:34 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed Message-ID: <578E6126.9050600@oracle.com> This removes redundant/incorrect compilation flags from the Solaris build environment. https://bugs.openjdk.java.net/browse/JDK-8161057 http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ I already have one commend from DanD: > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > Copyright year updated to '2015' instead of '2016'. I've already fixed that in my workspace but it's still present in the above webrev. There were some JPRT test failures on OSX and Windows, as this changeset doesn't affect those platforms I believe they can be ignored. There is some related cleanup in deploy, that will be covered by https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the Solaris-related scripts. -- Alan Burlison -- From tim.bell at oracle.com Tue Jul 19 18:56:35 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 19 Jul 2016 11:56:35 -0700 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: <578E77E3.60300@oracle.com> Alan: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. > > There were some JPRT test failures on OSX and Windows, as this > changeset doesn't affect those platforms I believe they can be ignored. Looks good to me. Thanks for doing this. > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. That's good to know. Tim From daniel.daugherty at oracle.com Tue Jul 19 21:31:23 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jul 2016 15:31:23 -0600 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: <42699440-72ce-cc9e-7f55-a3d7cc26cf81@oracle.com> On 7/19/16 11:19 AM, Alan Burlison wrote: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh No comments. jdk/src/demo/share/jvmti/compiledMethodLoad/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/gctest/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/heapTracker/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/heapViewer/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt No additional comments. jdk/src/demo/share/jvmti/minst/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/mtrace/sample.makefile.txt No comments. jdk/src/demo/share/jvmti/versionCheck/sample.makefile.txt No comments. Thumbs up. Dan > > There were some JPRT test failures on OSX and Windows, as this > changeset doesn't affect those platforms I believe they can be ignored. > > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. > From david.holmes at oracle.com Wed Jul 20 02:17:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 12:17:21 +1000 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578E6126.9050600@oracle.com> References: <578E6126.9050600@oracle.com> Message-ID: Looks good Alan! Thanks for cleaning this up. One comment below ... On 20/07/2016 3:19 AM, Alan Burlison wrote: > This removes redundant/incorrect compilation flags from the Solaris > build environment. > > https://bugs.openjdk.java.net/browse/JDK-8161057 > http://cr.openjdk.java.net/~dcubed/for_alanbur/8161057-webrev/0-jdk9-hs-all/ > > > I already have one commend from DanD: > >> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt >> Copyright year updated to '2015' instead of '2016'. > > I've already fixed that in my workspace but it's still present in the > above webrev. > > There were some JPRT test failures on OSX and Windows, as this changeset > doesn't affect those platforms I believe they can be ignored. If this is with "-testset hotspot" then it shouldn't happen, in that case please drop me an email pointing to the job. For other testsets, yes they are transient/intermittent failures. > There is some related cleanup in deploy, that will be covered by > https://bugs.openjdk.java.net/browse/JDK-8161081, by removing the > Solaris-related scripts. Not an OpenJDK issue so we will handle that internally. Thanks, David From serguei.spitsyn at oracle.com Wed Jul 20 07:22:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 00:22:49 -0700 Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> Message-ID: <578F26C9.5040109@oracle.com> Jini, The fix looks good to me. Thank you for the update! Could you fix a couple of nits, please? test/serviceability/sa/TestInstanceKlassSize.java 156 agent.attach( (int) pid); Do not need to cast to int and the space before pid is not needed. The lines 114 -120 need standard indentation (4). (I'd suggest to move '{' to the line 114). Something similar to the lines 106-113. (it'd probably makes sense to align the '}' with the 'new') test/serviceability/sa/TestInstanceKlassSizeForInterface.java 70 agent.attach( (int) pid); The same as above. 162 if ( args == null || args.length == 0 ) { Unneeded spaces in condition. Lines 109-116 and 151-154 - the same comment as for prev. file above. I don't need to see another webrev. Thanks, Serguei On 7/18/16 22:12, Jini George wrote: > > Thank you, Serguei, for the review. > > You are right, getBytesPerWord() makes more sense. Hence I modified > the code to use getBytesPerWord(), though both those (getAddressSize() > and getBytesPerWord()) seem to return the same value. I have retained > the call to alignSize() since the header size is not multiplied by > word size. > > I have addressed the comments related to the test cases. Here is a > modified webrev: > > http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ > > > Would you please take a relook ? > > Thank you, > > Jini. > > *From:*Serguei Spitsyn > *Sent:* Friday, July 15, 2016 3:21 PM > *To:* Jini George; serviceability-dev at openjdk.java.net > *Subject:* Re: PING: RFR: JDK-8145627 > (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect > size and has no test) > > Hi Jini, > > Some questions. > > Is the call of the method alignSize(size) necessary? > It seems that the size is already aligned by the way it is calculated > as the number of words is multiplied to wordLength. > But I'm not exactly sure because the wordLength is returned by > VM.getVM().getAddressSize() > but the VM.getVM().getBytesPerWord() is used in the alignSize:* > > public static long *alignSize(*long *size) { > // natural word size/ > /*return *VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); > } > > So, the question is why did you use the getAddressSize() but not the > getBytesPerWord()? > Do they always return the same number? > Just would like to understand your reasoning. :) > > Some nits: > > test/serviceability/sa/TestInstanceKlassSize.java > > 138 for (String s:output.asLines()) { > 139 if (s.contains (instanceKlassName)) { > 140 Asserts.assertTrue( > 141 s.contains (jcmdInstanceKlassSize), > ... > 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { > > A space is needed after the ':' sign at L138, L166. Space is not > needed after the 'contains' at L139, L141. > test/serviceability/sa/TestInstanceKlassSizeForInterface.java > > 138 for (String s:SAOutput.asLines()) { > 139 if (s.contains (instanceKlassName)) { > 140 Asserts.assertTrue( > 141 s.contains (jcmdInstanceKlassSize), > > A space is needed after the ':' sign at L138. Space is not needed > after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, > Jini George wrote: > > Hi, > > Gentle Reminder! > > Thanks, > > Jini. > > *From:*Jini George *Sent:* Tuesday, July 05, 2016 9:54 PM *To:* > serviceability-dev at openjdk.java.net > *Subject:* RFR: > JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns > the incorrect size and has no test) > > Hi all, > > Please review the fix in Serviceability Agent (SA) for: > > JDK-8145627 > (sun.jvm.hotspot.oops.InstanceKlass::getSize() > returns the incorrect size and has no test) > > The webrev is at: > > http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ > > > > The modifications include the fix and 2 tests to check the > InstanceKlass sizes representing some well known classes and that > of an interface. The tests compare the sizes returned by SA to > those returned by jcmd. At this point, SA cannot view the > InstanceKlasses representing anonymous classes. (This issue will > be addressed in JDK-8160228 > (SA cannot view > the LambdaMetaFactory generated anonymous instanceKlasses)). Hence > the current fix does not include the size addition for > InstanceKlasses representing anonymous classes. > > Thanks, > > - Jini Susan George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jul 20 07:30:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2016 17:30:40 +1000 Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <578F26C9.5040109@oracle.com> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> <578F26C9.5040109@oracle.com> Message-ID: <87e52bc2-3d7d-a546-91e9-9496b5770a85@oracle.com> Just to clarify something ... On 20/07/2016 5:22 PM, serguei.spitsyn at oracle.com wrote: > Jini, > > The fix looks good to me. > Thank you for the update! > > > Could you fix a couple of nits, please? > > test/serviceability/sa/TestInstanceKlassSize.java > > > 156 agent.attach( (int) pid); > > > Do not need to cast to int and the space before pid is not needed. > > The lines 114 -120 need standard indentation (4). (I'd suggest to move > '{' to the line 114). > Something similar to the lines 106-113. (it'd probably makes sense to > align the '}' with the 'new') > > > test/serviceability/sa/TestInstanceKlassSizeForInterface.java > > > > 70 agent.attach( (int) pid); > > > The same as above. > > > 162 if ( args == null || args.length == 0 ) { > > > Unneeded spaces in condition. Those being the spaces after the (, and before the ). We use spaces around operators. Cheers, David ----- > Lines 109-116 and 151-154 - the same comment as for prev. file above. > > > I don't need to see another webrev. > > > Thanks, > Serguei > > > > > On 7/18/16 22:12, Jini George wrote: >> >> Thank you, Serguei, for the review. >> >> >> >> You are right, getBytesPerWord() makes more sense. Hence I modified >> the code to use getBytesPerWord(), though both those (getAddressSize() >> and getBytesPerWord()) seem to return the same value. I have retained >> the call to alignSize() since the header size is not multiplied by >> word size. >> >> >> >> I have addressed the comments related to the test cases. Here is a >> modified webrev: >> >> >> >> http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ >> >> >> >> Would you please take a relook ? >> >> >> >> Thank you, >> >> Jini. >> >> >> >> >> >> *From:*Serguei Spitsyn >> *Sent:* Friday, July 15, 2016 3:21 PM >> *To:* Jini George; serviceability-dev at openjdk.java.net >> *Subject:* Re: PING: RFR: JDK-8145627 >> (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect >> size and has no test) >> >> >> >> Hi Jini, >> >> Some questions. >> >> Is the call of the method alignSize(size) necessary? >> It seems that the size is already aligned by the way it is calculated >> as the number of words is multiplied to wordLength. >> But I'm not exactly sure because the wordLength is returned by >> VM.getVM().getAddressSize() >> but the VM.getVM().getBytesPerWord() is used in the alignSize:* >> >> public static long *alignSize(*long *size) { >> // natural word size/ >> /*return *VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); >> } >> >> So, the question is why did you use the getAddressSize() but not the >> getBytesPerWord()? >> Do they always return the same number? >> Just would like to understand your reasoning. :) >> >> Some nits: >> >> test/serviceability/sa/TestInstanceKlassSize.java >> >> 138 for (String s:output.asLines()) { >> 139 if (s.contains (instanceKlassName)) { >> 140 Asserts.assertTrue( >> 141 s.contains (jcmdInstanceKlassSize), >> ... >> 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { >> >> >> A space is needed after the ':' sign at L138, L166. Space is not >> needed after the 'contains' at L139, L141. >> test/serviceability/sa/TestInstanceKlassSizeForInterface.java >> >> 138 for (String s:SAOutput.asLines()) { >> 139 if (s.contains (instanceKlassName)) { >> 140 Asserts.assertTrue( >> 141 s.contains (jcmdInstanceKlassSize), >> >> A space is needed after the ':' sign at L138. Space is not needed >> after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, >> Jini George wrote: >> >> Hi, >> >> >> >> Gentle Reminder! >> >> >> >> Thanks, >> >> Jini. >> >> >> >> *From:*Jini George *Sent:* Tuesday, July 05, 2016 9:54 PM *To:* >> serviceability-dev at openjdk.java.net >> *Subject:* RFR: >> JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns >> the incorrect size and has no test) >> >> >> >> Hi all, >> >> >> >> Please review the fix in Serviceability Agent (SA) for: >> >> JDK-8145627 >> (sun.jvm.hotspot.oops.InstanceKlass::getSize() >> returns the incorrect size and has no test) >> >> >> >> The webrev is at: >> >> http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ >> >> >> >> >> The modifications include the fix and 2 tests to check the >> InstanceKlass sizes representing some well known classes and that >> of an interface. The tests compare the sizes returned by SA to >> those returned by jcmd. At this point, SA cannot view the >> InstanceKlasses representing anonymous classes. (This issue will >> be addressed in JDK-8160228 >> (SA cannot view >> the LambdaMetaFactory generated anonymous instanceKlasses)). Hence >> the current fix does not include the size addition for >> InstanceKlasses representing anonymous classes. >> >> >> >> Thanks, >> >> - Jini Susan George >> >> >> > From serguei.spitsyn at oracle.com Wed Jul 20 07:36:43 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 00:36:43 -0700 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: References: <5788AB52.40605@oracle.com> Message-ID: <578F2A0B.4070806@oracle.com> Hi Egor, Thank you for providing the test! A couple of nits to the test: 56 if (!Arrays.equals(cpbytes, cpbytes2)) { 57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2); 58 }; Last semicolon is not need. 74 if (!testFailed) { 75 println("ConstantPoolInfoGC: passed"); 76 } else { 77 throw new Exception("ConstantPoolInfoGC: failed"); 78 } I'd suggest to rearrange the statement above to something like this: 74 if (testFailed) { 75 throw new Exception("ConstantPoolInfoGC: failed"); 76 } 77 println("ConstantPoolInfoGC: passed"); But I leave it up to you. No need to see another webrev. I can sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, Egor Ushakov wrote: > > Hi Serguei, > > here's a new webrev with a test included: > http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ > > Egor > > On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: >> Hi Egor, The fix looks good modulo the synchronization issue. Do you >> have a jtreg unit test reproducing this failure mode? We have a rule >> to provide a test coverage for the fixes. Thanks, Serguei On 7/15/16 >> 00:03, Egor Ushakov wrote: >>> >>> Thanks for your comments! >>> >>> I totally agree that the code there requires major refactoring. In >>> the fix I tried not to make it worse and fix the NPE. >>> >>> On 14.07.2016 20:06, Martin Buchholz wrote: >>>> The lack of volatile or synchronization, plus the use of multiple >>>> mutable fields, suggests that a deeper fix is necessary to be truly >>>> correct. For comparison, much of the similar code implementing >>>> reflection has been changed to use volatile. But that's a big job, >>>> for the serviceability team. >>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>>> > >>>> wrote: >>>> >>>> Hi, I'm a developer from IDEA debugger (we have company OCA). >>>> We've increased usage of ReferenceTypeImpl.constantPool and now >>>> facing JDK-6822627 more often. Please review and sponsor the >>>> fix. The problem was that constantPoolBytesRef SoftReference >>>> value coud be GCed and there was no check for that. I've added >>>> it to the check inside getConstantPoolInfo to request the bytes >>>> again in this case. BUGURL: >>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: >>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>>> >>>> Thanks!-- Egor Ushakov Software Developer JetBrains >>>> http://www.jetbrains.com The Drive to Develop >>>> >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jul 20 07:41:02 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 00:41:02 -0700 Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <87e52bc2-3d7d-a546-91e9-9496b5770a85@oracle.com> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> <578F26C9.5040109@oracle.com> <87e52bc2-3d7d-a546-91e9-9496b5770a85@oracle.com> Message-ID: <578F2B0E.1050805@oracle.com> On 7/20/16 00:30, David Holmes wrote: > Just to clarify something ... > > On 20/07/2016 5:22 PM, serguei.spitsyn at oracle.com wrote: >> Jini, >> >> The fix looks good to me. >> Thank you for the update! >> >> >> Could you fix a couple of nits, please? >> >> test/serviceability/sa/TestInstanceKlassSize.java >> >> >> 156 agent.attach( (int) pid); >> >> >> Do not need to cast to int and the space before pid is not needed. >> >> The lines 114 -120 need standard indentation (4). (I'd suggest to move >> '{' to the line 114). >> Something similar to the lines 106-113. (it'd probably makes sense to >> align the '}' with the 'new') >> >> >> test/serviceability/sa/TestInstanceKlassSizeForInterface.java >> >> >> >> 70 agent.attach( (int) pid); >> >> >> The same as above. >> >> >> 162 if ( args == null || args.length == 0 ) { >> >> >> Unneeded spaces in condition. > > Those being the spaces after the (, and before the ). We use spaces > around operators. Right. I thought, it is clear. :) Thank you for clarifying. Thanks, Serguei > > Cheers, > David > ----- > >> Lines 109-116 and 151-154 - the same comment as for prev. file above. >> >> >> I don't need to see another webrev. >> >> >> Thanks, >> Serguei >> >> >> >> >> On 7/18/16 22:12, Jini George wrote: >>> >>> Thank you, Serguei, for the review. >>> >>> >>> >>> You are right, getBytesPerWord() makes more sense. Hence I modified >>> the code to use getBytesPerWord(), though both those (getAddressSize() >>> and getBytesPerWord()) seem to return the same value. I have retained >>> the call to alignSize() since the header size is not multiplied by >>> word size. >>> >>> >>> >>> I have addressed the comments related to the test cases. Here is a >>> modified webrev: >>> >>> >>> >>> http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ >>> >>> >>> >>> >>> Would you please take a relook ? >>> >>> >>> >>> Thank you, >>> >>> Jini. >>> >>> >>> >>> >>> >>> *From:*Serguei Spitsyn >>> *Sent:* Friday, July 15, 2016 3:21 PM >>> *To:* Jini George; serviceability-dev at openjdk.java.net >>> *Subject:* Re: PING: RFR: JDK-8145627 >>> (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect >>> size and has no test) >>> >>> >>> >>> Hi Jini, >>> >>> Some questions. >>> >>> Is the call of the method alignSize(size) necessary? >>> It seems that the size is already aligned by the way it is calculated >>> as the number of words is multiplied to wordLength. >>> But I'm not exactly sure because the wordLength is returned by >>> VM.getVM().getAddressSize() >>> but the VM.getVM().getBytesPerWord() is used in the alignSize:* >>> >>> public static long *alignSize(*long *size) { >>> // natural word size/ >>> /*return *VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); >>> } >>> >>> So, the question is why did you use the getAddressSize() but not the >>> getBytesPerWord()? >>> Do they always return the same number? >>> Just would like to understand your reasoning. :) >>> >>> Some nits: >>> >>> test/serviceability/sa/TestInstanceKlassSize.java >>> >>> 138 for (String s:output.asLines()) { >>> 139 if (s.contains (instanceKlassName)) { >>> 140 Asserts.assertTrue( >>> 141 s.contains (jcmdInstanceKlassSize), >>> ... >>> 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { >>> >>> >>> A space is needed after the ':' sign at L138, L166. Space is not >>> needed after the 'contains' at L139, L141. >>> test/serviceability/sa/TestInstanceKlassSizeForInterface.java >>> >>> 138 for (String s:SAOutput.asLines()) { >>> 139 if (s.contains (instanceKlassName)) { >>> 140 Asserts.assertTrue( >>> 141 s.contains (jcmdInstanceKlassSize), >>> >>> A space is needed after the ':' sign at L138. Space is not needed >>> after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, >>> Jini George wrote: >>> >>> Hi, >>> >>> >>> >>> Gentle Reminder! >>> >>> >>> >>> Thanks, >>> >>> Jini. >>> >>> >>> >>> *From:*Jini George *Sent:* Tuesday, July 05, 2016 9:54 PM *To:* >>> serviceability-dev at openjdk.java.net >>> *Subject:* RFR: >>> JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns >>> the incorrect size and has no test) >>> >>> >>> >>> Hi all, >>> >>> >>> >>> Please review the fix in Serviceability Agent (SA) for: >>> >>> JDK-8145627 >>> (sun.jvm.hotspot.oops.InstanceKlass::getSize() >>> returns the incorrect size and has no test) >>> >>> >>> >>> The webrev is at: >>> >>> http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ >>> >>> >>> >>> >>> The modifications include the fix and 2 tests to check the >>> InstanceKlass sizes representing some well known classes and that >>> of an interface. The tests compare the sizes returned by SA to >>> those returned by jcmd. At this point, SA cannot view the >>> InstanceKlasses representing anonymous classes. (This issue will >>> be addressed in JDK-8160228 >>> (SA cannot view >>> the LambdaMetaFactory generated anonymous instanceKlasses)). Hence >>> the current fix does not include the size addition for >>> InstanceKlasses representing anonymous classes. >>> >>> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> >> From egor.ushakov at jetbrains.com Wed Jul 20 09:10:04 2016 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 20 Jul 2016 12:10:04 +0300 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: <578F2A0B.4070806@oracle.com> References: <5788AB52.40605@oracle.com> <578F2A0B.4070806@oracle.com> Message-ID: <04eb5e4d-eccb-d168-4701-6e8badcbd43a@jetbrains.com> Serguei, thanks for the review! Please sponsor the fix, I do not know how to proceed. Thanks! Egor On 20.07.2016 10:36, serguei.spitsyn at oracle.com wrote: > Hi Egor, > > Thank you for providing the test! > > A couple of nits to the test: > > 56 if (!Arrays.equals(cpbytes, cpbytes2)) { > 57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2); > 58 }; > Last semicolon is not need. > 74 if (!testFailed) { > 75 println("ConstantPoolInfoGC: passed"); > 76 } else { > 77 throw new Exception("ConstantPoolInfoGC: failed"); > 78 } > I'd suggest to rearrange the statement above to something like this: > 74 if (testFailed) { > 75 throw new Exception("ConstantPoolInfoGC: failed"); > 76 } > 77 println("ConstantPoolInfoGC: passed"); > > But I leave it up to you. No need to see another webrev. I > can sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, > Egor Ushakov wrote: >> >> Hi Serguei, >> >> here's a new webrev with a test included: >> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ >> >> Egor >> >> On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: >>> Hi Egor, The fix looks good modulo the synchronization issue. Do you >>> have a jtreg unit test reproducing this failure mode? We have a rule >>> to provide a test coverage for the fixes. Thanks, Serguei On 7/15/16 >>> 00:03, Egor Ushakov wrote: >>>> >>>> Thanks for your comments! >>>> >>>> I totally agree that the code there requires major refactoring. In >>>> the fix I tried not to make it worse and fix the NPE. >>>> >>>> On 14.07.2016 20:06, Martin Buchholz wrote: >>>>> The lack of volatile or synchronization, plus the use of multiple >>>>> mutable fields, suggests that a deeper fix is necessary to be >>>>> truly correct. For comparison, much of the similar code >>>>> implementing reflection has been changed to use volatile. But >>>>> that's a big job, for the serviceability team. >>>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>>>> > >>>>> wrote: >>>>> >>>>> Hi, I'm a developer from IDEA debugger (we have company OCA). >>>>> We've increased usage of ReferenceTypeImpl.constantPool and >>>>> now facing JDK-6822627 more often. Please review and sponsor >>>>> the fix. The problem was that constantPoolBytesRef >>>>> SoftReference value coud be GCed and there was no check for >>>>> that. I've added it to the check inside getConstantPoolInfo to >>>>> request the bytes again in this case. BUGURL: >>>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: >>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>>>> >>>>> Thanks!-- Egor Ushakov Software Developer JetBrains >>>>> http://www.jetbrains.com The Drive to Develop >>>>> >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jul 20 09:34:19 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 02:34:19 -0700 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: <04eb5e4d-eccb-d168-4701-6e8badcbd43a@jetbrains.com> References: <5788AB52.40605@oracle.com> <578F2A0B.4070806@oracle.com> <04eb5e4d-eccb-d168-4701-6e8badcbd43a@jetbrains.com> Message-ID: <578F459B.8070008@oracle.com> Egor, If I understand correctly, you do not have an openJdk user ID and an author status. Please, see the link: http://openjdk.java.net/census So that, I'll commit your fix with the comment: Contributed-by: egor.ushakov at jetbrains.com and push it to the jdk9/hs. I hope, somebody will correct me if it is not right. Please, let me know if it works for you. Thanks, Serguei On 7/20/16 02:10, Egor Ushakov wrote: > > Serguei, thanks for the review! > > Please sponsor the fix, I do not know how to proceed. > > Thanks! > > Egor > > > On 20.07.2016 10:36, serguei.spitsyn at oracle.com wrote: >> Hi Egor, >> >> Thank you for providing the test! >> >> A couple of nits to the test: >> >> 56 if (!Arrays.equals(cpbytes, cpbytes2)) { >> 57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2); >> 58 }; >> Last semicolon is not need. >> 74 if (!testFailed) { >> 75 println("ConstantPoolInfoGC: passed"); >> 76 } else { >> 77 throw new Exception("ConstantPoolInfoGC: failed"); >> 78 } >> I'd suggest to rearrange the statement above to something like this: >> 74 if (testFailed) { >> 75 throw new Exception("ConstantPoolInfoGC: failed"); >> 76 } >> 77 println("ConstantPoolInfoGC: passed"); >> >> But I leave it up to you. No need to see another webrev. I >> can sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, >> Egor Ushakov wrote: >>> >>> Hi Serguei, >>> >>> here's a new webrev with a test included: >>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ >>> >>> Egor >>> >>> On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: >>>> Hi Egor, The fix looks good modulo the synchronization issue. Do >>>> you have a jtreg unit test reproducing this failure mode? We have a >>>> rule to provide a test coverage for the fixes. Thanks, Serguei On >>>> 7/15/16 00:03, Egor Ushakov wrote: >>>>> >>>>> Thanks for your comments! >>>>> >>>>> I totally agree that the code there requires major refactoring. In >>>>> the fix I tried not to make it worse and fix the NPE. >>>>> >>>>> On 14.07.2016 20:06, Martin Buchholz wrote: >>>>>> The lack of volatile or synchronization, plus the use of multiple >>>>>> mutable fields, suggests that a deeper fix is necessary to be >>>>>> truly correct. For comparison, much of the similar code >>>>>> implementing reflection has been changed to use volatile. But >>>>>> that's a big job, for the serviceability team. >>>>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, I'm a developer from IDEA debugger (we have company OCA). >>>>>> We've increased usage of ReferenceTypeImpl.constantPool and >>>>>> now facing JDK-6822627 more often. Please review and sponsor >>>>>> the fix. The problem was that constantPoolBytesRef >>>>>> SoftReference value coud be GCed and there was no check for >>>>>> that. I've added it to the check inside getConstantPoolInfo >>>>>> to request the bytes again in this case. BUGURL: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: >>>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>>>>> >>>>>> Thanks!-- Egor Ushakov Software Developer JetBrains >>>>>> http://www.jetbrains.com The Drive to Develop >>>>>> >>>>> -- >>>>> Egor Ushakov >>>>> Software Developer >>>>> JetBrains >>>>> http://www.jetbrains.com >>>>> The Drive to Develop >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Wed Jul 20 09:53:45 2016 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 20 Jul 2016 12:53:45 +0300 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: <578F459B.8070008@oracle.com> References: <5788AB52.40605@oracle.com> <578F2A0B.4070806@oracle.com> <04eb5e4d-eccb-d168-4701-6e8badcbd43a@jetbrains.com> <578F459B.8070008@oracle.com> Message-ID: <342df83e-e7fe-4f8b-eaa6-6aa1427f6b45@jetbrains.com> Yes, all correct, thanks! On 20.07.2016 12:34, serguei.spitsyn at oracle.com wrote: > Egor, > > If I understand correctly, you do not have an openJdk user ID and an > author status. > Please, see the link: > http://openjdk.java.net/census > > So that, I'll commit your fix with the comment: > Contributed-by: egor.ushakov at jetbrains.com > > and push it to the jdk9/hs. > > I hope, somebody will correct me if it is not right. > Please, let me know if it works for you. > > Thanks, > Serguei > > > On 7/20/16 02:10, Egor Ushakov wrote: >> >> Serguei, thanks for the review! >> >> Please sponsor the fix, I do not know how to proceed. >> >> Thanks! >> >> Egor >> >> >> On 20.07.2016 10:36, serguei.spitsyn at oracle.com wrote: >>> Hi Egor, >>> >>> Thank you for providing the test! >>> >>> A couple of nits to the test: >>> >>> 56 if (!Arrays.equals(cpbytes, cpbytes2)) { >>> 57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2); >>> 58 }; >>> Last semicolon is not need. >>> 74 if (!testFailed) { >>> 75 println("ConstantPoolInfoGC: passed"); >>> 76 } else { >>> 77 throw new Exception("ConstantPoolInfoGC: failed"); >>> 78 } >>> I'd suggest to rearrange the statement above to something like this: >>> 74 if (testFailed) { >>> 75 throw new Exception("ConstantPoolInfoGC: failed"); >>> 76 } >>> 77 println("ConstantPoolInfoGC: passed"); >>> >>> But I leave it up to you. No need to see another webrev. I >>> can sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, >>> Egor Ushakov wrote: >>>> >>>> Hi Serguei, >>>> >>>> here's a new webrev with a test included: >>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ >>>> >>>> Egor >>>> >>>> On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: >>>>> Hi Egor, The fix looks good modulo the synchronization issue. Do >>>>> you have a jtreg unit test reproducing this failure mode? We have >>>>> a rule to provide a test coverage for the fixes. Thanks, Serguei >>>>> On 7/15/16 00:03, Egor Ushakov wrote: >>>>>> >>>>>> Thanks for your comments! >>>>>> >>>>>> I totally agree that the code there requires major refactoring. >>>>>> In the fix I tried not to make it worse and fix the NPE. >>>>>> >>>>>> On 14.07.2016 20:06, Martin Buchholz wrote: >>>>>>> The lack of volatile or synchronization, plus the use of >>>>>>> multiple mutable fields, suggests that a deeper fix is necessary >>>>>>> to be truly correct. For comparison, much of the similar code >>>>>>> implementing reflection has been changed to use volatile. But >>>>>>> that's a big job, for the serviceability team. >>>>>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, I'm a developer from IDEA debugger (we have company >>>>>>> OCA). We've increased usage of >>>>>>> ReferenceTypeImpl.constantPool and now facing JDK-6822627 >>>>>>> more often. Please review and sponsor the fix. The problem >>>>>>> was that constantPoolBytesRef SoftReference value coud be >>>>>>> GCed and there was no check for that. I've added it to the >>>>>>> check inside getConstantPoolInfo to request the bytes again >>>>>>> in this case. BUGURL: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: >>>>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>>>>>> >>>>>>> Thanks!-- Egor Ushakov Software Developer JetBrains >>>>>>> http://www.jetbrains.com The Drive to Develop >>>>>>> >>>>>> -- >>>>>> Egor Ushakov >>>>>> Software Developer >>>>>> JetBrains >>>>>> http://www.jetbrains.com >>>>>> The Drive to Develop >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jul 20 09:56:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 02:56:10 -0700 Subject: [PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool In-Reply-To: <342df83e-e7fe-4f8b-eaa6-6aa1427f6b45@jetbrains.com> References: <5788AB52.40605@oracle.com> <578F2A0B.4070806@oracle.com> <04eb5e4d-eccb-d168-4701-6e8badcbd43a@jetbrains.com> <578F459B.8070008@oracle.com> <342df83e-e7fe-4f8b-eaa6-6aa1427f6b45@jetbrains.com> Message-ID: <578F4ABA.6010606@oracle.com> On 7/20/16 02:53, Egor Ushakov wrote: > > Yes, all correct, thanks! > Ok, thanks. Serguei > > On 20.07.2016 12:34, serguei.spitsyn at oracle.com wrote: >> Egor, >> >> If I understand correctly, you do not have an openJdk user ID and an >> author status. >> Please, see the link: >> http://openjdk.java.net/census >> >> So that, I'll commit your fix with the comment: >> Contributed-by: egor.ushakov at jetbrains.com >> >> and push it to the jdk9/hs. >> >> I hope, somebody will correct me if it is not right. >> Please, let me know if it works for you. >> >> Thanks, >> Serguei >> >> >> On 7/20/16 02:10, Egor Ushakov wrote: >>> >>> Serguei, thanks for the review! >>> >>> Please sponsor the fix, I do not know how to proceed. >>> >>> Thanks! >>> >>> Egor >>> >>> >>> On 20.07.2016 10:36, serguei.spitsyn at oracle.com wrote: >>>> Hi Egor, >>>> >>>> Thank you for providing the test! >>>> >>>> A couple of nits to the test: >>>> >>>> 56 if (!Arrays.equals(cpbytes, cpbytes2)) { >>>> 57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2); >>>> 58 }; >>>> Last semicolon is not need. >>>> 74 if (!testFailed) { >>>> 75 println("ConstantPoolInfoGC: passed"); >>>> 76 } else { >>>> 77 throw new Exception("ConstantPoolInfoGC: failed"); >>>> 78 } >>>> I'd suggest to rearrange the statement above to something like this: >>>> 74 if (testFailed) { >>>> 75 throw new Exception("ConstantPoolInfoGC: failed"); >>>> 76 } >>>> 77 println("ConstantPoolInfoGC: passed"); >>>> >>>> But I leave it up to you. No need to see another webrev. I >>>> can sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, >>>> Egor Ushakov wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> here's a new webrev with a test included: >>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/ >>>>> >>>>> Egor >>>>> >>>>> On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Egor, The fix looks good modulo the synchronization issue. Do >>>>>> you have a jtreg unit test reproducing this failure mode? We have >>>>>> a rule to provide a test coverage for the fixes. Thanks, Serguei >>>>>> On 7/15/16 00:03, Egor Ushakov wrote: >>>>>>> >>>>>>> Thanks for your comments! >>>>>>> >>>>>>> I totally agree that the code there requires major refactoring. >>>>>>> In the fix I tried not to make it worse and fix the NPE. >>>>>>> >>>>>>> On 14.07.2016 20:06, Martin Buchholz wrote: >>>>>>>> The lack of volatile or synchronization, plus the use of >>>>>>>> multiple mutable fields, suggests that a deeper fix is >>>>>>>> necessary to be truly correct. For comparison, much of the >>>>>>>> similar code implementing reflection has been changed to use >>>>>>>> volatile. But that's a big job, for the serviceability team. >>>>>>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, I'm a developer from IDEA debugger (we have company >>>>>>>> OCA). We've increased usage of >>>>>>>> ReferenceTypeImpl.constantPool and now facing JDK-6822627 >>>>>>>> more often. Please review and sponsor the fix. The problem >>>>>>>> was that constantPoolBytesRef SoftReference value coud be >>>>>>>> GCed and there was no check for that. I've added it to the >>>>>>>> check inside getConstantPoolInfo to request the bytes again >>>>>>>> in this case. BUGURL: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV: >>>>>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/ >>>>>>>> >>>>>>>> Thanks!-- Egor Ushakov Software Developer JetBrains >>>>>>>> http://www.jetbrains.com The Drive to Develop >>>>>>>> >>>>>>> -- >>>>>>> Egor Ushakov >>>>>>> Software Developer >>>>>>> JetBrains >>>>>>> http://www.jetbrains.com >>>>>>> The Drive to Develop >>>>> -- >>>>> Egor Ushakov >>>>> Software Developer >>>>> JetBrains >>>>> http://www.jetbrains.com >>>>> The Drive to Develop >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Burlison at oracle.com Wed Jul 20 16:05:14 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 20 Jul 2016 17:05:14 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: References: <578E6126.9050600@oracle.com> Message-ID: <578FA13A.5010505@oracle.com> On 20/07/2016 03:17, David Holmes wrote: >> There were some JPRT test failures on OSX and Windows, as this changeset >> doesn't affect those platforms I believe they can be ignored. > > If this is with "-testset hotspot" then it shouldn't happen, in that > case please drop me an email pointing to the job. For other testsets, > yes they are transient/intermittent failures. The "-testset hostpot" run was clean, it was "-testset core" that failed, with errors in the same areas that I've seen in other unrelated runs. -- Alan Burlison -- From daniel.daugherty at oracle.com Wed Jul 20 17:11:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2016 11:11:00 -0600 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <578FA13A.5010505@oracle.com> References: <578E6126.9050600@oracle.com> <578FA13A.5010505@oracle.com> Message-ID: <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> We have three reviewers on this changeset. We don't have a review from a current Serviceability team member, but I think Tim and I can be considered as sufficient review since we're both former Serviceability team members. :-) Alan, please confirm that this is good to go. This change is applied in the repo I have setup for this change: > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > Copyright year updated to '2015' instead of '2016'. Dan On 7/20/16 10:05 AM, Alan Burlison wrote: > On 20/07/2016 03:17, David Holmes wrote: > >>> There were some JPRT test failures on OSX and Windows, as this >>> changeset >>> doesn't affect those platforms I believe they can be ignored. >> >> If this is with "-testset hotspot" then it shouldn't happen, in that >> case please drop me an email pointing to the job. For other testsets, >> yes they are transient/intermittent failures. > > The "-testset hostpot" run was clean, it was "-testset core" that > failed, with errors in the same areas that I've seen in other > unrelated runs. > From christian.tornqvist at oracle.com Wed Jul 20 17:10:48 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 20 Jul 2016 13:10:48 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <5727CF48.7020007@oracle.com> References: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> <5727CF48.7020007@oracle.com> Message-ID: <30d801d1e2a9$a944bde0$fbce39a0$@oracle.com> Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin ; Serviceability-Dev 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 Alan.Burlison at oracle.com Wed Jul 20 17:38:37 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 20 Jul 2016 18:38:37 +0100 Subject: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed In-Reply-To: <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> References: <578E6126.9050600@oracle.com> <578FA13A.5010505@oracle.com> <08799ca8-166f-bebe-9b57-32d6306e1f93@oracle.com> Message-ID: <578FB71D.9030406@oracle.com> On 20/07/2016 18:11, Daniel D. Daugherty wrote: > We have three reviewers on this changeset. We don't have a review > from a current Serviceability team member, but I think Tim and I > can be considered as sufficient review since we're both former > Serviceability team members. :-) > > Alan, please confirm that this is good to go. > > This change is applied in the repo I have setup for this change: > > > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt > > Copyright year updated to '2015' instead of '2016'. Yes, it is good to go, as a belt-and-braces I've sent you a patch with the change above included. Thanks, -- Alan Burlison -- From serguei.spitsyn at oracle.com Wed Jul 20 21:57:15 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Jul 2016 14:57:15 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <30d801d1e2a9$a944bde0$fbce39a0$@oracle.com> References: <16ccbaaf-d909-4a1a-af87-5f456746fe20@default> <5727CF48.7020007@oracle.com> <30d801d1e2a9$a944bde0$fbce39a0$@oracle.com> Message-ID: <578FF3BB.9090304@oracle.com> Christian, Thank you for the comments. I agree, this test is over complicated. Your suggestions for simplifications are good. Alexander, Could you, please, update the webrev according to the Christian's comments? I will re-review it then. Can you do it tomorrow? Otherwise, I'm going to vacation starting from the next week. Thanks, Serguei On 7/20/16 10:10, Christian Tornqvist wrote: > > Hi Alexander, > > This test is unnecessarily complicated, it could be simplified a lot. > > JvmtiGetAllModulesTest.java > > Move getModulesNative() into JvmtiGetAllModulesTest.java and have it > return a Set to be able to use equals later > > @27 * @compile JvmtiGetAllModulesTest.java > > No need for this, jtreg will compile it for you > > @45 & @67 > > Why is this check needed? Why are there least 3 unnamed modules? > > @50 > > Change this to: assertTrue(Layer.boot().equals(getModulesNative())); > > @54 > > This should be doable without using JAR's and custom loaders by using > Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > > @65 > > Change this to an assertTrue using the layer containing the new > module, similar to the change @50 > > @73 > > No need for this method > > @81 > > Change this method to use the Layer.defineModules() method to define a > module instead, this eliminates the need for external JAR's > > @98 > > No need for this method > > If you use Layer.defineModules(), the following files can be removed: > > JarBuilder.java > > JavaModulesInfo.java > > JvmtiModulesInfo.java > > ModuleLoader.java > > ModulesInfo.java > > module-info.java > > Thanks, > > Christian > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of > *serguei.spitsyn at oracle.com > *Sent:* Monday, May 2, 2016 6:06 PM > *To:* Alexander Kulyakhtin ; > Serviceability-Dev > *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 jini.george at oracle.com Thu Jul 21 02:43:32 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 20 Jul 2016 19:43:32 -0700 (PDT) Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <578F26C9.5040109@oracle.com> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> <578F26C9.5040109@oracle.com> Message-ID: Thank you, Serguei. I will be fixing these nits. Regards, -Jini From: Serguei Spitsyn Sent: Wednesday, July 20, 2016 12:53 PM To: Jini George; serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Jini, The fix looks good to me. Thank you for the update! Could you fix a couple of nits, please? test/serviceability/sa/TestInstanceKlassSize.java 156 agent.attach( (int) pid); Do not need to cast to int and the space before pid is not needed. The lines 114 -120 need standard indentation (4). (I'd suggest to move '{' to the line 114). Something similar to the lines 106-113. (it'd probably makes sense to align the '}' with the 'new') test/serviceability/sa/TestInstanceKlassSizeForInterface.java 70 agent.attach( (int) pid); The same as above. 162 if ( args == null || args.length == 0 ) { Unneeded spaces in condition. Lines 109-116 and 151-154 - the same comment as for prev. file above. I don't need to see another webrev. Thanks, Serguei On 7/18/16 22:12, Jini George wrote: Thank you, Serguei, for the review. You are right, getBytesPerWord() makes more sense. Hence I modified the code to use getBytesPerWord(), though both those (getAddressSize() and getBytesPerWord()) seem to return the same value. I have retained the call to alignSize() since the header size is not multiplied by word size. I have addressed the comments related to the test cases. Here is a modified webrev: http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ Would you please take a relook ? Thank you, Jini. From: Serguei Spitsyn Sent: Friday, July 15, 2016 3:21 PM To: Jini George; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi Jini, Some questions. Is the call of the method alignSize(size) necessary? It seems that the size is already aligned by the way it is calculated as the number of words is multiplied to wordLength. But I'm not exactly sure because the wordLength is returned by VM.getVM().getAddressSize() but the VM.getVM().getBytesPerWord() is used in the alignSize: public static long alignSize(long size) { // natural word size return VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); } So, the question is why did you use the getAddressSize() but not the getBytesPerWord()? Do they always return the same number? Just would like to understand your reasoning. :) Some nits: test/serviceability/sa/TestInstanceKlassSize.java 138 for (String s:output.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), ... 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { A space is needed after the ':' sign at L138, L166. Space is not needed after the 'contains' at L139, L141. test/serviceability/sa/TestInstanceKlassSizeForInterface.java 138 for (String s:SAOutput.asLines()) { 139 if (s.contains (instanceKlassName)) { 140 Asserts.assertTrue( 141 s.contains (jcmdInstanceKlassSize), A space is needed after the ':' sign at L138. Space is not needed after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 19:07, Jini George wrote: Hi, Gentle Reminder! Thanks, Jini. From: Jini George Sent: Tuesday, July 05, 2016 9:54 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) Hi all, Please review the fix in Serviceability Agent (SA) for: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8145627"JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) The webrev is at: http://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ The modifications include the fix and 2 tests to check the InstanceKlass sizes representing some well known classes and that of an interface. The tests compare the sizes returned by SA to those returned by jcmd. At this point, SA cannot view the InstanceKlasses representing anonymous classes. (This issue will be addressed in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8160228"JDK-8160228 (SA cannot view the LambdaMetaFactory generated anonymous instanceKlasses)). Hence the current fix does not include the size addition for InstanceKlasses representing anonymous classes. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Thu Jul 21 02:43:55 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 20 Jul 2016 19:43:55 -0700 (PDT) Subject: PING: RFR: JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test) In-Reply-To: <87e52bc2-3d7d-a546-91e9-9496b5770a85@oracle.com> References: <46c08ec5-8071-48ff-981d-0f6cb187e65d@default> <1fb87a0d-0833-429f-b8b1-b96d633fc268@default> <5788B1EF.1030303@oracle.com> <63ef596b-cc47-4fdc-9bcd-2bfb78015709@default> <578F26C9.5040109@oracle.com> <87e52bc2-3d7d-a546-91e9-9496b5770a85@oracle.com> Message-ID: <43281f4f-5710-4137-af16-e850f8f4e836@default> Thank you, David. Regards, Jini. > -----Original Message----- > From: David Holmes > Sent: Wednesday, July 20, 2016 1:01 PM > To: Serguei Spitsyn; Jini George; serviceability-dev at openjdk.java.net > Subject: Re: PING: RFR: JDK-8145627 > (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect > size and has no test) > > Just to clarify something ... > > On 20/07/2016 5:22 PM, serguei.spitsyn at oracle.com wrote: > > Jini, > > > > The fix looks good to me. > > Thank you for the update! > > > > > > Could you fix a couple of nits, please? > > > > test/serviceability/sa/TestInstanceKlassSize.java > > > > > > 156 agent.attach( (int) pid); > > > > > > Do not need to cast to int and the space before pid is not needed. > > > > The lines 114 -120 need standard indentation (4). (I'd suggest to > move > > '{' to the line 114). > > Something similar to the lines 106-113. (it'd probably makes sense > to > > align the '}' with the 'new') > > > > > > test/serviceability/sa/TestInstanceKlassSizeForInterface.java > > > > > > > > 70 agent.attach( (int) pid); > > > > > > The same as above. > > > > > > 162 if ( args == null || args.length == 0 ) { > > > > > > Unneeded spaces in condition. > > Those being the spaces after the (, and before the ). We use spaces > around operators. > > Cheers, > David > ----- > > > Lines 109-116 and 151-154 - the same comment as for prev. file > above. > > > > > > I don't need to see another webrev. > > > > > > Thanks, > > Serguei > > > > > > > > > > On 7/18/16 22:12, Jini George wrote: > >> > >> Thank you, Serguei, for the review. > >> > >> > >> > >> You are right, getBytesPerWord() makes more sense. Hence I modified > >> the code to use getBytesPerWord(), though both those > (getAddressSize() > >> and getBytesPerWord()) seem to return the same value. I have > retained > >> the call to alignSize() since the header size is not multiplied by > >> word size. > >> > >> > >> > >> I have addressed the comments related to the test cases. Here is a > >> modified webrev: > >> > >> > >> > >> > h > ttp://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.01/ > >> > >> > >> > >> Would you please take a relook ? > >> > >> > >> > >> Thank you, > >> > >> Jini. > >> > >> > >> > >> > >> > >> *From:*Serguei Spitsyn > >> *Sent:* Friday, July 15, 2016 3:21 PM > >> *To:* Jini George; serviceability-dev at openjdk.java.net > >> *Subject:* Re: PING: RFR: JDK-8145627 > >> (sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect > >> size and has no test) > >> > >> > >> > >> Hi Jini, > >> > >> Some questions. > >> > >> Is the call of the method alignSize(size) necessary? > >> It seems that the size is already aligned by the way it is > calculated > >> as the number of words is multiplied to wordLength. > >> But I'm not exactly sure because the wordLength is returned by > >> VM.getVM().getAddressSize() > >> but the VM.getVM().getBytesPerWord() is used in the alignSize:* > >> > >> public static long *alignSize(*long *size) { > >> // natural word size/ > >> /*return *VM.getVM().alignUp(size, VM.getVM().getBytesPerWord()); > >> } > >> > >> So, the question is why did you use the getAddressSize() but not the > >> getBytesPerWord()? > >> Do they always return the same number? > >> Just would like to understand your reasoning. :) > >> > >> Some nits: > >> > >> test/serviceability/sa/TestInstanceKlassSize.java > >> > >> 138 for (String s:output.asLines()) { > >> 139 if (s.contains (instanceKlassName)) { > >> 140 Asserts.assertTrue( > >> 141 s.contains (jcmdInstanceKlassSize), > >> ... > >> 166 for (String SAInstanceKlassName:SAInstanceKlassNames) { > >> > >> > >> A space is needed after the ':' sign at L138, L166. Space is not > >> needed after the 'contains' at L139, L141. > >> test/serviceability/sa/TestInstanceKlassSizeForInterface.java > >> > >> 138 for (String s:SAOutput.asLines()) { > >> 139 if (s.contains (instanceKlassName)) { > >> 140 Asserts.assertTrue( > >> 141 s.contains (jcmdInstanceKlassSize), > >> > >> A space is needed after the ':' sign at L138. Space is not needed > >> after the 'contains' at L139, L141. Thanks, Serguei On 7/10/16 > 19:07, > >> Jini George wrote: > >> > >> Hi, > >> > >> > >> > >> Gentle Reminder! > >> > >> > >> > >> Thanks, > >> > >> Jini. > >> > >> > >> > >> *From:*Jini George *Sent:* Tuesday, July 05, 2016 9:54 PM *To:* > >> serviceability-dev at openjdk.java.net > >> *Subject:* RFR: > >> JDK-8145627 (sun.jvm.hotspot.oops.InstanceKlass::getSize() > returns > >> the incorrect size and has no test) > >> > >> > >> > >> Hi all, > >> > >> > >> > >> Please review the fix in Serviceability Agent (SA) for: > >> > >> JDK-8145627 > >> 8145627>(sun.jvm.hotspot.oops.InstanceKlass::getSize() > >> returns the incorrect size and has no test) > >> > >> > >> > >> The webrev is at: > >> > >> > h > ttp://cr.openjdk.java.net/~sballal/sponsorship/8145627/webrev.00/ > >> > >> > >> > >> > >> The modifications include the fix and 2 tests to check the > >> InstanceKlass sizes representing some well known classes and > that > >> of an interface. The tests compare the sizes returned by SA to > >> those returned by jcmd. At this point, SA cannot view the > >> InstanceKlasses representing anonymous classes. (This issue will > >> be addressed in JDK-8160228 > >> (SA cannot > view > >> the LambdaMetaFactory generated anonymous instanceKlasses)). > Hence > >> the current fix does not include the size addition for > >> InstanceKlasses representing anonymous classes. > >> > >> > >> > >> Thanks, > >> > >> - Jini Susan George > >> > >> > >> > > From alexander.kulyakhtin at oracle.com Thu Jul 21 14:03:46 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 21 Jul 2016 07:03:46 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <694c529e-c783-4b79-ad7d-5aaffbef1ebb@default> Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules . @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMT I spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin ; Serviceability-Dev 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 christian.tornqvist at oracle.com Thu Jul 21 15:29:49 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 21 Jul 2016 11:29:49 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <694c529e-c783-4b79-ad7d-5aaffbef1ebb@default> References: <694c529e-c783-4b79-ad7d-5aaffbef1ebb@default> Message-ID: <0a5c01d1e364$b8a7bb50$29f731f0$@oracle.com> Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin >; Serviceability-Dev > 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 Thu Jul 21 15:39:19 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Jul 2016 08:39:19 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <0a5c01d1e364$b8a7bb50$29f731f0$@oracle.com> References: <694c529e-c783-4b79-ad7d-5aaffbef1ebb@default> <0a5c01d1e364$b8a7bb50$29f731f0$@oracle.com> Message-ID: <5790ECA7.20604@oracle.com> On 7/21/16 08:29, Christian Tornqvist wrote: > > Hi Alexander, > > >The JVMTI always reports 3 unnamed modules: the boot module, the system > module and the application module. > > >The Java API does not report any unnamed modules. > > I?ll leave this up to you if this is something that we need to verify > or not, the code for doing this is also overcomplicated and can be > reduced to a simple assertGTE. > The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei > >This should be doable without using JAR's and custom loaders by using > Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > > >The test has been written from the user perspective. The user loads a new > module in the form of jar using the ModuleLoader.loadModule() API. > Then the test checks that JVMTI does return the info about that loaded > module. > > >Probably, defining the module using Layer.defineModules would not be the same > as loading the module using ModuleLoader.loadModule(), since the JVMTI > GetAllModules() returns the info about all the currently loaded modules. > > >As the JVMTI spec says: "GetAllModules: Return an array of all modules > loaded in the virtual machine.", it does not mention defining modules. > > There are several ways to get modules loaded/defined, the > Layer.defineModules is part of the official Java API and is one of > them. It doesn?t matter to JVMTI if they come from JAR files on disk > or if they?re defined using a Java API, so I suggest you go with > Layer.defineModules. > > Thanks, > > Christian > > *From:*Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] > *Sent:* Thursday, July 21, 2016 10:04 AM > *To:* Serguei Vladimirovich Spitsyn ; > christian.tornqvist at oracle.com > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > Christian, > > Thank you very much for your comments. I have some concerns about the > proposed changes: > > @45 & @67 > > Why is this check needed? Why are there least 3 unnamed modules? > The JVMTI always reports 3 unnamed modules: the boot module, the > system module and the application module. > The Java API does not report any unnamed modules. > > @54 > > This should be doable without using JAR's and custom loaders by using > Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > The test has been written from the user perspective. The user loads a > new module in the form of jar using the ModuleLoader.loadModule() API. > Then the test checks that JVMTI does return the info about that loaded > module. > Probably, defining the module using Layer.defineModules would not be > the same as loading the module using ModuleLoader.loadModule(), since > the JVMTI GetAllModules() returns the info about all the currently > loaded modules. > As the JVMTI spec says: "GetAllModules: Return an array of all modules > loaded in the virtual machine.", it does not mention defining modules. > > Could you, please, clarify these points for me so I fix the test > appropriately? > > Best regards, > Alexander > > > > > > ----- Original Message ----- > From: christian.tornqvist at oracle.com > > To: alexander.kulyakhtin at oracle.com > , > serviceability-dev at openjdk.java.net > > Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq > Subject: RE: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > > Hi Alexander, > > This test is unnecessarily complicated, it could be simplified a lot. > > JvmtiGetAllModulesTest.java > > Move getModulesNative() into JvmtiGetAllModulesTest.java and have it > return a Set to be able to use equals later > > @27 * @compile JvmtiGetAllModulesTest.java > > No need for this, jtreg will compile it for you > > @45 & @67 > > Why is this check needed? Why are there least 3 unnamed modules? > > @50 > > Change this to: assertTrue(Layer.boot().equals(getModulesNative())); > > @54 > > This should be doable without using JAR's and custom loaders by using > Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > > @65 > > Change this to an assertTrue using the layer containing the new > module, similar to the change @50 > > @73 > > No need for this method > > @81 > > Change this method to use the Layer.defineModules() method to define a > module instead, this eliminates the need for external JAR's > > @98 > > No need for this method > > If you use Layer.defineModules(), the following files can be removed: > > JarBuilder.java > > JavaModulesInfo.java > > JvmtiModulesInfo.java > > ModuleLoader.java > > ModulesInfo.java > > module-info.java > > Thanks, > > Christian > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of > *serguei.spitsyn at oracle.com > *Sent:* Monday, May 2, 2016 6:06 PM > *To:* Alexander Kulyakhtin >; Serviceability-Dev > > > *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 Thu Jul 21 17:14:12 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 21 Jul 2016 10:14:12 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <5acb9725-4009-4d66-b3da-cb56151c999a@default> Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [ mailto:alexander.kulyakhtin at oracle.com ] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [ mailto:serviceability-dev-bounces at openjdk.java.net ] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin < alexander.kulyakhtin at oracle.com >; Serviceability-Dev < serviceability-dev at openjdk.java.net > 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 Thu Jul 21 18:35:43 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Jul 2016 11:35:43 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <5acb9725-4009-4d66-b3da-cb56151c999a@default> References: <5acb9725-4009-4d66-b3da-cb56151c999a@default> Message-ID: <579115FF.6030604@oracle.com> Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: > Christian, Sergey, > > I've modified the test per your findings. Now it is one java file and > one C file only. > > Please, find the updated review at: > > Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ > > Thank you very much for your help. > > 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq > Subject: Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > On 7/21/16 08:29, Christian Tornqvist wrote: > > Hi Alexander, > > >The JVMTI always reports 3 unnamed modules: the boot module, the > system module and the application module. > > >The Java API does not report any unnamed modules. > > I?ll leave this up to you if this is something that we need to > verify or not, the code for doing this is also overcomplicated and > can be reduced to a simple assertGTE. > > > The rule is that there is one unnamed module per a class loader. > The options are: to test this rule or remove the check. > For simplicity is better to remove this check as unclear. > > Thanks, > Serguei > > >This should be doable without using JAR's and custom loaders by using > Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > > >The test has been written from the user perspective. The user loads a > new module in the form of jar using the ModuleLoader.loadModule() > API. Then the test checks that JVMTI does return the info about > that loaded module. > > >Probably, defining the module using Layer.defineModules would not be the > same as loading the module using ModuleLoader.loadModule(), since > the JVMTI GetAllModules() returns the info about all the currently > loaded modules. > > >As the JVMTI spec says: "GetAllModules: Return an array of all > modules loaded in the virtual machine.", it does not mention > defining modules. > > There are several ways to get modules loaded/defined, the > Layer.defineModules is part of the official Java API and is one of > them. It doesn?t matter to JVMTI if they come from JAR files on > disk or if they?re defined using a Java API, so I suggest you go > with Layer.defineModules. > > Thanks, > > Christian > > *From:*Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] > *Sent:* Thursday, July 21, 2016 10:04 AM > *To:* Serguei Vladimirovich Spitsyn ; > christian.tornqvist at oracle.com > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > Christian, > > Thank you very much for your comments. I have some concerns about > the proposed changes: > > @45 & @67 > > Why is this check needed? Why are there least 3 unnamed modules? > The JVMTI always reports 3 unnamed modules: the boot module, the > system module and the application module. > The Java API does not report any unnamed modules. > > @54 > > This should be doable without using JAR's and custom loaders by > using Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > The test has been written from the user perspective. The user > loads a new module in the form of jar using the > ModuleLoader.loadModule() API. Then the test checks that JVMTI > does return the info about that loaded module. > Probably, defining the module using Layer.defineModules would not > be the same as loading the module using ModuleLoader.loadModule(), > since the JVMTI GetAllModules() returns the info about all the > currently loaded modules. > As the JVMTI spec says: "GetAllModules: Return an array of all > modules loaded in the virtual machine.", it does not mention > defining modules. > > Could you, please, clarify these points for me so I fix the test > appropriately? > > Best regards, > Alexander > > > > > > ----- Original Message ----- > From: christian.tornqvist at oracle.com > > To: alexander.kulyakhtin at oracle.com > , > serviceability-dev at openjdk.java.net > > Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq > Subject: RE: RFR:8153978:New test to verify the modules info as > returned by the JVMTI > > > Hi Alexander, > > This test is unnecessarily complicated, it could be simplified a lot. > > JvmtiGetAllModulesTest.java > > Move getModulesNative() into JvmtiGetAllModulesTest.java and have > it return a Set to be able to use equals later > > @27 * @compile JvmtiGetAllModulesTest.java > > No need for this, jtreg will compile it for you > > @45 & @67 > > Why is this check needed? Why are there least 3 unnamed modules? > > @50 > > Change this to: assertTrue(Layer.boot().equals(getModulesNative())); > > @54 > > This should be doable without using JAR's and custom loaders by > using Layer.defineModules(), see the examples in > jdk/test/java/lang/reflect/Layer/BasicLayerTest.java > > @65 > > Change this to an assertTrue using the layer containing the new > module, similar to the change @50 > > @73 > > No need for this method > > @81 > > Change this method to use the Layer.defineModules() method to > define a module instead, this eliminates the need for external JAR's > > @98 > > No need for this method > > If you use Layer.defineModules(), the following files can be removed: > > JarBuilder.java > > JavaModulesInfo.java > > JvmtiModulesInfo.java > > ModuleLoader.java > > ModulesInfo.java > > module-info.java > > Thanks, > > Christian > > *From:*serviceability-dev > [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf Of > *serguei.spitsyn at oracle.com > *Sent:* Monday, May 2, 2016 6:06 PM > *To:* Alexander Kulyakhtin ; > Serviceability-Dev > > *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 Thu Jul 21 21:05:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Jul 2016 14:05:25 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <579115FF.6030604@oracle.com> References: <5acb9725-4009-4d66-b3da-cb56151c999a@default> <579115FF.6030604@oracle.com> Message-ID: <57913915.3070605@oracle.com> On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: > Hi Alexander, > > JvmtiGetAllModulesTest.java > > It looks pretty good but it would be nice if there is any chance to > simplify even more. > However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei > > libJvmtiGetAllModulesTest.c > > Unneeded indent for all lines. > Otherwise, it is good. > > Thanks, > Serguei > > > > On 7/21/16 10:14, Alexander Kulyakhtin wrote: >> Christian, Sergey, >> >> I've modified the test per your findings. Now it is one java file and >> one C file only. >> >> Please, find the updated review at: >> >> Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ >> >> Thank you very much for your help. >> >> 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq >> Subject: Re: RFR:8153978:New test to verify the modules info as >> returned by the JVMTI >> >> On 7/21/16 08:29, Christian Tornqvist wrote: >> >> Hi Alexander, >> >> >The JVMTI always reports 3 unnamed modules: the boot module, the >> system module and the application module. >> >> >The Java API does not report any unnamed modules. >> >> I?ll leave this up to you if this is something that we need to >> verify or not, the code for doing this is also overcomplicated >> and can be reduced to a simple assertGTE. >> >> >> The rule is that there is one unnamed module per a class loader. >> The options are: to test this rule or remove the check. >> For simplicity is better to remove this check as unclear. >> >> Thanks, >> Serguei >> >> >This should be doable without using JAR's and custom loaders by using >> Layer.defineModules(), see the examples in >> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >> >> >The test has been written from the user perspective. The user loads >> a new module in the form of jar using the >> ModuleLoader.loadModule() API. Then the test checks that JVMTI >> does return the info about that loaded module. >> >> >Probably, defining the module using Layer.defineModules would not be the >> same as loading the module using ModuleLoader.loadModule(), since >> the JVMTI GetAllModules() returns the info about all the >> currently loaded modules. >> >> >As the JVMTI spec says: "GetAllModules: Return an array of all >> modules loaded in the virtual machine.", it does not mention >> defining modules. >> >> There are several ways to get modules loaded/defined, the >> Layer.defineModules is part of the official Java API and is one >> of them. It doesn?t matter to JVMTI if they come from JAR files >> on disk or if they?re defined using a Java API, so I suggest you >> go with Layer.defineModules. >> >> Thanks, >> >> Christian >> >> *From:*Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] >> *Sent:* Thursday, July 21, 2016 10:04 AM >> *To:* Serguei Vladimirovich Spitsyn ; >> christian.tornqvist at oracle.com >> *Cc:* serviceability-dev at openjdk.java.net >> *Subject:* Re: RFR:8153978:New test to verify the modules info as >> returned by the JVMTI >> >> Christian, >> >> Thank you very much for your comments. I have some concerns about >> the proposed changes: >> >> @45 & @67 >> >> Why is this check needed? Why are there least 3 unnamed modules? >> The JVMTI always reports 3 unnamed modules: the boot module, the >> system module and the application module. >> The Java API does not report any unnamed modules. >> >> @54 >> >> This should be doable without using JAR's and custom loaders by >> using Layer.defineModules(), see the examples in >> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >> The test has been written from the user perspective. The user >> loads a new module in the form of jar using the >> ModuleLoader.loadModule() API. Then the test checks that JVMTI >> does return the info about that loaded module. >> Probably, defining the module using Layer.defineModules would not >> be the same as loading the module using >> ModuleLoader.loadModule(), since the JVMTI GetAllModules() >> returns the info about all the currently loaded modules. >> As the JVMTI spec says: "GetAllModules: Return an array of all >> modules loaded in the virtual machine.", it does not mention >> defining modules. >> >> Could you, please, clarify these points for me so I fix the test >> appropriately? >> >> Best regards, >> Alexander >> >> >> >> >> >> ----- Original Message ----- >> From: christian.tornqvist at oracle.com >> >> To: alexander.kulyakhtin at oracle.com >> , >> serviceability-dev at openjdk.java.net >> >> Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq >> Subject: RE: RFR:8153978:New test to verify the modules info as >> returned by the JVMTI >> >> >> Hi Alexander, >> >> This test is unnecessarily complicated, it could be simplified a lot. >> >> JvmtiGetAllModulesTest.java >> >> Move getModulesNative() into JvmtiGetAllModulesTest.java and have >> it return a Set to be able to use equals later >> >> @27 * @compile JvmtiGetAllModulesTest.java >> >> No need for this, jtreg will compile it for you >> >> @45 & @67 >> >> Why is this check needed? Why are there least 3 unnamed modules? >> >> @50 >> >> Change this to: assertTrue(Layer.boot().equals(getModulesNative())); >> >> @54 >> >> This should be doable without using JAR's and custom loaders by >> using Layer.defineModules(), see the examples in >> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >> >> @65 >> >> Change this to an assertTrue using the layer containing the new >> module, similar to the change @50 >> >> @73 >> >> No need for this method >> >> @81 >> >> Change this method to use the Layer.defineModules() method to >> define a module instead, this eliminates the need for external JAR's >> >> @98 >> >> No need for this method >> >> If you use Layer.defineModules(), the following files can be removed: >> >> JarBuilder.java >> >> JavaModulesInfo.java >> >> JvmtiModulesInfo.java >> >> ModuleLoader.java >> >> ModulesInfo.java >> >> module-info.java >> >> Thanks, >> >> Christian >> >> *From:*serviceability-dev >> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf >> Of *serguei.spitsyn at oracle.com >> *Sent:* Monday, May 2, 2016 6:06 PM >> *To:* Alexander Kulyakhtin ; >> Serviceability-Dev >> *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 Fri Jul 22 08:31:12 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 22 Jul 2016 01:31:12 -0700 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <57913915.3070605@oracle.com> References: <5acb9725-4009-4d66-b3da-cb56151c999a@default> <579115FF.6030604@oracle.com> <57913915.3070605@oracle.com> Message-ID: <5791D9D0.3050907@oracle.com> Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: > On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: >> Hi Alexander, >> >> JvmtiGetAllModulesTest.java >> >> It looks pretty good but it would be nice if there is any chance to >> simplify even more. >> However, I can't suggest anything at the moment. > > 67 // Verify that JVMTI reports exactly the same info as Java > regarding the named modules > 68 Layer.boot().equals(getModulesJVMTI()); 69 > . . . > 89 // Verify the consistency of the whole JVMTI report again > 90 Layer.boot().equals(getModulesJVMTI()); 91 > > The above lines can be removed. > They even do not check the result of comparison. > > Thanks, > Serguei > > >> >> libJvmtiGetAllModulesTest.c >> >> Unneeded indent for all lines. >> Otherwise, it is good. >> >> Thanks, >> Serguei >> >> >> >> On 7/21/16 10:14, Alexander Kulyakhtin wrote: >>> Christian, Sergey, >>> >>> I've modified the test per your findings. Now it is one java file >>> and one C file only. >>> >>> Please, find the updated review at: >>> >>> Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ >>> >>> Thank you very much for your help. >>> >>> 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq >>> Subject: Re: RFR:8153978:New test to verify the modules info as >>> returned by the JVMTI >>> >>> On 7/21/16 08:29, Christian Tornqvist wrote: >>> >>> Hi Alexander, >>> >>> >The JVMTI always reports 3 unnamed modules: the boot module, the >>> system module and the application module. >>> >>> >The Java API does not report any unnamed modules. >>> >>> I?ll leave this up to you if this is something that we need to >>> verify or not, the code for doing this is also overcomplicated >>> and can be reduced to a simple assertGTE. >>> >>> >>> The rule is that there is one unnamed module per a class loader. >>> The options are: to test this rule or remove the check. >>> For simplicity is better to remove this check as unclear. >>> >>> Thanks, >>> Serguei >>> >>> >This should be doable without using JAR's and custom loaders by >>> using Layer.defineModules(), see the examples in >>> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >>> >>> >The test has been written from the user perspective. The user loads >>> a new module in the form of jar using the >>> ModuleLoader.loadModule() API. Then the test checks that JVMTI >>> does return the info about that loaded module. >>> >>> >Probably, defining the module using Layer.defineModules would not be the >>> same as loading the module using ModuleLoader.loadModule(), >>> since the JVMTI GetAllModules() returns the info about all the >>> currently loaded modules. >>> >>> >As the JVMTI spec says: "GetAllModules: Return an array of all >>> modules loaded in the virtual machine.", it does not mention >>> defining modules. >>> >>> There are several ways to get modules loaded/defined, the >>> Layer.defineModules is part of the official Java API and is one >>> of them. It doesn?t matter to JVMTI if they come from JAR files >>> on disk or if they?re defined using a Java API, so I suggest you >>> go with Layer.defineModules. >>> >>> Thanks, >>> >>> Christian >>> >>> *From:*Alexander Kulyakhtin >>> [mailto:alexander.kulyakhtin at oracle.com] >>> *Sent:* Thursday, July 21, 2016 10:04 AM >>> *To:* Serguei Vladimirovich Spitsyn >>> ; christian.tornqvist at oracle.com >>> *Cc:* serviceability-dev at openjdk.java.net >>> *Subject:* Re: RFR:8153978:New test to verify the modules info >>> as returned by the JVMTI >>> >>> Christian, >>> >>> Thank you very much for your comments. I have some concerns >>> about the proposed changes: >>> >>> @45 & @67 >>> >>> Why is this check needed? Why are there least 3 unnamed modules? >>> The JVMTI always reports 3 unnamed modules: the boot module, the >>> system module and the application module. >>> The Java API does not report any unnamed modules. >>> >>> @54 >>> >>> This should be doable without using JAR's and custom loaders by >>> using Layer.defineModules(), see the examples in >>> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >>> The test has been written from the user perspective. The user >>> loads a new module in the form of jar using the >>> ModuleLoader.loadModule() API. Then the test checks that JVMTI >>> does return the info about that loaded module. >>> Probably, defining the module using Layer.defineModules would >>> not be the same as loading the module using >>> ModuleLoader.loadModule(), since the JVMTI GetAllModules() >>> returns the info about all the currently loaded modules. >>> As the JVMTI spec says: "GetAllModules: Return an array of all >>> modules loaded in the virtual machine.", it does not mention >>> defining modules. >>> >>> Could you, please, clarify these points for me so I fix the test >>> appropriately? >>> >>> Best regards, >>> Alexander >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: christian.tornqvist at oracle.com >>> >>> To: alexander.kulyakhtin at oracle.com >>> , >>> serviceability-dev at openjdk.java.net >>> >>> Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq >>> Subject: RE: RFR:8153978:New test to verify the modules info as >>> returned by the JVMTI >>> >>> >>> Hi Alexander, >>> >>> This test is unnecessarily complicated, it could be simplified a >>> lot. >>> >>> JvmtiGetAllModulesTest.java >>> >>> Move getModulesNative() into JvmtiGetAllModulesTest.java and >>> have it return a Set to be able to use equals later >>> >>> @27 * @compile JvmtiGetAllModulesTest.java >>> >>> No need for this, jtreg will compile it for you >>> >>> @45 & @67 >>> >>> Why is this check needed? Why are there least 3 unnamed modules? >>> >>> @50 >>> >>> Change this to: assertTrue(Layer.boot().equals(getModulesNative())); >>> >>> @54 >>> >>> This should be doable without using JAR's and custom loaders by >>> using Layer.defineModules(), see the examples in >>> jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >>> >>> @65 >>> >>> Change this to an assertTrue using the layer containing the new >>> module, similar to the change @50 >>> >>> @73 >>> >>> No need for this method >>> >>> @81 >>> >>> Change this method to use the Layer.defineModules() method to >>> define a module instead, this eliminates the need for external >>> JAR's >>> >>> @98 >>> >>> No need for this method >>> >>> If you use Layer.defineModules(), the following files can be >>> removed: >>> >>> JarBuilder.java >>> >>> JavaModulesInfo.java >>> >>> JvmtiModulesInfo.java >>> >>> ModuleLoader.java >>> >>> ModulesInfo.java >>> >>> module-info.java >>> >>> Thanks, >>> >>> Christian >>> >>> *From:*serviceability-dev >>> [mailto:serviceability-dev-bounces at openjdk.java.net] *On Behalf >>> Of *serguei.spitsyn at oracle.com >>> *Sent:* Monday, May 2, 2016 6:06 PM >>> *To:* Alexander Kulyakhtin ; >>> Serviceability-Dev >>> *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 Fri Jul 22 11:40:14 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 22 Jul 2016 04:40:14 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <806aaec0-f827-458d-94db-4a3225861dbe@default> Hi Sergey, Thank you very much for the review. I'm going to wait for any other findings today and, if everything is fine, will push the fix then. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com, christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [ mailto:alexander.kulyakhtin at oracle.com ] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [ mailto:serviceability-dev-bounces at openjdk.java.net ] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin < alexander.kulyakhtin at oracle.com >; Serviceability-Dev < serviceability-dev at openjdk.java.net > 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 christian.tornqvist at oracle.com Fri Jul 22 12:50:04 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 22 Jul 2016 08:50:04 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <806aaec0-f827-458d-94db-4a3225861dbe@default> References: <806aaec0-f827-458d-94db-4a3225861dbe@default> Message-ID: <16b501d1e417$91d4d400$b57e7c00$@oracle.com> Hi Alexander, As Serguei said, the lines 68 and 90 doesn?t check the results so they should either do that or be removed. If you remove those lines, you can remove the filtering out of unnamed modules in getModulesJVMTI as well since that will no longer be necessary. Minor style thing, move the } on 76 to be on the same line as the opening {. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Friday, July 22, 2016 7:40 AM To: serguei.spitsyn at oracle.com Cc: christian.tornqvist at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Sergey, Thank you very much for the review. I'm going to wait for any other findings today and, if everything is fine, will push the fix then. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin >; Serviceability-Dev > 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 Fri Jul 22 12:57:08 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 22 Jul 2016 05:57:08 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <89be221d-8963-49ef-b5a7-fca311cd0ea0@default> Hi Christian, Yes, my intention was to check the equality of the returned data. I've changed line 68 to: Asserts.assertEquals(Layer.boot().modules(), getModulesJVMTI()); and removed line 90 since it's not needed. As to the line 76, that is how Netbeans has formatted the code. I've changed it to have {} on the same line now. Please, find the updated review at: http://cr.openjdk.java.net/~akulyakh/8153978_7/test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java.html Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com, serguei.spitsyn at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 3:50:09 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, As Serguei said, the lines 68 and 90 doesn?t check the results so they should either do that or be removed. If you remove those lines, you can remove the filtering out of unnamed modules in getModulesJVMTI as well since that will no longer be necessary. Minor style thing, move the } on 76 to be on the same line as the opening {. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Friday, July 22, 2016 7:40 AM To: serguei.spitsyn at oracle.com Cc: christian.tornqvist at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Sergey, Thank you very much for the review. I'm going to wait for any other findings today and, if everything is fine, will push the fix then. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [ mailto:alexander.kulyakhtin at oracle.com ] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [ mailto:serviceability-dev-bounces at openjdk.java.net ] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin < alexander.kulyakhtin at oracle.com >; Serviceability-Dev < serviceability-dev at openjdk.java.net > 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 christian.tornqvist at oracle.com Fri Jul 22 13:02:01 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 22 Jul 2016 09:02:01 -0400 Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI In-Reply-To: <89be221d-8963-49ef-b5a7-fca311cd0ea0@default> References: <89be221d-8963-49ef-b5a7-fca311cd0ea0@default> Message-ID: <16e201d1e419$40a11970$c1e34c50$@oracle.com> Hi Alexander, This looks good, thanks for adding this :) Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Friday, July 22, 2016 8:57 AM To: christian.tornqvist at oracle.com Cc: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Christian, Yes, my intention was to check the equality of the returned data. I've changed line 68 to: Asserts.assertEquals(Layer.boot().modules(), getModulesJVMTI()); and removed line 90 since it's not needed. As to the line 76, that is how Netbeans has formatted the code. I've changed it to have {} on the same line now. Please, find the updated review at: http://cr.openjdk.java.net/~akulyakh/8153978_7/test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java.html Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serguei.spitsyn at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 3:50:09 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, As Serguei said, the lines 68 and 90 doesn?t check the results so they should either do that or be removed. If you remove those lines, you can remove the filtering out of unnamed modules in getModulesJVMTI as well since that will no longer be necessary. Minor style thing, move the } on 76 to be on the same line as the opening {. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Friday, July 22, 2016 7:40 AM To: serguei.spitsyn at oracle.com Cc: christian.tornqvist at oracle.com ; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Sergey, Thank you very much for the review. I'm going to wait for any other findings today and, if everything is fine, will push the fix then. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin >; Serviceability-Dev > 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 Fri Jul 22 13:05:16 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 22 Jul 2016 06:05:16 -0700 (PDT) Subject: RFR:8153978:New test to verify the modules info as returned by the JVMTI Message-ID: <17851fa4-dbbb-4a12-98ca-eea7cf8aa4a1@default> Hi Christian, Thank you very much for the review. Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com Cc: serguei.spitsyn at oracle.com, serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 4:02:11 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This looks good, thanks for adding this J Thanks, Christian From: Alexander Kulyakhtin [mailto:alexander.kulyakhtin at oracle.com] Sent: Friday, July 22, 2016 8:57 AM To: christian.tornqvist at oracle.com Cc: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Christian, Yes, my intention was to check the equality of the returned data. I've changed line 68 to: Asserts.assertEquals(Layer.boot().modules(), getModulesJVMTI()); and removed line 90 since it's not needed. As to the line 76, that is how Netbeans has formatted the code. I've changed it to have {} on the same line now. Please, find the updated review at: http://cr.openjdk.java.net/~akulyakh/8153978_7/test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java.html Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serguei.spitsyn at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 3:50:09 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, As Serguei said, the lines 68 and 90 doesn?t check the results so they should either do that or be removed. If you remove those lines, you can remove the filtering out of unnamed modules in getModulesJVMTI as well since that will no longer be necessary. Minor style thing, move the } on 76 to be on the same line as the opening {. Thanks, Christian From: Alexander Kulyakhtin [ mailto:alexander.kulyakhtin at oracle.com ] Sent: Friday, July 22, 2016 7:40 AM To: serguei.spitsyn at oracle.com Cc: christian.tornqvist at oracle.com ; serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Sergey, Thank you very much for the review. I'm going to wait for any other findings today and, if everything is fine, will push the fix then. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Alexander, A thumbs up on the push. I leave it up to you and Christian to tweak and polish the test if you think it is necessary. Thank you a lot for working on it! Thanks, Serguei On 7/21/16 14:05, serguei.spitsyn at oracle.com wrote: On 7/21/16 11:35, serguei.spitsyn at oracle.com wrote: Hi Alexander, JvmtiGetAllModulesTest.java It looks pretty good but it would be nice if there is any chance to simplify even more. However, I can't suggest anything at the moment. 67 // Verify that JVMTI reports exactly the same info as Java regarding the named modules 68 Layer.boot().equals(getModulesJVMTI()); 69 . . . 89 // Verify the consistency of the whole JVMTI report again 90 Layer.boot().equals(getModulesJVMTI()); 91 The above lines can be removed. They even do not check the result of comparison. Thanks, Serguei libJvmtiGetAllModulesTest.c Unneeded indent for all lines. Otherwise, it is good. Thanks, Serguei On 7/21/16 10:14, Alexander Kulyakhtin wrote: Christian, Sergey, I've modified the test per your findings. Now it is one java file and one C file only. Please, find the updated review at: Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_6/ Thank you very much for your help. 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: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI On 7/21/16 08:29, Christian Tornqvist wrote: Hi Alexander, >The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. >The Java API does not report any unnamed modules. I?ll leave this up to you if this is something that we need to verify or not, the code for doing this is also overcomplicated and can be reduced to a simple assertGTE. The rule is that there is one unnamed module per a class loader. The options are: to test this rule or remove the check. For simplicity is better to remove this check as unclear. Thanks, Serguei >This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java >The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. >Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. >As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. There are several ways to get modules loaded/defined, the Layer.defineModules is part of the official Java API and is one of them. It doesn?t matter to JVMTI if they come from JAR files on disk or if they?re defined using a Java API, so I suggest you go with Layer.defineModules. Thanks, Christian From: Alexander Kulyakhtin [ mailto:alexander.kulyakhtin at oracle.com ] Sent: Thursday, July 21, 2016 10:04 AM To: Serguei Vladimirovich Spitsyn ; christian.tornqvist at oracle.com Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:8153978:New test to verify the modules info as returned by the JVMTI Christian, Thank you very much for your comments. I have some concerns about the proposed changes: @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? The JVMTI always reports 3 unnamed modules: the boot module, the system module and the application module. The Java API does not report any unnamed modules. @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java The test has been written from the user perspective. The user loads a new module in the form of jar using the ModuleLoader.loadModule() API. Then the test checks that JVMTI does return the info about that loaded module. Probably, defining the module using Layer.defineModules would not be the same as loading the module using ModuleLoader.loadModule(), since the JVMTI GetAllModules() returns the info about all the currently loaded modules. As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded in the virtual machine.", it does not mention defining modules. Could you, please, clarify these points for me so I fix the test appropriately? Best regards, Alexander ----- Original Message ----- From: christian.tornqvist at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq Subject: RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI Hi Alexander, This test is unnecessarily complicated, it could be simplified a lot. JvmtiGetAllModulesTest.java Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a Set to be able to use equals later @27 * @compile JvmtiGetAllModulesTest.java No need for this, jtreg will compile it for you @45 & @67 Why is this check needed? Why are there least 3 unnamed modules? @50 Change this to: assertTrue(Layer.boot().equals(getModulesNative())); @54 This should be doable without using JAR's and custom loaders by using Layer.defineModules(), see the examples in jdk/test/java/lang/reflect/Layer/BasicLayerTest.java @65 Change this to an assertTrue using the layer containing the new module, similar to the change @50 @73 No need for this method @81 Change this method to use the Layer.defineModules() method to define a module instead, this eliminates the need for external JAR's @98 No need for this method If you use Layer.defineModules(), the following files can be removed: JarBuilder.java JavaModulesInfo.java JvmtiModulesInfo.java ModuleLoader.java ModulesInfo.java module-info.java Thanks, Christian From: serviceability-dev [ mailto:serviceability-dev-bounces at openjdk.java.net ] On Behalf Of serguei.spitsyn at oracle.com Sent: Monday, May 2, 2016 6:06 PM To: Alexander Kulyakhtin < alexander.kulyakhtin at oracle.com >; Serviceability-Dev < serviceability-dev at openjdk.java.net > 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 daniel.daugherty at oracle.com Tue Jul 26 19:53:50 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Jul 2016 13:53:50 -0600 Subject: Result: New Serviceability Group Lead: Staffan Larsen Message-ID: The vote for Staffan Larsen [1] is now closed. Yes: 4 No: 0 Abstain: 0 Not counted: 2 [3] According to the Bylaws definition of Simple Majority[2], this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Daniel Daugherty [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-July/019952.html [2] http://openjdk.java.net/bylaws#simple-majority Quoted here for convenience: > Simple Majority ? There are more Yes votes than No votes. [3] Two votes were cast by folks that were not members of the Serviceability Group so their votes could not be counted. Thanks for voting anyway! From sharath.ballal at oracle.com Wed Jul 27 08:43:29 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Jul 2016 01:43:29 -0700 (PDT) Subject: RFR: 8160817:Add jsadebugd functionality to jhsdb In-Reply-To: References: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> Message-ID: <8a3340e1-4603-4b22-a39c-b5bbe61d94b2@default> Hello, I figured out that the classLoaderStat functionality is already provided by 'jhsdb jmap --clstats' command. Hence I have removed the same from jhsdb in this webrev. I have updated the copyright year for the files. I have added the GPL copyright to the new file SADebugDTest.java. Pls review the same. http://cr.openjdk.java.net/~sballal/8160817/webrev.02/ -Sharath Ballal -----Original Message----- From: Sharath Ballal Sent: Monday, July 11, 2016 10:48 PM To: Dmitry Samersoff; serviceability-dev at openjdk.java.net Subject: RE: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb I have updated the review by adding SADebugDTest.java http://cr.openjdk.java.net/~sballal/8160817/webrev.01/index.html -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Monday, July 11, 2016 12:45 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb Sharath, Looks good for me. -Dmitry On 2016-07-08 18:06, Sharath Ballal wrote: > Hello, > > Please review the fix for: > > JDK-8160817 - *Add > jsadebugd and classLoaderStat functionality to jhsdb* > > Webrev is at: > > http://cr.openjdk.java.net/~sballal/8160817/webrev.00/index.html > > > > This fix moves the jsadebugd and classLoaderStat functionality to > jhsdb and move the TestClassLoaderStats.java functionality to > BasicLauncherTest.java. > > > > -Sharath Ballal > > > > > -- 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 sharath.ballal at oracle.com Wed Jul 27 08:43:36 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Jul 2016 01:43:36 -0700 (PDT) Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: <532ea808-a020-b5fe-e58a-e1b535e157d4@oracle.com> References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> <532ea808-a020-b5fe-e58a-e1b535e157d4@oracle.com> Message-ID: Hello, I realized I didn't update the copyright year, I have done the same. This is the webrev with the changes: http://cr.openjdk.java.net/~sballal/8158050/webrev.03/ -Sharath Ballal From: Alan Bateman Sent: Monday, July 11, 2016 10:51 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8158050: Remove SA-JDI On 11/07/2016 18:17, Sharath Ballal wrote: Alan, I have updated the review by removing certain tests from the 'src' directory (which I believe are obsolete). The SQE will be removing the tests owned by them separately, they have already quarantined the relevant tests. HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8158050/webrev.02/index.html"http://cr.openjdk.java.net/~sballal/8158050/webrev.02/index.html Okay. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Jul 27 09:27:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Jul 2016 12:27:18 +0300 Subject: RFR: 8158050: Remove SA-JDI In-Reply-To: References: <7a78a4f2-dac0-460c-96d1-6f82e9d66c33@default> <0f033542-6598-8ded-a6d6-53d4fc2d7bcc@oracle.com> <532ea808-a020-b5fe-e58a-e1b535e157d4@oracle.com> Message-ID: <899e342f-e769-9c6e-101d-b7ab2afd34a7@oracle.com> Looks good for me! On 2016-07-27 11:43, Sharath Ballal wrote: > Hello, > > > > I realized I didn?t update the copyright year, I have done the same. > This is the webrev with the changes: > > > > http://cr.openjdk.java.net/~sballal/8158050/webrev.03/ > > > > > > -Sharath Ballal > > > > > > *From:*Alan Bateman > *Sent:* Monday, July 11, 2016 10:51 PM > *To:* Sharath Ballal; serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: 8158050: Remove SA-JDI > > > > > > > > On 11/07/2016 18:17, Sharath Ballal wrote: > > Alan, > > I have updated the review by removing certain tests from the ?src? > directory (which I believe are obsolete). The SQE will be removing > the tests owned by them separately, they have already quarantined > the relevant tests. > > > > http://cr.openjdk.java.net/~sballal/8158050/webrev.02/index.html > > > > > Okay. > > -Alan. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Jul 27 09:35:26 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Jul 2016 12:35:26 +0300 Subject: RFR: 8160817:Add jsadebugd functionality to jhsdb In-Reply-To: <8a3340e1-4603-4b22-a39c-b5bbe61d94b2@default> References: <92e6d422-3c5c-4662-bc3a-e8e65b5ce8ed@default> <8a3340e1-4603-4b22-a39c-b5bbe61d94b2@default> Message-ID: Sharath, Looks good for me. -Dmitry On 2016-07-27 11:43, Sharath Ballal wrote: > Hello, > I figured out that the classLoaderStat functionality is already provided by 'jhsdb jmap --clstats' command. Hence I have removed the same from jhsdb in this webrev. I have updated the copyright year for the files. I have added the GPL copyright to the new file SADebugDTest.java. Pls review the same. > > http://cr.openjdk.java.net/~sballal/8160817/webrev.02/ > > -Sharath Ballal > > > -----Original Message----- > From: Sharath Ballal > Sent: Monday, July 11, 2016 10:48 PM > To: Dmitry Samersoff; serviceability-dev at openjdk.java.net > Subject: RE: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb > > I have updated the review by adding SADebugDTest.java > > http://cr.openjdk.java.net/~sballal/8160817/webrev.01/index.html > > -Sharath Ballal > > > > -----Original Message----- > From: Dmitry Samersoff > Sent: Monday, July 11, 2016 12:45 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8160817:Add jsadebugd and classLoaderStat functionality to jhsdb > > Sharath, > > Looks good for me. > > -Dmitry > > On 2016-07-08 18:06, Sharath Ballal wrote: >> Hello, >> >> Please review the fix for: >> >> JDK-8160817 - *Add >> jsadebugd and classLoaderStat functionality to jhsdb* >> >> Webrev is at: >> >> http://cr.openjdk.java.net/~sballal/8160817/webrev.00/index.html >> >> >> >> This fix moves the jsadebugd and classLoaderStat functionality to >> jhsdb and move the TestClassLoaderStats.java functionality to >> BasicLauncherTest.java. >> >> >> >> -Sharath Ballal >> >> >> >> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From amit.sapre at oracle.com Fri Jul 29 08:20:43 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Fri, 29 Jul 2016 01:20:43 -0700 (PDT) Subject: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member Message-ID: <8fd296d9-57fc-422d-81db-affbcdc8af0a@default> Hello, Please review this small fix. Bug : https://bugs.openjdk.java.net/browse/JDK-8162702 Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162702/webrev.00/ Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Fri Jul 29 09:05:04 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Fri, 29 Jul 2016 02:05:04 -0700 (PDT) Subject: RFR - JDK-8162524 : src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions Message-ID: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> Hello, Please review this small fix. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8162524 Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162524/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Jul 29 09:25:17 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 29 Jul 2016 12:25:17 +0300 Subject: RFR - JDK-8162524 : src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions In-Reply-To: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> References: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> Message-ID: <286843c8-265b-26b9-f70b-93c82b806e5c@oracle.com> Amit, Looks good for me. -Dmitry On 2016-07-29 12:05, Amit Sapre wrote: > Hello, > > > > Please review this small fix. > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8162524 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162524/webrev.00/ > > > > Thanks, > > Amit > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Fri Jul 29 09:29:14 2016 From: jini.george at oracle.com (Jini Susan George) Date: Fri, 29 Jul 2016 02:29:14 -0700 (PDT) Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation Message-ID: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> Hi all, Please review the fix for the following SA defect (to avoid exposing internal representations by storing or returning externally mutable objects directly). Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 Webrev: http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bachorik at gmail.com Fri Jul 29 11:37:06 2016 From: j.bachorik at gmail.com (Jaroslav Bachorik) Date: Fri, 29 Jul 2016 13:37:06 +0200 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> Message-ID: Hi Jini, 'null' seems to be a valid value for 'data' field in both of the places you are using 'data.clone()' - you should guard for null and call 'clone()' only if the passed in value is non-null. Cheers, -JB- On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George wrote: > Hi all, > > Please review the fix for the following SA defect (to avoid exposing > internal representations by storing or returning externally mutable > objects directly). > > Bug ID: *https://bugs.openjdk.java.net/browse/JDK-8068004* > > > Webrev: > *http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/* > > > Thanks, > > - Jini Susan George > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Fri Jul 29 11:41:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 29 Jul 2016 17:11:18 +0530 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> Message-ID: <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> If cloning is done to avoid exposing byte[] outside SA, this fix is not needed in jdk9. In jdk9, none of the SA packages are exposed and code outside SA cannot access this. Besides, Page data may be very big - cloning that ever constructor and getter may be too costly. -Sundar On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: > Hi Jini, > > 'null' seems to be a valid value for 'data' field in both of the > places you are using 'data.clone()' - you should guard for null and > call 'clone()' only if the passed in value is non-null. > > Cheers, > > -JB- > > On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George > > wrote: > > Hi all, > > Please review the fix for the followingSAdefect(to avoid exposing > internal representations by storingor returningexternally mutable > objectsdirectly). > > Bug ID:_https://bugs.openjdk.java.net/browse/JDK-8068004_ > > Webrev:_http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/_ > > Thanks, > > - Jini Susan George > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Jul 29 12:35:23 2016 From: jini.george at oracle.com (Jini Susan George) Date: Fri, 29 Jul 2016 05:35:23 -0700 (PDT) Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> Message-ID: <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> Thank you, JB and Sundar. Sundar, would that hold true even if ?XaddExports is used ? ? Regards, Jini. ? From: Sundararajan Athijegannathan Sent: Friday, July 29, 2016 5:11 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation ? If cloning is done to avoid exposing byte[] outside SA, this fix is not needed in jdk9. In jdk9, none of the SA packages are exposed and code outside SA cannot access this. Besides, Page data may be very big - cloning that ever constructor and getter may be too costly. -Sundar ? On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: Hi Jini, ? 'null' seems to be a valid value for 'data' field in both of the places you are using 'data.clone()' - you should guard for null and call 'clone()' only if the passed in value is non-null. ? Cheers, ? -JB- ? On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George wrote: Hi all, Please review the fix for the following SA defect (to avoid exposing internal representations by storing or returning externally mutable objects directly). Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/sponsorship/8068004/webrev.00/" \nhttp://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ Thanks, - Jini Susan George ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Fri Jul 29 13:19:56 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 29 Jul 2016 18:49:56 +0530 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> Message-ID: <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> Well, we can't code for that kind of overrides - Findbugs or any such tool is about normal mode of execution. With that argument, people can override classes using -Xpatch option as well! -Sundar On 7/29/2016 6:05 PM, Jini Susan George wrote: > > Thank you, JB and Sundar. Sundar, would that hold true even if > ?XaddExports is used ? > > > > Regards, > > Jini. > > > > *From:*Sundararajan Athijegannathan > *Sent:* Friday, July 29, 2016 5:11 PM > *To:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR: (XS): JDK-8068004: > [Findbugs]sun.jvm.hotspot.debugger may expose internal representation > > > > If cloning is done to avoid exposing byte[] outside SA, this fix is > not needed in jdk9. In jdk9, none of the SA packages are exposed and > code outside SA cannot access this. Besides, Page data may be very big > - cloning that ever constructor and getter may be too costly. > > -Sundar > > > > On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: > > Hi Jini, > > > > 'null' seems to be a valid value for 'data' field in both of the > places you are using 'data.clone()' - you should guard for null > and call 'clone()' only if the passed in value is non-null. > > > > Cheers, > > > > -JB- > > > > On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George > > wrote: > > Hi all, > > Please review the fix for the following SA defect (to avoid > exposing internal representations by storing or returning > externally mutable objects directly). > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 > > Webrev: > http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ > > > Thanks, > > - Jini Susan George > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Jul 29 16:06:24 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jul 2016 10:06:24 -0600 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> Message-ID: <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> Two points: 1) if Findbugs reports the same issue on JDK9 code, then we want to address such that we reduce any Findbugs noise 2) Fixing it could be considered to be a defense-in-depth change. Dan On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: > Well, we can't code for that kind of overrides - Findbugs or any such > tool is about normal mode of execution. With that argument, people can > override classes using -Xpatch option as well! > > -Sundar > > On 7/29/2016 6:05 PM, Jini Susan George wrote: >> >> Thank you, JB and Sundar. Sundar, would that hold true even if >> ?XaddExports is used ? >> >> Regards, >> >> Jini. >> >> *From:*Sundararajan Athijegannathan >> *Sent:* Friday, July 29, 2016 5:11 PM >> *To:* serviceability-dev at openjdk.java.net >> *Subject:* Re: RFR: (XS): JDK-8068004: >> [Findbugs]sun.jvm.hotspot.debugger may expose internal representation >> >> If cloning is done to avoid exposing byte[] outside SA, this fix is >> not needed in jdk9. In jdk9, none of the SA packages are exposed and >> code outside SA cannot access this. Besides, Page data may be very >> big - cloning that ever constructor and getter may be too costly. >> >> -Sundar >> >> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >> >> Hi Jini, >> >> 'null' seems to be a valid value for 'data' field in both of the >> places you are using 'data.clone()' - you should guard for null >> and call 'clone()' only if the passed in value is non-null. >> >> Cheers, >> >> -JB- >> >> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >> > wrote: >> >> Hi all, >> >> Please review the fix for the following SA defect (to avoid >> exposing internal representations by storing or returning >> externally mutable objects directly). >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >> >> Webrev: >> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >> >> >> Thanks, >> >> - Jini Susan George >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Fri Jul 29 16:16:11 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 29 Jul 2016 21:46:11 +0530 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> Message-ID: <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> Agreed that it could be considered as a defense-in-depth fix. But, in this case Page data could be huge. I think it was not cloned in first place to avoid copying many big byte[] instances around. -Sundar On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: > Two points: > > 1) if Findbugs reports the same issue on JDK9 code, then we want to > address such that we reduce any Findbugs noise > > 2) Fixing it could be considered to be a defense-in-depth change. > > Dan > > > On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: >> Well, we can't code for that kind of overrides - Findbugs or any such >> tool is about normal mode of execution. With that argument, people >> can override classes using -Xpatch option as well! >> >> -Sundar >> >> On 7/29/2016 6:05 PM, Jini Susan George wrote: >>> >>> Thank you, JB and Sundar. Sundar, would that hold true even if >>> ?XaddExports is used ? >>> >>> >>> >>> Regards, >>> >>> Jini. >>> >>> >>> >>> *From:*Sundararajan Athijegannathan >>> *Sent:* Friday, July 29, 2016 5:11 PM >>> *To:* serviceability-dev at openjdk.java.net >>> *Subject:* Re: RFR: (XS): JDK-8068004: >>> [Findbugs]sun.jvm.hotspot.debugger may expose internal representation >>> >>> >>> >>> If cloning is done to avoid exposing byte[] outside SA, this fix is >>> not needed in jdk9. In jdk9, none of the SA packages are exposed and >>> code outside SA cannot access this. Besides, Page data may be very >>> big - cloning that ever constructor and getter may be too costly. >>> >>> -Sundar >>> >>> >>> >>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >>> >>> Hi Jini, >>> >>> >>> >>> 'null' seems to be a valid value for 'data' field in both of the >>> places you are using 'data.clone()' - you should guard for null >>> and call 'clone()' only if the passed in value is non-null. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> -JB- >>> >>> >>> >>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >>> > wrote: >>> >>> Hi all, >>> >>> Please review the fix for the following SA defect (to avoid >>> exposing internal representations by storing or returning >>> externally mutable objects directly). >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >>> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Jul 29 16:26:40 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 Jul 2016 10:26:40 -0600 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> Message-ID: <1ca9a495-06a4-ecee-9b5e-c609f491d14f@oracle.com> I didn't miss this part: > Besides, Page data may be very big - cloning that ever > constructor and getter may be too costly. of what you originally wrote. :-) In my opinion, even defense-in-depth security trumps space savings. Dan On 7/29/16 10:16 AM, Sundararajan Athijegannathan wrote: > > Agreed that it could be considered as a defense-in-depth fix. But, in > this case Page data could be huge. I think it was not cloned in first > place to avoid copying many big byte[] instances around. > > -Sundar > > On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: >> Two points: >> >> 1) if Findbugs reports the same issue on JDK9 code, then we want to >> address such that we reduce any Findbugs noise >> >> 2) Fixing it could be considered to be a defense-in-depth change. >> >> Dan >> >> >> On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: >>> Well, we can't code for that kind of overrides - Findbugs or any >>> such tool is about normal mode of execution. With that argument, >>> people can override classes using -Xpatch option as well! >>> >>> -Sundar >>> >>> On 7/29/2016 6:05 PM, Jini Susan George wrote: >>>> >>>> Thank you, JB and Sundar. Sundar, would that hold true even if >>>> ?XaddExports is used ? >>>> >>>> Regards, >>>> >>>> Jini. >>>> >>>> *From:*Sundararajan Athijegannathan >>>> *Sent:* Friday, July 29, 2016 5:11 PM >>>> *To:* serviceability-dev at openjdk.java.net >>>> *Subject:* Re: RFR: (XS): JDK-8068004: >>>> [Findbugs]sun.jvm.hotspot.debugger may expose internal representation >>>> >>>> If cloning is done to avoid exposing byte[] outside SA, this fix is >>>> not needed in jdk9. In jdk9, none of the SA packages are exposed >>>> and code outside SA cannot access this. Besides, Page data may be >>>> very big - cloning that ever constructor and getter may be too costly. >>>> >>>> -Sundar >>>> >>>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >>>> >>>> Hi Jini, >>>> >>>> 'null' seems to be a valid value for 'data' field in both of >>>> the places you are using 'data.clone()' - you should guard for >>>> null and call 'clone()' only if the passed in value is non-null. >>>> >>>> Cheers, >>>> >>>> -JB- >>>> >>>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >>>> > wrote: >>>> >>>> Hi all, >>>> >>>> Please review the fix for the following SA defect (to avoid >>>> exposing internal representations by storing or returning >>>> externally mutable objects directly). >>>> >>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> - Jini Susan George >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: