RFR: 8302850: Implement C1 clone intrinsic that reuses arraycopy code for primitive arrays [v6]
Galder Zamarreño
galder at openjdk.org
Wed Mar 20 10:00:29 UTC 2024
On Fri, 15 Mar 2024 18:56:46 GMT, Dean Long <dlong at openjdk.org> wrote:
> OK, I missed the is_intrinsic_supported change. The platform-specific changes should probably have a comment saying they are for clone support.
That's fine for me, but the platform-specific changes are a bit spread around. Anywhere in particular you'd want the comment(s) to go in? Or shall the comments be added in all platform specific changes?
> Also, I was hoping there was a way to minimize platform-specific changes, maybe by handing the force_reexecute inheritance in state_for()....
I'm not sure exactly what you mean, but let me try to explain the `x->state_before()` bit. So I guess you're referring to this piece of logic:
CodeEmitInfo* info = nullptr;
if (x->state_before() != nullptr && x->state_before()->force_reexecute()) {
info = state_for(x, x->state_before());
info->set_force_reexecute();
} else {
info = state_for(x, x->state());
}
This code was added to deal with SEGV failures coming out of `compiler/interpreter/Test6833129.clone_and_verify`, which is configure to stress deoptimizations. In `append_alloc_array_copy`, I construct `NewTypeArray` and the array_copy `Intrinsic` both with `state_before` so that if any deoptimizations happen at either stage, re-execution happen from the point before clone was called.
I guess I can move the code up to `LIRGenerator::state_for` and if the intrinsic is either array copy or new type array, apply that logic, is that what you are after?
> ... putting the state in x->state() instead of x->state_before()
Hmmm, you mean this instead?
CodeEmitInfo* info = nullptr;
if (x->state_before() != nullptr && x->state_before()->force_reexecute()) {
info = state_for(x, x->state());
info->set_force_reexecute();
} else {
info = state_for(x, x->state());
}
Granted that it could be tidied but not sure I understand how state can work here. Before this change both new type array and array copy called `CodeEmitInfo* info = state_for(x, x->state());` which didn't seem to be enough to be able to go back to re-executing bytecode before clone was called. It seemed to leave things in a half-done state when deoptimizations happened while clone's intrinsic was doing either a new type array or array copy.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17667#issuecomment-2009168412
More information about the hotspot-compiler-dev
mailing list