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

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


+      failure_reason = ci_env.failure_reason();
+      retry_message = ci_env.retry_message();

Why not use failure_reason?


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

+    oop result_object = (oop) result.get_jobject();
+    if (result_object != NULL) {

Looks like there is nothing to handle the null case.  Should we?

> On Jan 19, 2016, at 9:32 AM, Tom Rodriguez <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/18340df4/attachment-0001.html>

More information about the hotspot-compiler-dev mailing list