CompileCommand help text

[Albert Noll]

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.

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