RFR: 8198571: [JVMCI] must not install wide vector code unless runtime supports it

[dean.long at oracle.com]

Should we also bail out if

HotSpotReferenceMap::maxRegisterSize(reference_map)) > MaxVectorSize

or

is_wide_vector(HotSpotReferenceMap::maxRegisterSize(reference_map))) && 
!is_wide_vector(MaxVectorSize)

instead of determining based only on the existence of the safepoint 
blob?  Otherwise it looks good.

dl

On 3/2/18 8:56 AM, Doug Simon wrote:
> Thanks Vladimir.
>
> Can I get another review please?
>
> -Doug
>
>> On 23 Feb 2018, at 21:14, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Okay. Then it is good.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/23/18 11:59 AM, Doug Simon wrote:
>>> Yes. We have a separate fix for Graal that does what you propose. This is just a last bit of defense to prevent a VM crash in case the bug creeps back into Graal (or any other JVMCI compiler).
>>> Sent from my iPhone
>>>> On 23 Feb 2018, at 8:54 pm, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> Are you planning changes to check MaxVectorSize value when vectors are generated by Graal?
>>>> Throwing exception during code installation is very late and expensive (you have to throw out all methods with vectors after spending CPUs to compile them).
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>> On 2/23/18 8:57 AM, Doug Simon wrote:
>>>>> As shown in https://github.com/oracle/graal/issues/303, a bug in a JVMCI compiler can result in vector code being installed even if the runtime doesn't support it. JVMCI should be defensive and raise an exception in this case.
>>>>> https://bugs.openjdk.java.net/browse/JDK-8198571
>>>>> http://cr.openjdk.java.net/~dnsimon/8198571/
>>>>> -Doug