RFR(S) [12] : 8216180 : [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled

[Igor Ignatyev]

you meant libraries_count, right?

-- Igor

> On Jan 23, 2019, at 2:41 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> It should be AOTLoader::heaps_count(). Otherwise it is very good.
> 
> Thanks,
> Vladimir
> 
> On 1/23/19 2:13 PM, Igor Ignatyev wrote:
>> Vladimir,
>> I gave it a bit more thoughts, and am inclining to agree that replying on env. variables is indeed fragile. so I've decided to go w/ a new WB method --http://cr.openjdk.java.net/~iignatyev//8216180/webrev.01/index.html
>> (testing is in-progress)
>> Thanks,
>> -- Igor
>>> On Jan 23, 2019, at 10:34 AM, Igor Ignatyev <igor.ignatyev at oracle.com <mailto:igor.ignatyev at oracle.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Jan 23, 2019, at 10:28 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>> 
>>>> I assume tests don't use -XX:AOTLibrary= flag but load them from default location in JDK. Right?
>>> that's correct, the runs where the test fails used libraries from the default location.
>>> 
>>>> Can we instead skip such tests if any AOT library is loaded? We can check it with PrintAOT or new ouptu or new WB API.
>>>> Relying on env variable is not robust I think.
>>> 
>>> these env variables are part of run-test "official" contract, so I believe it's safe to use them. the only problem I see w/ such approach is runs w/ jdk-images which include AOT'ed modules in them, but there are no such images, and w/ current state of AOT, they aren't actually possible however if you have strong objections, I can look into other ways to retrieve this information.
>>> 
>>> -- Igor
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 1/23/19 9:36 AM, Igor Ignatyev wrote:
>>>>> http://cr.openjdk.java.net/~iignatyev//8216180/webrev.00/index.html
>>>>>> 32 lines changed: 32 ins; 0 del; 0 mod;
>>>>> Hi all,
>>>>> could you please review this small patch which exclude TestMulAdd test from execution if java.base is AOT'ed compiled?
>>>>> the test disables some intrinsics, and if it's run w/ AOT'ed java.base there these intrinsics are enabled (which is the most common, if not the only, case) we get crash. the fix introduces new @requires value -- vm.aot.modules which contains comma-separated list of AOT'ed modules and use it to skip this test if java.base is one of them.
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8216180/webrev.00/index.html
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8216180
>>>>> testing: compiler/intrinsics/bigInteger tests on linux-x64 w/ JTREG=AOT_MODULES=java.base, TEST_OPTS_AOT_MODULES=java.base and w/o any extra make args
>>>>> Thanks,
>>>>> -- Igor
>>>