[External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement

[Cesar Soares Lucas]

Hi, Quan Ahn.

I’m currently working on solving allocation merge issue but the next task on my list is to improve EA/SR to be “flow-sensitive” (at least in some case..). So, thank you for sharing your ideas.

Can you please elaborate what each of the fields in the wrapper mean?


Regards,
Cesar

From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Quân Anh Mai <anhmdq at gmail.com>
Date: Friday, April 1, 2022 at 5:39 AM
To: hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
[You don't often get email from anhmdq at gmail.com. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]<http://aka.ms/LearnAboutSenderIdentification.%5d>

Hi,

I would like to present some ideas regarding this topic. To extend the idea
of using a selector, the scalar replacement algorithm may be generalised
for objects to dynamically decide their escape status and act accordingly.

Overall, an object of type T has a wrapper W<T> of the form:

    struct W<T> {
        int selector;
        T* ref;
        T obj;
    }

As a result, a creation site would be transformed:

    T a = new T;
    ->
    wa.selector = 0;
    wa.ref = null;
    wa.obj = 0; // The zero instance of this object has all fields being
zeros

    T a = callSomething();
    ->
    wa.selector = 1;
    wa.ref = callSomething();
    wa.obj = 0;

A use site then would be:

    x = a.x;
    ->
    if (wa.selector == 0) {
        x1 = wa.obj.x;
    } else {
        x2 = wa.ref->x;
    }
    x = phi(x1, x2);

    escape(a);
    ->
    if (wa.selector == 0) {
        ref1 = materialise(wa.obj);
    } else {
        ref2 = wa.ref;
    }
    ref = phi(ref1, ref2);
    wa.selector = 1;
    wa.ref = ref;
    escape(ref);

This can be thought of as a more generalised version of the current escape
analysis, since if the object is known to not escape, its corresponding
selector value would be always 0, and constant propagation and dead code
elimination would remove the redundant selector and ref nodes. On the other
hand, if an object is known to escape, its selector value would be always
1, and there would be no additional overhead checking for the selector.

Regards,
Quan Anh