RFR(XS): 8155735: use strings instead of Symbol* in JVMCI exception stubs

[Christian Thalinger]

> On May 2, 2016, at 3:46 AM, Roland Schatz <roland.schatz at oracle.com> wrote:
> 
> On 04/29/2016 09:49 PM, Tom Rodriguez wrote:
>> Sorry I was looking at the comment below lookup instead of above it.  It’s very odd that both of these exist though and new_symbol just forwards to lookup.
>> 
>>   static Symbol* new_symbol(const char* utf8_buffer, int length, TRAPS) {
>>   static Symbol* lookup(const char* name, int len, TRAPS);
>> 
>> I do think you want the TempNewSymbol though.
> You're right. I misunderstood the semantics of lookup/new_symbol, they actually both do the same thing.
> 
> Normally, the symbol we're looking up is a class name, so the lookup should never fail anyway. But we should still not leak anything if there is a wrong string passed in.
> 
> New webrev, using TempNewSymbol:
> http://cr.openjdk.java.net/~rschatz/JDK-8155735/webrev.01/
> 
> I've also included an exception check after the symbol lookup, just to be sure.

Use CHECK instead of HAS_PENDING_EXCEPTION.  Otherwise this looks good.

> 
> - Roland
>> 
>>>> and let new_exception throw an exception if the class named by symbol doesn’t exist.
>>> throw_and_post_jvmti_exception will throw a `NoClassDefFoundError` when the exception class doesn't exist.
>>> 
>>> 
>>> Just to be sure, I tested this using graal. Temporarily passing in a wrong class name into the stub results in:
>>>> java.lang.NoClassDefFoundError: bla/java/lang/NullPointerException
>>>>        at com.oracle.graal.replacements.test.CompiledNullPointerExceptionTest.testSnippet(CompiledNullPointerExceptionTest.java:93)
>>>>        at jdk.vm.ci.hotspot.CompilerToVM.executeInstalledCode(Native Method)
>>>>        at jdk.vm.ci.hotspot.HotSpotNmethod.executeVarargs(HotSpotNmethod.java:100)
>>>>        at com.oracle.graal.compiler.test.GraalCompilerTest.executeActual(GraalCompilerTest.java:578)
>>>> […]
>> Thanks for checking.
>> 
>> tom
>> 
>>> 
>>> - Roland
>>> 
>