RFR: 8339526: C2: store incorrectly removed for clone() transformed to series of loads/stores [v3]
Roland Westrelin
roland at openjdk.org
Tue Oct 14 11:41:14 UTC 2025
On Mon, 13 Oct 2025 15:51:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
> > inlined2() calls clone() for an object loaded from field field
> > that has inexact type A at parse time. The intrinsic for clone()
> > inserts an Allocate and an ArrayCopy nodes. When igvn runs, the
> > load of field is optimized out because it reads back a newly
> > allocated B written to field in the same method. ArrayCopy can
> > now be optimized because the type of its src input is known. The
> > type of its dest input is the CheckCastPP from the allocation of
> > the cloned object created at parse time. That one has type A. A
> > series of Loads/Stores are created to copy the fields of class B
> > from src (of type B) to dest of (type A).
>
> I'm still struggling to understand. I wonder if the test can be further simplified to make the case more clear.
>
> Am I understanding right, that we essentially this:
>
> ```
> field = new B(42, 42, 42);
> A a = field;
> return (A)a.clone();
> ```
>
> What should the result of that be? An `A` or a `B`? I think we should be getting a `B`, right? So why is the `dest` of the `ArrayCopy` an `A`? Is that even correct?
The type of `a` is initially `A` and inexact (that is `A` or some subclass). The type of the result of the clone is the same. The type of `a` is then refined to `B` exact (so only class `B`).
`A` inexact is correct as dest for `ArrayCopy`. `B` exact is correct too. `A` exact would be incorrect.
>
> > The fix I propose is to skip ArrayCopyNode::try_clone_instance()
> > when src and dest classes don't match as this seems like a rare
> > enough corner case.
>
> How do you know that this is a rare case? Did you do some kind of profiling / benchmarking?
Instead of the test that I propose here, I initially added an assert. I ran quite a bit of testing with it (ctw + jtreg) and, if I remember correctly, there was a single failure with one of compiler jtreg tests.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27604#issuecomment-3401367577
More information about the hotspot-compiler-dev
mailing list