[9] RFR(S) 8172054: Aot tests should include Java assertions into AOT compiled code

[Igor Veresov]

This seems to be too conservative:
+   if (_config->_omitAssertions && (JavaAssertions::userClassDefault() ||
+                                    JavaAssertions::systemClassDefault())) {
+     handle_config_error("Shared file %s error: Java assertions are omitted in compiled code, but they are enabled for this execution.", _name);
+   }

For example it would mean that if the user runs with java.base AOT’ed and enables -ea it would render all of the java.base aot code unusable. We need the classloader to be able to differentiate the effect of -ea vs -esa. And we don’t have it at this point. Perhaps this check could be moved to load_klass_data() to short-circuit the check without allocating the C string name? That should be a small enough check… What do you think?
 
 if (_lib->config()->_omitAssertions) {
   Handle kl(kh->class_loader());
   if (kl() == NULL && JavaAssertions::systemClassDefault()) ||
      (kl() != NULL && JavaAssertions::userClassDefault()) ||
      JavaAssertions::enabled(kh->name()->as_C_string(), kl() == NULL))) {
      log_trace(aot, class, load)("class %s in %s does not have java assertions in compiled code, but assertions are enabled for this execution.", kh->internal_name(), _lib->name());
      sweep_dependent_methods(klass_data);
      return false;
   }
}

igor

> On Jan 3, 2017, at 5:40 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~kvn/8172054/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8172054
> 
> AOT tests failed when run with -esa or -ea flags after JDK-8168792 changes which requires to have Java assertions in AOT compiled code when these flags are specified.
> 
> The fix is always generate AOT code with Java assertions for AOT tests by adding jaotc flag --compile-with-assertions.
> 
> Also trace log for such failure and additional check when AOT library is loaded.
> 
> Tested with Hotspot jtreg tests.
> 
> Thanks,
> Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170103/746f6a32/attachment-0001.html>