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

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Apr 8 17:39:20 UTC 2016


On 4/8/16 6:47 AM, Nils Eliasson wrote:
> Hi,
>
> Picking up this thread again.
>
> On 2016-02-10 19:15, Vladimir Kozlov wrote:
>> This looks almost good.
>>
>> There is " at the end but there is no first ":
>>
> That was just the end of mark of the cut out of the hs_err file.
>
>> 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.
>
> The printout is generated by a macro for simplicity. Any sorting or formatting require a hand tuned print function or a
> macro that builds a list that is sorted and printed by the print function. I don't think it is worth the effort to have
> in the hs_err file.
>

This is really unfortunate. :(

>>
>> 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?
>
> Enable - Is the directive ok to use (otherwise disabled as in not available)
> Exclude - this method can not be compiled, as in CompileCommand=exclude
>
> I'll add comments to the flag table:
>
>    #define compilerdirectives_common_flags(cflags) \
>      cflags(Enable,                  bool, true, X)  /* false -> directive disabled from use */ \
>      cflags(Exclude,                 bool, false, X) /* true  -> don't compile method */ \

Should we rename these flags to make them more clear:
EnableDirective
ExcludeCompile

>
>>
>> DisableIntrinsic: does not have value so it should not be on list. Similar for others when they don't have values.
> DisableIntrinsic appear to be empty because it contains the empty list. I can add an "" for clarity. All options have a
> value.

Don't crate more noise when it is not needed. It is hs_err file - it is used to understand what happened. Useless 
information does not help. Even if DisableIntrinsic is specified in directive it should not be listed if it does not 
have value.

Actually I think it is bug - we should not accept directive or flag with empty string value.

>
>>
>> Again what * means in "*PrintInlining:true"? Is it because it is present on command line?
>
> A * shows that it was set with a directive.

Okay.

Thanks,
Vladimir

>
> Regards,
> Nils
>
>>
>> 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
>>>>>>>
>>>>>
>>>
>


More information about the hotspot-compiler-dev mailing list