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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jan 23 22:51:19 UTC 2019


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