RFR: 8200204: SharedArchiveConfigFile cannot accept output of VM.stringtable
Yasumasa Suenaga
yasuenag at gmail.com
Tue Mar 27 08:59:00 UTC 2018
Hi Ioi,
If my suggestion (1. in my previous email) is not accepted, I think it
should be documented.
Should I close this JBS ticket?
Thanks,
Yasumasa
2018-03-27 5:17 GMT+09:00 Ioi Lam <ioi.lam at oracle.com>:
>
>
> On 3/26/18 6:21 AM, Yasumasa Suenaga wrote:
>>
>> Hi Ioi,
>>
>>> I think a proper fix should clarify which VERSION we are looking for.
>>
>>
>> I agree with you, but I cannot agree with new format because it is
>> difficult to understand two different "VERSION" meanings.
>>
>> IMHO, we can change the format as below:
>>
>>
>> 1. Define same VERSION to all @SECTION. It is same of current behavior.
>> ----------------
>> VERSION: 1.0
>> @SECTION: Symbol
>> ....contents of "jcmd <pid> VM.symboltable -verbose" (**)
>> @SECTION: String
>> ....contents of "jcmd <pid> VM.stringtable -verbose"(**)
>> ----------------
>>
>> 2. Define same VERSION to all @SECTION except "String".
>> ----------------
>> VERSION: 1.0
>> @SECTION: Symbol
>> ....contents of "jcmd <pid> VM.symboltable -verbose" (**)
>> @SECTION: String
>> VERSION: 1.1
>> ....contents of "jcmd <pid> VM.stringtable -verbose"(**)
>> ----------------
>>
>> 3. Define VERSIONs in each @SECTIONs.
>> ----------------
>> @SECTION: Symbol
>> VERSION: 1.0
>> ....contents of "jcmd <pid> VM.symboltable -verbose" (**)
>> @SECTION: String
>> VERSION: 1.1
>> ....contents of "jcmd <pid> VM.stringtable -verbose"(**)
>> ----------------
>>
>>
>> How about this?
>>
> Maybe we should just keep the current behavior, and stick with 1.0 for the
> config file version. That way we don't need to make any code changes, and
> just need to clarify the user documentation.
>
> Thanks
> - Ioi
>
>
>> Thanks,
>> Yasumasa
>>
>>
>>
>> On 2018/03/26 13:39, Ioi Lam wrote:
>>>
>>> Hi Yasumasa,
>>>
>>> The word "VERSION" actually means different things in different places.
>>> That's the confusing part.
>>>
>>> "jcmd <pid> VM.stringtable -verbose" prints out the version of the
>>> "string listing".
>>>
>>> However,
>>>
>>> The VERSION in SharedArchiveConfigFile means the "version of the config
>>> file". The current version is 1.0. The format of this file is:
>>>
>>> ??? VERSION: 1.0
>>> ??? @SECTION: Symbol
>>> ??? ....contents of "jcmd <pid> VM.symboltable -verbose" (**)
>>> ??? @SECTION: String
>>> ??? ....contents of "jcmd <pid> VM.stringtable -verbose"(**)
>>>
>>> (**) The first two lines of jcmd output (pid and VERSION) should be
>>> skipped.
>>>
>>>
>>> So the creation of the config file is somewhat manual -- you need to cut
>>> out the process id anyway (maybe we should add an option to jcmd to not
>>> print the process ID).
>>>
>>> I think a proper fix should clarify which VERSION we are looking for. We
>>> need a mechanism to ensure that the @SECTIONs for Symbol and String are
>>> in the correct format as expected by the JVM.
>>>
>>> How about changing the config file format to this:
>>>
>>> ? ? VERSION: 1.1
>>> ??? @SECTION: Symbol
>>> ??? VERSION: 1.0
>>> ??? ....contents of "jcmd <pid> VM.symboltable -verbose" (**)
>>> ??? @SECTION: String
>>> ??? VERSION: 1.1
>>> ??? ....contents of "jcmd <pid> VM.stringtable -verbose" (**)
>>>
>>>
>>> So we have 3 kinds of VERSIONS - for the config file, for the symbol
>>> section, and for the string section.
>>>
>>> What do you think?
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>>
>>> On 3/25/18 5:46 PM, Yasumasa Suenaga wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please review this change.
>>>>
>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8200204
>>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8200204/webrev.00/
>>>> submit-hs: mach5-one-ysuenaga-JDK-8200204-20180325-1440-16057
>>>>
>>>>
>>>> JDK-8134448 says SharedArchiveConfigFile accepts output of `jcmd <pid>
>>>> VM.stringtable -verbose` , but it could not because JDK-8059510 has
>>>> changed version number to 1.1 .
>>>>
>>>> I think we should accept version 1.1 stringtable.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>
>
More information about the serviceability-dev
mailing list