[9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code

[Vladimir Kozlov]

On 10/22/14 11:01 PM, John Rose wrote:
> On Oct 22, 2014, at 10:09 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>
>> Intrinsic is not enough.

It was only part of my statement. I suggested to always inline Class.cast() by changes in bytecodeInfo.cpp. As result 
Class.cast() could be used in castReference() without manual inlining.

>
> Would it be possible to give the new intrinsic wider coverage, to replace the logic in a majority of places it is used?

I need a translation for this suggestion. The intrinsic will be used in all places where Class.cast() is called.
If it does not fold code statically Roland's speculative type code fro arguments will generate type check based on 
profiling and cast. But it does that only if profiled type is unique.

Or you are suggesting a full blown intrinsic which executes Class.cast() code for all cases and not only when klasses 
are matched statically?

>
> The logic in GraphKit::gen_checkcast is pretty sophisticated, and it's all there for a reason.  What would stop us from
> using it more fully?

Please, explain. gen_instanceof() does not use gen_checkcast().

Are you talking about last cast code: "return (T) obj;"?

Or you are talking about folding whole next expression?:

   void testLoopOne(String s) {
     ssink = (String) MH_CAST.invokeExact(String.class, s);

Thanks,
Vladimir

>
> Some of the sophistication depends on profiling of the cast and aastore instructions, crucially with null, but perhaps
> we can cover that need with Roland's argument profiling work.
>
> — John