[9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

[Remi Forax]

In my opinion, there are two issues here,
the first one is the extra Class.cast which is inserted and as John said 
it should be interesting to try to remove them.
the second one is why when there is a Class.cast, the cast is 
effectively removed but a null check stay.

regards,
Rémi

On 07/08/2014 09:09 PM, John Rose wrote:
> Regarding the extra cast in accessor logic that Paul picked up on: 
>  That may be a left-over from obsolete versions of the code, or it may 
> cover for some corner cases, or it could possibly be a re-assurance 
> to the JIT.
>
> Generally speaking, we lean heavily on MH types to guarantee a priori 
> correctness of argument types.  Paul is right that the stored value 
> type is already validated and (except for corner cases we may be 
> neglecting) does not need re-validation via a cast.
>
> It might be an interesting experiment to replace the cast with an assert.
>
> Sometimes corner cases bite you.  For example, an array store check is 
> necessary, if the type is an interface, because interfaces are weakly 
> checked all the way up to aastore or invokeinterface.
>
> Sometimes the JIT cannot see the type assurances implicit in a MH 
> type, and so (when choosing internal MH code shapes) we must choose 
> between handing the JIT code that is not locally verifiable, or adding 
> "reassurance" casts to repair the local verifiability of the code.  If 
> the JIT thinks it sees badly-typed code, it might bail out.Note that 
> "locality" of verifiability is a fluid concept, depending sometime on 
> vagaries of inlining decisions.  This is the reason for some awkward 
> looking "belt and suspenders" MH internals, such as the free use of 
> casts in LF bytecode rendering.
>
> Usually, redundant type verifications (including casts and signatures 
> of incoming arguments) are eliminated, but they can cause (as noted) 
> an extra null check.  In theory, that should fold up also, if the null 
> value is replaced by "another" null, as (p == null ? null : 
> identityFunction(p)).
>
> --- John
>
> On Jul 8, 2014, at 3:09 AM, Vladimir Ivanov 
> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> 
> wrote:
>
>> I'd like to revive this review thread.
>>
>> Updated version:
>> http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Evlivanov/8037209/webrev.04/>
>>
>> Paul, I'd like to address your case (if possible) separately. Right 
>> now, I don't see any way to avoid null check you see with your tests.
>
>
> On Apr 1, 2014, at 8:29 AM, Paul Sandoz <paul.sandoz at oracle.com 
> <mailto:paul.sandoz at oracle.com>> wrote:
>
>> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov 
>> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> 
>> wrote:
>>
>>> Paul,
>>>
>>> Unfortunately, additional profiling doesn't work for 
>>> Accessor.checkCast case. The problem is Accessor.checkCast is called 
>>> from multiple places, so type profile is very likely to be polluted. 
>>> And it kills the benefits.
>>>
>>
>> So is there any point in doing such a cast in this case?
>>
>> The type performing the cast is the field type declared as a 
>> parameter in the MethodType of the MethodHandle and also held by the 
>> Accessor.
>>
>> IIUC the Invokers.checkExactType should ensure no "unsavoury" 
>> instances of the wrong type gets through? (the holder instance is 
>> only checked for null, via checkBase).
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140708/a5978898/attachment-0001.html>