RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes

[Doug Simon]

Note that Graal has already decoupled itself from JVMCIError (http://hg.openjdk.java.net/graal/graal-core/rev/53fb0bdfd127) so we could leave JVMCIError around. However, we’re trying to do a final round of JVMCI reduction and this is a good candidate, especially since once we remove UnsafeUtil, we are left with a project (jdk.vm.ci.common) that contains exactly one class.

-Doug

> On 11 May 2016, at 23:21, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 11 May 2016, at 23:09, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On 11 May 2016, at 22:54, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> 
>>>> On May 11, 2016, at 10:19 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>> 
>>>> Please review this change which removes a couple of classes which do not need to be in JVMCI.
>>>> 
>>>> I’ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug.
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8156759
>>> 
>>> The JIRA issue states:
>>> 
>>> "Only Graal uses the context functionality of JVMCIError so it will move it Graal.”
>>> 
>>> But there is more value to JVMCIError than just the context functionality.  Having a separate JVMCI exception class can be useful when catching exceptions.
>> 
>> Grepping through other jdk code, I see 587 instances of ‘new InternalError’ so I’d say it’s an appropriate choice. The stack trace is the most useful part of the errors thrown from within JVMCI and they aren’t going to change. What other uses do you have in mind?
> 
> BTW, I have not seen any uses of 'catch (JVMCIError e) {...}’.
> 
> -Doug