RFR: 8152634: generalize exception throwing routines in JVMCIRuntime

[Christian Thalinger]

> On Mar 25, 2016, at 2:25 AM, Roland Schatz <roland.schatz at oracle.com> wrote:
> 
> 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.

Thanks.

> 
> 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/

Looks good.  Do you need me to push this?

> 
> - 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
>