RFR(S): 8138756: Compiler Control: Print directives in hs_err

Wed Feb 10 18:15:35 UTC 2016

This looks almost good.

There is " at the end but there is no first ":

MaxNodeLimit:80000"

"Compiling with directive:" --> "Compiling with directives:". "No inline rules in directive.", again "directives".

Also the list of values is difficult to navigate. To have one per line is definitely overkill but organizing them in 
some kind of patter would be nice (3 per line with the same indent, for example). It could be hard to do but at least 
order them alphabetically.

I asked before and I again forgot what it means "Enable:true Exclude:false". This means you need to add more info 
"Enable directives:true"? What is "Exclude" again?

DisableIntrinsic: does not have value so it should not be on list. Similar for others when they don't have values.

Again what * means in "*PrintInlining:true"? Is it because it is present on command line?

Thanks,
Vladimir

On 2/10/16 1:56 AM, Nils Eliasson wrote:
> Hi,
>
> New webrev including Vladimirs suggestions:
>
> http://cr.openjdk.java.net/~neliasso/8138756/webrev.04/
>
> Now it will look like this printing the directive when there are no compile commands for inlining:
>
> "---------------  T H R E A D  ---------------
>
> Current thread (0x00007f53f0468000):  JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8398,
> stack(0x00007f52e6163000,0x00007f52e6264000)]
>
> Current CompileTask:
> C1:    228    1       3       java.lang.String::isLatin1 (19 bytes)
>
> Compiling with directive:
>    No inline rules in directive.
>    Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true
> PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false
> DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false
> TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false
> DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000"
>
>
>
> And like this when there are:
>
>
> "---------------  T H R E A D  ---------------
>
> Current thread (0x00007feda4468800):  JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8314,
> stack(0x00007fec9a751000,0x00007fec9a852000)]
>
> Current CompileTask:
> C1:    227    1       3       java.lang.String::isLatin1 (19 bytes)
>
> Compiling with directive:
>    No inline rules in directive. Following compile commands are in use:
>      inline: b.b, a.a
>      dontinline: c.c
>      exclude: d.d
>      compileonly: *.*
>    Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true
> PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false
> DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false
> TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false
> DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000"
>
> Regards,
> Nils
>
> On 2016-01-22 19:56, Vladimir Kozlov wrote:
>> "no inline - compile commands may apply" is confusing to me (and for others who not familiar with directives). What
>> does it mean? :)
>> Does it mean no 'inline' directives were used or opposite: -XX:-Inline flag was specified (or corresponding directive).
>>
>> If it is switch off inlining then I think it should be "don't inline".
>> So what "compile commands may apply" means?
>>
>> > I updated the print output to mark all options in the directive that are
>> > not default with a '*'. That makes it quicker to see if any special
>>
>> Yes, it is better but I still did not get this. I see that command line has PrintInlining command and it is in the
>> list: *PrintInlining:true.
>> But I don't see PrintCompilation on the list but it is specified on command line. On other hand PrintIntrinsics:false
>> is there.
>>
>> > It only prints the directive that is used for the current compile task
>> > (that caused the crash). (Thats why I put them together in the hs_err file)
>>
>> What do you mean "is used"?
>>
>> "Print *which* directive (and options) were in use if compiler crash.
>>  Print *if* directives were used at some point if other crash?"
>>
>> Should we replace "in use"/"were used" with "were set"?
>>
>> Thanks,
>> Vladimir
>>
>> On 1/22/16 5:38 AM, Nils Eliasson wrote:
>>> Hi, Vladimir
>>>
>>> On 2016-01-21 20:28, Vladimir Kozlov wrote:
>>>> Passing directives through ciEnv is fine.
>>>> My question is about output in hs_err file. How those directives were
>>>> selected in your example?
>>>
>>> It only prints the directive that is used for the current compile task
>>> (that caused the crash). (Thats why I put them together in the hs_err file)
>>>
>>>> I found it strange to see mixed flags values and oracle commands.
>>>> "Enable:true Exclude:false" - which these correspond to, for example?
>>>
>>> These are all options from the directive - and they are set with
>>> directives (highest priority), compilecommmand or vmflags (lowest
>>> priority).
>>>
>>>>
>>>> Should we not print directives/flags which are not set explicitly?
>>>
>>> I updated the print output to mark all options in the directive that are
>>> not default with a '*'. That makes it quicker to see if any special
>>> options was applied. It will also print if the directive is the
>>> unmodified default directive.
>>>
>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/
>>> Example output:
>>> http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/hserr.txt
>>>
>>> Regards,
>>> Nils
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 1/21/16 2:31 AM, Nils Eliasson wrote:
>>>>> This is how it looks:
>>>>>
>>>>> [...]
>>>>>
>>>>> ---------------  T H R E A D  ---------------
>>>>>
>>>>> Current thread (0x00007f071046a000):  JavaThread "C1
>>>>> CompilerThread10" daemon [_thread_in_native, id=20033,
>>>>> stack(0x00007f05d7afb000,0x00007f05d7bfc000)]
>>>>>
>>>>> Current CompileTask:
>>>>> C1:    225    1       3       java.lang.String::isLatin1 (19 bytes)
>>>>>
>>>>> Current compiler directive:
>>>>>    inline: -
>>>>>    Enable:true Exclude:false BreakAtExecute:false
>>>>> BreakAtCompile:false Log:false PrintAssembly:false
>>>>> PrintInlining:false PrintNMethods:false ReplayInline:false
>>>>> DumpReplay:false DumpInline:false
>>>>> CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic:
>>>>> BlockLayoutByFrequency:true PrintOptoAssembly:false
>>>>> PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false
>>>>> TraceSpilling:false Vectorize:false VectorizeDebug:false
>>>>> CloneMapDebug:false DoReserveCopyInSuperWordDebug:false
>>>>> IGVPrintLevel:0 MaxNodeLimit:80000
>>>>>
>>>>> Stack: [0x00007f05d7afb000,0x00007f05d7bfc000],
>>>>> sp=0x00007f05d7bfa5d0,  free space=1021k
>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>> C=native code)
>>>>> V  [libjvm.so+0x12e7532]  VMError::report_and_die(int, char const*,
>>>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*,
>>>>> char const*, int, unsigned long)+0x182
>>>>> V  [libjvm.so+0x12e829a]  VMError::report_and_die(Thread*, char
>>>>> const*, int, char const*, char const*, __va_list_tag*)+0x4a
>>>>> V  [libjvm.so+0x908cca]  report_vm_error(char const*, int, char
>>>>> const*, char const*, ...)+0xea
>>>>> V  [libjvm.so+0x88df81] CompileBroker::post_compile(CompilerThread*,
>>>>> CompileTask*, EventCompilation&, bool, ciEnv*)+0x1b1
>>>>> V  [libjvm.so+0x88ec5a]
>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x90a
>>>>> V  [libjvm.so+0x88f960] CompileBroker::compiler_thread_loop()+0x540
>>>>> V  [libjvm.so+0x1264789] JavaThread::thread_main_inner()+0x1c9
>>>>> V  [libjvm.so+0x1264ac6]  JavaThread::run()+0x2a6
>>>>> V  [libjvm.so+0x10189aa]  java_start(Thread*)+0xca
>>>>> C  [libpthread.so.0+0x8182]  start_thread+0xc2
>>>>>
>>>>> [...]
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8138756/hserr.txt
>>>>>
>>>>> Regards,
>>>>> Nils
>>>>>
>>>>> On 2016-01-21 11:25, Nils Eliasson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this small change. The diff looks big but most of the
>>>>>> change is just changing how the directive are
>>>>>> passed to the compilers. Directives are set in the ciEnv and then
>>>>>> passed to the compilers. The compilers can then
>>>>>> choose to add it to any internal compilation object for convenience.
>>>>>> The hs_err printing routine in vmError.cpp loads
>>>>>> the directive from the ciEnv.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138756
>>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.01/
>>>>>>
>>>>>> Regards,
>>>>>> Nils
>>>>>
>>>
>