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.


> I've changed WB_AotLibrariesCount to use AOTLoader::heaps_count, retested the fix locally, it works fine. testing it in mach5.



> 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