PING: RFR: JDK-8153074: UL: Show output option in VM.log jcmd
Yasumasa Suenaga
yasuenag at gmail.com
Thu Jun 30 13:01:09 UTC 2016
Hi Marcus,
> Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.)
I've fixed it.
Could you review again?
http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.07/
Thanks,
Yasumasa
On 2016/06/30 18:38, Marcus Larsson wrote:
> Hi,
>
>
> On 2016-06-30 11:31, Yasumasa Suenaga wrote:
>> Hi Marcus,
>>
>>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well.
>>
>> Ah, I understood.
>> If we refactor that in this enhancement, we do not need to make dynamic memory allocation.
>>
>> I uploaded a new webrev.
>> I hope this webrev matches your suggestion :-)
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.06/
>
> Looks good! Just a nit: Can we keep the printing of the index # in LogConfiguration? That would save us from passing it as a parameter to describe. (So, print index, call describe, and then print newline.)
>
> Thanks,
> Marcus
>
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/06/28 22:21, Yasumasa Suenaga wrote:
>>> Hi Marcus,
>>>
>>>> I don't really like that we need to make dynamic allocations here.
>>>
>>> Should use resource area? or char array?
>>> If we should use char array, how long should we reserve for buffer?
>>>
>>>
>>>> Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well.
>>>
>>> I think this is refactoring of LogOutput and LogConfiguration.
>>> Now (after FC date), is this work accepted?
>>>
>>> IMHO, refactoring is another enhancement from this.
>>> If it is needed, I think this enhancement should be started after
>>> refactoring.
>>>
>>>
>>> If refactoring and this enhancement can be merged and be accepted,
>>> I will start to work for it.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/06/28 20:23, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 06/28/2016 11:29 AM, Yasumasa Suenaga wrote:
>>>>> PING: Could you review and sponsor it?
>>>>>
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/
>>>>
>>>> I don't really like that we need to make dynamic allocations here. I would prefer to have the outputs be responsible for describing themselves just like David mentions. The current design of LogConfiguration::describe doesn't follow that pattern, but I really think it should. Therefore I suggest that we introduce a describe() function in LogOutput as part of this change, and move the code currently in LogConfiguration::describe to this function, adding the option text to it as well.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>>>
>>>>> I've requested FC extension for this.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2016/06/13 13:24, David Holmes wrote:
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> On 13/06/2016 1:45 PM, Yasumasa Suenaga wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Thank you for your comment.
>>>>>>>
>>>>>>>> So options are a distinct property of outputs and so should have been
>>>>>>>> a first class entity in LogOutput all along.
>>>>>>>
>>>>>>> I agree to you.
>>>>>>> But I think we need to discuss about it with logging folks.
>>>>>>>
>>>>>>> I uploaded a new webrev. It removes fixed buffer length and changes the
>>>>>>> order of output.
>>>>>>> Could you review again?
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.05/
>>>>>>
>>>>>> It's okay to wait and hear what opinions others may have before changing things based on my comments. :) The fixed buffer may be okay - as I said I don't know what the potential options are, so don't know if it is okay or not.
>>>>>>
>>>>>> Using dynamic allocation avoids that but raises other concerns - like calling vm_exit_on_out_of_memory on failure; or whether to use malloc or resource area?
>>>>>>
>>>>>> Lets wait for other feedback before going further.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> On 2016/06/13 9:05, David Holmes wrote:
>>>>>>>> Hi Yasumasa,
>>>>>>>>
>>>>>>>> On 13/06/2016 9:30 AM, Yasumasa Suenaga wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> I think "config_string" is different from "option_string".
>>>>>>>>>
>>>>>>>>> -Xlog format (from -Xlog:help message):
>>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]]
>>>>>>>>>
>>>>>>>>> config_string: "what" (ex. gc=trace)
>>>>>>>>> option_string: "output-options" (ex. filecount=5)
>>>>>>>>>
>>>>>>>>> Currently, LogOutput handles tags and loglevels only as config_string.
>>>>>>>>> It does not contain output options.
>>>>>>>>
>>>>>>>> Okay I'm starting to see the bigger picture here. In terms of the
>>>>>>>> overall logging configuration we might have, for example:
>>>>>>>>
>>>>>>>> gc=trace -> stdout
>>>>>>>> runtime=info -> fileA
>>>>>>>> compiler=trace -> fileB
>>>>>>>>
>>>>>>>> where the LHS is (part of) the configuration, and the RHS is the
>>>>>>>> output. So for each output we set its "configuration" to the
>>>>>>>> associated LHS.
>>>>>>>>
>>>>>>>> So options are a distinct property of outputs and so should have been
>>>>>>>> a first class entity in LogOutput all along.
>>>>>>>>
>>>>>>>> Okay so looking at your v4 I have two comments:
>>>>>>>>
>>>>>>>> First, hard-wiring OPTIONS_LEN. I don't know what the possible options
>>>>>>>> are so don't know if 100 is adequate.
>>>>>>>>
>>>>>>>> Second, if the logging syntax is:
>>>>>>>>
>>>>>>>> -Xlog[:[what][:[output][:[decorators][:output-options]]]]
>>>>>>>>
>>>>>>>> then shouldn't the configuration be printed in the same order/format?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Yasumasa
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2016/06/13 8:14, David Holmes wrote:
>>>>>>>>>> On 12/06/2016 11:10 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for your comment.
>>>>>>>>>>>
>>>>>>>>>>>> Is there some reason the option string could not simply become
>>>>>>>>>>>> part of
>>>>>>>>>>>> the existing configuration string?
>>>>>>>>>>>
>>>>>>>>>>> My first proposal keeps option string at LogOutput and its child class
>>>>>>>>>>> (See webrev.01).
>>>>>>>>>>> Marcus commented that option string should be generated from current
>>>>>>>>>>> configuration.
>>>>>>>>>>>
>>>>>>>>>>> I uploaded new webrev.
>>>>>>>>>>> Could you review again?
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.04/
>>>>>>>>>>
>>>>>>>>>> Sorry but I repeat my question - why is the option information not
>>>>>>>>>> simply part of the config_string?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Yasumasa
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2016/06/12 6:44, David Holmes wrote:
>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry but this API seems poorly fitting to me. First
>>>>>>>>>>>> print_option_string seems the wrong name given that the base class,
>>>>>>>>>>>> LogOutput, has no notion of having an "option string". It seems to be
>>>>>>>>>>>> a supposedly generic "print other stuff" function that only one class
>>>>>>>>>>>> actually needs to implement.
>>>>>>>>>>>>
>>>>>>>>>>>> Secondly it inverts the style of the API used for everything else
>>>>>>>>>>>> - we
>>>>>>>>>>>> have getters for all the other "properties" which are then printed by
>>>>>>>>>>>> the describe_current_configuration method. But this is instead a
>>>>>>>>>>>> "print" function where we ask the target to print itself. Mixing the
>>>>>>>>>>>> two styles seems messy. It probably would have been better to have
>>>>>>>>>>>> had
>>>>>>>>>>>> a print-style API from the start - then adding the options would have
>>>>>>>>>>>> been a trivial extension for those output classes with options.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition the change you made to describe_current_configuration is
>>>>>>>>>>>> not at all general purpose - you wanted a given format (print between
>>>>>>>>>>>> the config string and the decorators) for this one class and so you
>>>>>>>>>>>> added the code to support that format. But that format may not make
>>>>>>>>>>>> sense for other classes that might have "extra stuff" to print.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there some reason the option string could not simply become
>>>>>>>>>>>> part of
>>>>>>>>>>>> the existing configuration string? It seems to me that for a LogFile
>>>>>>>>>>>> these "options" really are part of the configuration.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>> PS. The two hpp files would need their copyright years updated to
>>>>>>>>>>>> "2015, 2016,".
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/06/2016 10:30 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>> PING: Could you review it?
>>>>>>>>>>>>> We need a second reviewer.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/
>>>>>>>>>>>>>
>>>>>>>>>>>>> This change is small fix, and it helps us to confirm current
>>>>>>>>>>>>> FileLogOutput configuration.
>>>>>>>>>>>>> So I want to merge it to jdk 9.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2016/05/17 19:17, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>> PING: Could you review it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2016/05/10 8:06, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>> We need a second reviewer.
>>>>>>>>>>>>>>> Could you review it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2016/05/04 23:38, Marcus Larsson wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 05/04/2016 04:12 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>> Hi Marcus,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ",
>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size),
>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size));
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks, I applied it to new webrev:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.03/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Looks OK.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Could you review again?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2016/05/04 22:35, Marcus Larsson wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 05/04/2016 02:59 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>> Hi Marcus,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thank you for your comment.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.02/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looks better. The format for _rotate_size should be
>>>>>>>>>>>>>>>>>> SIZE_FORMAT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> While we're at it I think it would be good (as I mentioned) to
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> a proper unit for the filesize. Basically changing
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=%lu ", _file_count,
>>>>>>>>>>>>>>>>>> _rotate_size);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 93 out->print("filecount=%u,filesize=" SIZE_FORMAT "%s ",
>>>>>>>>>>>>>>>>>> _file_count, byte_size_in_proper_unit(_rotate_size),
>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size(_rotate_size));
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I fixed to use _rotate_size and _file_count directly to show
>>>>>>>>>>>>>>>>>>> VM.log list jcmd.
>>>>>>>>>>>>>>>>>>> I do not store option string, and I added new function to
>>>>>>>>>>>>>>>>>>> print
>>>>>>>>>>>>>>>>>>> option string.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could you review it again?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 2016/05/04 18:33, Marcus Larsson wrote:
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 05/03/2016 01:43 PM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I would prefer to generate the option string from the actual
>>>>>>>>>>>>>>>>>>>> options rather than saving the string from when it was
>>>>>>>>>>>>>>>>>>>> configured. This would also produce/print the options for
>>>>>>>>>>>>>>>>>>>> outputs that are using the defaults (which is not the case
>>>>>>>>>>>>>>>>>>>> now).
>>>>>>>>>>>>>>>>>>>> The filesize option could then use
>>>>>>>>>>>>>>>>>>>> byte_size_in_proper_unit and
>>>>>>>>>>>>>>>>>>>> proper_unit_for_byte_size to make it easier to read.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Also, get_option_string() should just be called
>>>>>>>>>>>>>>>>>>>> option_string().
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Marcus
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This patch makes to show option string of LogFileOutput.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 2016/04/19 22:55, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>> I adapted changes to jdk9/hs/hotspot repos.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.01/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Please review.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 2016/04/18 23:09, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>> PING:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I've sent review request for JDK-8153074.
>>>>>>>>>>>>>>>>>>>>>>> Could you review it?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If this patch is merged, user can confirm output option
>>>>>>>>>>>>>>>>>>>>>>> via
>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Please review and sponsor it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 2016/04/11 18:29, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/31 22:35, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> CC'ed to serviceability-dev.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Could you review it?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 23:09, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> This request review is related to [1].
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I want to see output option (filecount, filesize) in
>>>>>>>>>>>>>>>>>>>>>>>>>> VM.log jcmd.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Output sample:
>>>>>>>>>>>>>>>>>>>>>>>>>> #2: gc.log gc=trace,
>>>>>>>>>>>>>>>>>>>>>>>>>> filecount=5,filesize=1048576
>>>>>>>>>>>>>>>>>>>>>>>>>> time,level,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I uploaded webrev. Could you review it?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>
>
More information about the hotspot-runtime-dev
mailing list