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