Passive Materialization

Example1_Point.java

import java.lang.Math; 

class Example1_Point {
    static class Point {
        double x; 
        double y; 

        public Point(double x, double y) {
            this.x = x; 
            this.y = y; 
        }

        // distance from zero 
        public double length() {
            return Math.sqrt(x * x +  y * y);
        }
    }

    private static Point _cache;

    public double test(boolean cond, double x, double y) {
        Point pt = new Point(x, y);
        pt.x = 3.0d;

        if (cond) {
            _cache = pt; // materialize here. pt1 = Mat(pt)
        } 
        // pt2 = phi(pt, pt1)
        return pt.length();
    }

    public static void main(String[] args)  {
        var kase = new Example1_Point();

        long iterations = 0;
        try {
            while (true) {
                kase.test(0 == (iterations & 0xf), 2.0d, 1.0d);
                iterations++;
            }
        } finally {
            System.err.println("Epsilon Test: " + iterations);
        }
    }
}

Statement: PEA without passive materialization doesn't duplicate the allocation when C2 applies to JDK-8287061

Prove:
o denotes the original object: o0 = Allocate(Class).

1. if o0 never encounters an escaping point, PEA doesn't change o0. no duplication.

2. if o0 encounters an escaping point in a branch, PEA materializes it o1 = Mat(Obj). o1 is Escape

   • o0 is dead before reaching to a merging point, C2 parse doesn't generate phi node for it. o0 is NonEscape and no phi node consumes it. Current C2 guarantees to perform scalar replacement for it. o0 is gone, so no duplication in the path that PEA materializes the object.
   • o0 is live at the merging point. C2 parse creates a new revision of it due to SSA property. o2 = PHI(o0, o1). o0 is NonEscape and NSR in C2 EA. JDK-8287061 marks o2 as a reducible phi and conducts scalar replacement for o0. no duplication.

It's natural to extend this proof to multiple branches. As long as we retain SSA property, we can prove that the original allocation is either dead or get scalar replaced if PEA does materialize the object.

JDK-8287061 determines whether o2 is a reducible phi based on both inputs and outputs. it's possible that JDK-8287061 opts out phi reduction because the consumer of o2 is not recognizable. I think this problem is amendable. we can extend it to include all possible codeshape in the future.