Request for reviews (L): 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob

[Vladimir Kozlov]

Looks good.

Vladimir

Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/6934494/webrev.01/
> 
> Passing a null pointer to an InvokeDynamic function call, like:
> 
>   MethodHandle mh = null;
>   InvokeDynamic.funcall(mh);
> 
> should lead to a NullPointerException. But with current HotSpot we
> hit a guarantee:
> 
>   #  Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448
>   #  Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)")
> 
> The reason for this is that the MethodHandles adapters are generated
> into the same CodeBlob as other code stubs which do not throw
> exceptions. The only blob that can throw exceptions is the C2I/I2C
> adapter blob, and this what the guarantee says.
> 
> The fix is to generate MethodHandles adapters into their own CodeBlob
> and add a check into the guarantee for that blob.
> 
> src/cpu/sparc/vm/stubRoutines_sparc.hpp
> src/cpu/x86/vm/stubGenerator_x86_32.cpp
> src/cpu/x86/vm/stubGenerator_x86_64.cpp
> src/cpu/x86/vm/stubRoutines_x86_32.hpp
> src/cpu/x86/vm/stubRoutines_x86_64.hpp
> src/share/vm/code/codeBlob.cpp
> src/share/vm/code/codeBlob.hpp
> src/share/vm/includeDB_core
> src/share/vm/prims/methodHandles.cpp
> src/share/vm/prims/methodHandles.hpp
> src/share/vm/runtime/init.cpp
> src/share/vm/runtime/sharedRuntime.cpp
> src/share/vm/runtime/sharedRuntime.hpp
>