RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
Nils Eliasson
nils.eliasson at oracle.com
Mon Feb 14 10:11:13 UTC 2022
The transformation is equal to having multiple return point:
public int ex1(boolean cond, int first, int second) {
p0 = Allocate(...);
...
p0.x = first;
p0.y = second;
if (cond) {
p1 = call(...); // or allocate
...
p1.x = second;
p1.y = first;
return p1.x - p1.y;
}
return p0.x - p0.y;
}
As long as p1.x and p1.y doesn't float up above any other call or
synchronization point in the '...' section, there are no point at which
concurrent field updates can be visible between the threads. The stores
to p1 can't be elided, but p0 is fair game.
Regards,
Nils
On 2022-02-11 19:01, Vladimir Kozlov wrote:
> We can't do that unless we know that p0 does not escape in call() (we
> do such analysis in EA code already).
> Otherwise there could be concurrent p0's fields updates.
>
> Thanks,
> Vladimir K
>
> On 2/11/22 1:38 AM, Nils Eliasson wrote:
>> This is also useful if only one of the paths are a local allocation.
>> We must just be sure that the original phi actually can be removed.
>>
>> public int ex1(boolean cond, int first, int second) {
>>
>> p0 = call(...)
>>
>> if (cond) {
>> p1 = Allocate(...);
>> ...
>> p1.x = second;
>> p1.y = first;
>> }
>>
>> p = phi(p0, p1) // unused and will be removed
>>
>>
>> return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>> }
>>
>> Regards,
>> Nils
>>
>> On 2022-02-11 05:07, Vladimir Kozlov wrote:
>>> For this simple case we can teach C2's IGVN to split fields loads
>>> through Phi so that phi(p0, p1) is not used and allocations as well.
>>> We can do that because we know that allocations and phi do not escape.
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> p0 = Allocate(...);
>>> ...
>>> p0.x = first;
>>> p0.y = second;
>>>
>>> if (cond) {
>>> p1 = Allocate(...);
>>> ...
>>> p1.x = second;
>>> p1.y = first;
>>> }
>>>
>>> p = phi(p0, p1) // unused and will be removed
>>>
>>>
>>> return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>> }
>>>
>>> Thanks,
>>> Vladimir K
>>
More information about the hotspot-compiler-dev
mailing list