RFR: 8289943: Simplify some object allocation merges [v6]
Cesar Soares Lucas
cslucas at openjdk.org
Wed Sep 28 00:40:15 UTC 2022
On Fri, 2 Sep 2022 16:01:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>> @vnkozlov - Thank you for clarifying that. I've been playing with lifting the restriction and I actually found a corner case:
>>
>>
>> public static Class test(boolean c1, boolean c2, boolean c3, int x, int y, int w, int z) {
>> Animal s = new Dog(x, y, z);
>>
>> if (c1) {
>> s = new Cat("Fisker");
>> }
>>
>> Unloaded u = new Unloaded(); // assumes this is converted to a uncommon_trap(unloaded, reinterpret)
>>
>> return s.getClass();
>> }
>>
>>
>> It seems that when merging allocations of different subtypes I'll need to add a special `Phi` node merging the `Klass` of the input allocations and assign the output of that `Phi` to `SafepointScalarReplacedNode`. If I don't do that, the method above will return Animal.class instead of `Dog.class` or `Cat.class`. I'm wondering if I'll actually have to do the same for the Header/Mark word of the input allocations.
>
> @JohnTortugo Yes, you would need to construct Phi when you replace RAM with `SafePointScalarObjectNode`. Hmm, may be you would need to construct Phi in other cases too (getClass intrinsic).
>
> Add cases when class is loaded from argument for allocation: `Unsafe.allocateInstance()` and `Object.clone()` to test class Load instead of simple constant on some paths of such Phi.
>
> Why you need Phi for mark word? For identity check (hashCode/identityHashCode intrinsics)?
Hi @vnkozlov - I pushed some changes that I think address the comments that you made. I also had to add another constraint to reducing the allocations: for now, I won't be reducing merges of SR and NSR allocations. I'll definitely work on that in a subsequent patch.
Thank you again for reviewing and I'd appreciate it very much if you could check if the patch doesn't break any of your tests.
-------------
PR: https://git.openjdk.org/jdk/pull/9073
More information about the hotspot-compiler-dev
mailing list