RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
paul.sandoz at oracle.com
Wed Apr 2 14:16:21 UTC 2014
On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov <vladimir.x.ivanov at 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.ivanov at oracle.com> wrote:
>>> 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...
More information about the core-libs-dev