DMH to fields, casts and type profiling <was> Re:  RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
paul.sandoz at oracle.com
Fri Aug 29 15:10:15 UTC 2014
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.
>> [*] 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?
More information about the core-libs-dev