RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal

[Dean Long]

Thanks Vladimir!

dl

On 11/22/19 6:54 PM, Vladimir Kozlov wrote:
> Got it. My thinking was in reverse ;)
>
> Changes are good.
>
> Vladimir
>
> On 11/22/19 6:47 PM, Dean Long wrote:
>> On 11/22/19 6:37 PM, Vladimir Kozlov wrote:
>>> Hmm. I assumed that Graal should have GCs list which is subset of 
>>> GCs in Hotspot. But it could be not true since GraalVM have to run 
>>> with JDK 8.
>>>
>>> May be we should bailout AOT compilation if GC is unknown in Hotspot 
>>> instead of recording in library enum 'def' from Graal which does not 
>>> match enum in HotSpot. And check for GC early before we start 
>>> collecting classes to compile.
>>>
>>
>> Graal uses the HotSpot flags to determine which GC is being used, so 
>> there is no way for AOT to store a GC that the underlying HotSpot 
>> doesn't know about.  The default fall-back of ordinal() + 1 is only 
>> for pre-JDK14 which doesn't have the CollectedHeap GC constants 
>> exported to JVMCI.  We could get rid of that if we backport the 
>> vmStructs_jvmci.cpp change to all the JDK versions that Graal supports.
>>
>> There is a separate issue, if you try to use a GC that JVMCI/Graal 
>> doesn't support:
>>
>>   % jaotc -J-XX:+UseZGC java.lang.String
>>
>> JVMCI Compiler does not support selected GC: z gc
>>
>> dl
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/22/19 5:55 PM, Dean Long wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8234432
>>>> http://cr.openjdk.java.net/~dlong/8234432/webrev/
>>>>
>>>> The change fixes AOT after CMS was removed.  Previously we relied 
>>>> to a Graal enum matching a JDK enum, but now we map from one to the 
>>>> other.
>>>>
>>>> dl
>>