CompileCommand help text

[Albert Noll]

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
>>>
>>>
>>
>