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

[John Rose]

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

— John