RFR: 8152634: generalize exception throwing routines in JVMCIRuntime

[Roland Schatz]

On 03/24/2016 07:12 PM, Christian Thalinger wrote:
> I’ve mentioned this before internally but I would like to keep HotSpotVmSymbols.  The reason is Symbols are organized in a SymbolTable and lookup is complicated but vmSymbols is an array which can be indexed.
>
> HotSpotSymbol.symbolAt(int index) is very confusing.
Ok, restored.

I also needed to rebase it on the current tip, since there was a 
conflicting change in the meantime.
The new version of generate_class_cast_message takes the Klass* 
directly, instead of the name, and it doesn't take an optional string 
argument anymore.

Updated webrev:
http://cr.openjdk.java.net/~rschatz/JDK-8152634/webrev.01/

- Roland
>
>> On Mar 24, 2016, at 3:30 AM, Roland Schatz <roland.schatz at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the following changes:
>> http://cr.openjdk.java.net/~rschatz/JDK-8152634/webrev.00/
>>
>> This change directly exposes `throw_and_post_jvmti_exception` for JVMCI compilers, instead of the two hardcoded routines for null and index out of bounds.
>> That way, the compiler can generate its own stubs for arbitrary exceptions, or even embed the exception construction code inline in a method.
>>
>> There are still two special case functions exported, for the exceptions that want to use `Klass::external_name()` in their message. This method is not easy to call from JVMCI compiled code because it uses resource allocation.
>>
>> Since `throw_and_post_jvmti_exception` has a Symbol* argument, we also need to add support for dealing with Symbol* pointers to the JVMCI interface. That's what most of the changes in this patch are about. This is using the same mechanisms that are already in place for Klass* and Method* pointers.
>>
>> Thanks,
>> Roland