RFR(S) [12] : 8216180 : [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Jan 24 00:16:29 UTC 2019
On 1/23/19 4:07 PM, Igor Ignatyev wrote:
> UseAOT will be changed to false, only if UseAOT wasn't specified in the command line, so we can't use it reliably to determine if there are any loaded AOT libraries.
Okay.
>
> I've changed WB_AotLibrariesCount to use AOTLoader::heaps_count, retested the fix locally, it works fine. testing it in mach5.
Good.
Thanks,
Vladimir
>
> Thanks,
> -- Igor
>
>> On Jan 23, 2019, at 2:51 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> No, heaps_count(). Some libraries could be invalid (AOT compilation config was different, for example) and are not used:
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/e3ed96060992/src/hotspot/share/aot/aotLoader.cpp#l190
>>
>> May be we should just check UseAOT flag? If no AOT libraries are loaded ot they are invalid UseAOT will be set to false.
>>
>> Vladimir
>>
>> On 1/23/19 2:44 PM, Igor Ignatyev wrote:
>>> 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
>>>>>>
>
More information about the hotspot-compiler-dev
mailing list