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

[Vladimir Kozlov]

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
>