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