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 Aug 29, 2014, at 12:45 AM, John Rose <john.r.rose at oracle.com> wrote:

> On Aug 28, 2014, at 7:38 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 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
> 
> Here's something to try first:  Force a profile point before Class.cast, even without Roland's enhancements.
> You should be able to type-profile "x" by inserting "push x; checkcast java/lang/Object; pop".
> See last line of https://wiki.openjdk.java.net/display/HotSpot/MethodData
> 

Thanks, that's a neat trick. I will play around with that.

Some thoughts triggered (now i am a supposedly little wiser... perhaps :-)).

I could imagine things would get polluted fairly quickly within the compiled & shared DHM LFs for field access (same for VHs), plus cast-wise only the value is operated on and not the receiver. In general presumably what matters most is the type profile from the call site that would flow down to the LF?

But... what would there be in compiled DHM LFs for field access that they would require profiling so that generated code would be different for accessing a field of Bar rather than a field of Foo? since it all boils down to Unsafe calls, or are there some subtle details hidden within the Unsafe intrinsics? or perhaps a lack of that can result in some odd effects?

Paul.
-------------- 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/20140829/952765cb/signature.asc>