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

[Vladimir Kozlov]

On 1/3/17 8:33 PM, Igor Veresov wrote:
> 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

Okay, make sense. I will remove that check.

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

No, it would be duplication - JavaAssertions::enabled() already checks systemClassDefault() and userClassDefault().

Thanks,
Vladimir

>
>  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 <mailto: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
>