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