On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote: > On 4/1/14 7:29 PM, Paul Sandoz wrote: >> >> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> >> wrote: >> >>> Paul, >>> >>> Unfortunately, additional profiling doesn't work for Accessor.checkCast >>> case. The problem is Accessor.checkCast is called from multiple places, so >>> type profile is very likely to be polluted. And it kills the benefits. >>> >>
Though... i wonder why the accessor cast is any more or less unique than casts performed for lambda form. >> So is there any point in doing such a cast in this case? >> >> The type performing the cast is the field type declared as a parameter in >> the MethodType of the MethodHandle and also held by the Accessor. >> >> IIUC the Invokers.checkExactType should ensure no "unsavoury" instances of >> the wrong type gets through? (the holder instance is only checked for null, >> via checkBase). > I don't see any point in doing profiling for this particular case. Such shape > should be well optimized by JIT if it sees that an instance of Accessor is a > constant. As I understand, it should be the case for most of the usage > scenarios. > Perhaps conservatively we could retain the existing casts if PROFILE > 0. I can provide a patch if that helps? Also, just double checking, i would presume the same would be applicable for MH setter/getters to arrays as per your patch improving those? >>> Regarding redundant null check, do you have a test case so I can play with >>> it myself? >>> >> >> I will send something to you later today or tomorrow. >> Still plan to send you something today :-) but later on... Paul.
