CompileCommand help text

Nils Eliasson nils.eliasson at oracle.com
Tue Nov 25 12:55:42 UTC 2014


I have now included this text in my fix of CompileCommand parsing.

Thanks Albert!

//Nils

On 2014-11-25 12:53, Albert Noll wrote:
>
> On 11/25/2014 12:50 PM, Albert Noll wrote:
>> Hi Nils,
>>
>>
>> On 11/25/2014 11:30 AM, Nils Eliasson wrote:
>>> Hi Albert,
>>>
>>> I added your suggestions to the text. Answers to the questions 
>>> inline below.
>>>
>>> Thanks,
>>> Nils
>>>
>>>
>>> The CompileCommand option enables the user of the JVM to control 
>>> specific
>>> behavior of the dynamic compilers. The CompileCommand option defines 
>>> the
>>> following commands:
>>>
>>>   break,<pattern>       - debug breakpoint in compiler and in 
>>> generated code
>>>   print,<pattern>       - print assembly of method
>>>   exclude,<pattern>     - don't compile or inline this method
>>>   inline,<pattern>      - always inline this method
>>>   dontinline,<pattern>  - don't inline this method
>>>   compileonly,<pattern> - compile only this method
>>>   log,<pattern>         - log compilation of method
>>>   option,<pattern>,<option type>,<option name>,<value>
>>>   option,<pattern>,<bool option name>
>>>                         - set value of custom option
>>>   quiet                 - silence the compile command output
>>>   help                  - print this text
>>>
>>> The preferred pattern for referencing a method is:
>>>   "package/Class.method()"
>>>
>>> For backwards compatibility this form is also allowed:
>>>   "package.Class::method()"
>>>
>>> The signature can be separated by an optional whitespace or comma:
>>>   "package/Class.method ()"
>>>   "package.Class::method ()"
>>>   "package/Class,method,()"
>>>
>>> The class identifier and method can can be used together with 
>>> leading or
>>> trailing *'s for a small amount of wildcarding:
>>>   "*ackage/Clas*.*etho*()"
>>>
>>> It is possible to use more than one CompileCommand:
>>> -XX:CompileCommand=exclude,"java/*.*" -XX:CompileCommand=log,"java*.*"
>>>
>>> The CompileCommands can be loaded from a file with the flag
>>> -XX:CompileCommandFile=<file>. Use the same format without the flag:
>>>   exclude,"java/*.*"
>>>   log,"java*.*"
>>>
>> Up to here it looks good to me.
>>> These commands have conflicting behavior - exclude, inline, dontinline
>>> and compileonly. Currently there is no strict priority between then and
>>> the behavior is undefined when matching the same method.
>>>
>> I would rephrase the last paragraph as follows:
>>
>> "The following commands have conflicting behavior: 'exclude', 
>> 'inline', 'dontinline',
>> and 'compileonly'. There is no priority of commands. Applying (a 
>> subset) of these
>> commands to the same method results in undefined behavior.
>>
> .. (a subset of) ...
>
> Best,
> Albert
>
>> Best,
>> Albert
>>
>>>
>>>
>>> On 2014-11-25 11:03, Albert Noll wrote:
>>>> Hi Nils,
>>>>
>>>> here are my suggestions:
>>>>
>>>> On 11/25/2014 10:34 AM, Nils Eliasson wrote:
>>>>> Hi,
>>>>>
>>>>> I am updating the help text for CompileCommand and would 
>>>>> appreciate some feedback.
>>>>>
>>>>> Regards,
>>>>> Nils Eliasson
>>>>>
>>>>>
>>>>> Use a monospacced font.
>>>>>
>>>>> "
>>>>> CompileCommand allows some control over the compiler. The basic
>>>>> form of all commands is a command followed by the name of the method.
>>>> The CompileCommand option enables the user of the JVM to control 
>>>> specific behavior of the dynamic compilers.
>>>> The CompileCommand option defines the following commands:
>>>>> The compile commands are:
>>>>>   break,<pattern>       - add break in compiler and in C2 
>>>>> generated code
>>>> What does that mean?
>>> Adds a debug breakpoint in the beginning of compilation and in the 
>>> start of the generated code, see BREAKPOINT macro and 
>>> break_at_execute(). Missing from C1 generated code at the moment but 
>>> should be added ASAP. (C1 has the C1Breakpoint flag so the 
>>> functionality is there)
>>>
>>>>> print,<pattern>       - print assembly for method
>>>> use 'of' instead of 'for'
>>>>> exclude,<pattern>     - don't compile or inline this method
>>>>>   inline,<pattern>      - force inline this method
>>>> - "always inline this method"
>>>>> dontinline,<pattern>  - prevent inlining of this method
>>>> -"don't inline this method"
>>>>> compileonly,<pattern> - exclude all methods except this one
>>>> -"compile only this method"
>>>>> log,<pattern>         - log this compilation
>>>> Does that mean log the compilation of this method?
>>>
>>> Yes. LogCompilation output.
>>>
>>>>> option,<pattern>,<option type>,<option name>,<value>
>>>>>                         - set value of custom option
>>>>>   option,<pattern>,<bool option name>
>>>>>                         - short hand for setting boolean option
>>>>>   quiet                 - silence the compile command output
>>>>>   help                  - print this text
>>>>>
>>>>> The preferred pattern for referencing a method is:
>>>>>   "package/Class.method()"
>>>>>
>>>>> For backwards compatibility this form is also allowed:
>>>>>   "package.Class::method()"
>>>>>
>>>>> The signature can be separated by an optional whitespace or comma:
>>>>>   "package/Class.method ()"
>>>>>   "package.Class::method ()"
>>>>>   "package/Class,method,()"
>>>>>
>>>>> The class identifier and method can can be used together with 
>>>>> leading or
>>>>> trailing *'s for a small amount of wildcarding.
>>>>>   "*ackage/Clas*.*etho*()"
>>>>>
>>>>> Several CompileCommands can be used on the same command line.
>>>> "It is possible to use more than one CompileCommand."
>>>>> -XX:CompileCommand=exclude,"java/*.*" 
>>>>> -XX:CompileCommand=log,"java*.*"
>>>>>
>>>>> The CompileCommands can also be loaded from a file with the flag
>>>> I think you can skip 'also'
>>>>> -XX:CompileCommandFile=<file>. Use the same format but without the
>>>>> commandline flag.
>>>>>   exclude,"java/*.*"
>>>>>   log,"java*.*"
>>>>>
>>>>> Some commands have conflicting behavior. Currently they have a
>>>>> undefined behavior when used together.
>>>>> "
>>>> It would be good to know which commands conflict. E.g., how do I 
>>>> know that 'dontinline' and 'log' do not conflict?
>>>>
>>>> Best,
>>>> Albert
>>>>
>>>>
>>>
>>
>



More information about the hotspot-compiler-dev mailing list