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

Quân Anh Mai anhmdq at gmail.com
Fri Apr 1 12:37:50 UTC 2022


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


More information about the hotspot-compiler-dev mailing list