RFR: 8302850: Implement C1 clone intrinsic that reuses arraycopy code for primitive arrays [v7]

Galder Zamarreño galder at openjdk.org
Wed Apr 3 08:43:10 UTC 2024


On Thu, 28 Mar 2024 02:43:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> You're right about holder_known, but why do you need to check for _clone specifically at line 2137?  If there is logic missing that prevents an inlining attempt then I think it should be fixed first, rather than in a followup.
>> 
>> And I see that you need to do a receiver type check to allow only primitive arrays.  Can you do that in append_alloc_array_copy, and bailout if not successful?  The logic in build_graph_for_intrinsic would need to change slightly to support this.
>
> I was able to remove the clone-specific logic in invoke() in two parts:
> 
> 1. fix the type_is_exact logic to allow array receiver
> 2. move primitive array receiver check into append_alloc_array_copy

> You're right about holder_known, but why do you need to check for _clone specifically at line 2137? If there is logic missing that prevents an inlining attempt then I think it should be fixed first, rather than in a followup.

I added that check because none of the conditions in that `if` statement satisfied the situations in which `clone` calls are optimized. For the example I gave above, `code == Bytecodes::_invokevirtual` is true and `target->is_final_method()` is false. So that's why I added `clone` specifically.

> I was able to remove the clone-specific logic in invoke() in two parts:
> 
> 1. fix the type_is_exact logic to allow array receiver
> 2. move primitive array receiver check into append_alloc_array_copy

Great! I assume you also solved the clone check in line 2137?

How do we add your work on top of mine? Do I cherry pick the commit(s) from a branch of yours? Or some other way?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17667#discussion_r1549258389


More information about the hotspot-compiler-dev mailing list