RFR(S): 8147432: JVMCI should report bailouts in PrintCompilation output

Christian Thalinger christian.thalinger at oracle.com
Tue Jan 19 20:44:20 UTC 2016


> On Jan 19, 2016, at 10:40 AM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
> 
>> On Jan 19, 2016, at 12:12 PM, Christian Thalinger <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>> wrote:
>> 
>> src/share/vm/compiler/compileBroker.cpp:
>> 
>> +      failure_reason = ci_env.failure_reason();
>> +      retry_message = ci_env.retry_message();
>>        ci_env.report_failure(ci_env.failure_reason());
>> 
>> Why not use failure_reason?
> 
> Fewer edits?  :)  I’ll fix it.

:-D

> 
>> 
>> src/share/vm/jvmci/jvmciCompiler.cpp:
>> 
>> +      oop failure_message = CompilationRequestResult::failureMessage(result_object);
>> +      if (failure_message != NULL) {
>> +        const char* failure_reason = failure_message != NULL ? java_lang_String::as_utf8_string(failure_message) : "unknown reason”;
>> 
>> failure_message is guaranteed to be non-null.
> 
> Right.  The code evolved a few times but now that test is unnecessary.
> 
>> 
>> +    oop result_object = (oop) result.get_jobject();
>> +    if (result_object != NULL) {
>> 
>> Looks like there is nothing to handle the null case.  Should we?
> 
> I debated on that.  Maybe a Java assert in HotSpotJVMCIRuntime.compileMethod that JVMCICompiler.compileMethod always returns non-null?  I don’t know that there’s anything useful we can in the C++ code if it’s null.

Assert in Java sounds good.  I was thinking about a hard-failure in C++ since it shouldn’t happen.

> 
> tom
> 
>> 
>>> On Jan 19, 2016, at 9:32 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>> 
>>> http://cr.openjdk.java.net/~never/8147432/webrev/index.html <http://cr.openjdk.java.net/~never/8147432/webrev/index.html>
>>> https://bugs.openjdk.java.net/browse/JDK-8147432 <https://bugs.openjdk.java.net/browse/JDK-8147432>
>>> 
>>> Currently JVMCI compiles either produce code or they don’t but nothing is reported for failures.  This adds a new CompilationRequestResult object that can return a human readable message to be included in the normal “COMPILE SKIPPED” style message.  I’ve refactored the printing so it’s shared between compiles.  The result can also include the number of inlined byte codes for use by things like CITimeEach.  Additionally I removed the CompilationToVM.notifyCompilationStatistics as this was apparently a left over.  Tested with specjvm and PrintCompilation which has a few OSR bailouts plus injecting some exceptions to make sure they were reported correctly.
>>> 
>>> tom
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160119/94632a8c/attachment.html>


More information about the hotspot-compiler-dev mailing list