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