[15] RFR: 8237894: CTW: C1 compilation fails with assert(x->type()->tag() == f->type()->tag()) failed: should have same type
Jamsheed C M
jamsheed.c.m at oracle.com
Thu Feb 13 10:22:44 UTC 2020
so, are you ok with patch as is, or should i attempt hashing type as
well, as you said it will be still awkward for subtypes.
Best regards,
Jamsheed
On 13/02/2020 02:23, Aleksey Shipilev wrote:
> On 2/12/20 1:48 PM, Jamsheed C M wrote:
>>> But now I have second thoughts. Do we foresee any performance troubles from not GVN'ing null
>>> constants in C1, though?
>> i am not sure about all use case, i think only static finals are
>> affected, service loader based initialization is an use case probably,
>> but it is interface.
> Ah, right. And since those are known nulls, access through them would also yield immediate NPE. I am
> struggling to come up with a plausible counter-example that involves using the
> known-null-object/array without tanking performance even before this patch, hm.
>
>> these error never occurred in any other testing before , so use cases
>> were limited ?
> This, unfortunately, does not tell us much. It looks like two constant nulls of different types meet
> and that is how assert fails. But if we exclude all constant nulls, are we breaking the case where
> two constant nulls of the same type meet. This would not fail the assert, yet have the effects on
> performance. But as said above, this is probably not a problem here.
>
More information about the hotspot-compiler-dev
mailing list