DMH to fields, casts and type profiling <was> Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

[Paul Sandoz]

On Jul 8, 2014, at 9:09 PM, John Rose <john.r.rose at oracle.com> 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.
> 

I had some enlightening discussions with Roland on this.

It seems quite tricky to solve in general the removal of the null check due to the aggressive nature in which the null branch is reduce to a trap, but IIUC may be possible to turn Class.cast into an intrinsic to handle the specific case (although that seems costly).

I was labouring under the misapprehension that an explicit Class.cast was a profiling point but now i realize it's only certain byte codes (like checkcast/invokehandle). Nothing specific to the DHM access logic showed up with regards to type profiling when analysing the MethodData output from some simple examples [*]. Therefore i presume it's more likely to be the first or third reason you state.

So i propose to proceed with the experiment with a patch to replace the casts with asserts in the accessor logic and run that through the usual tests.

Paul.


[*] Also i have so far failed to concoct a simple example for VarHandles where i can trigger profile pollution and failed inlining
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140828/466a558a/signature-0001.asc>