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

Nils Eliasson nils.eliasson at oracle.com
Fri Apr 8 13:47:22 UTC 2016


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.

>
> 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 */ \

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

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

A * shows that it was set with a directive.

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