On Aug 28, 2014, at 7:38 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
> On Jul 8, 2014, at 9:09 PM, John Rose <john.r.r...@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
