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

[Boris Ulasevich]

On Thu, 18 Apr 2024 09:11:40 GMT, Galder Zamarreño <galder at openjdk.org> wrote:

>> Adding C1 intrinsic for primitive array clone invocations for aarch64 and x86 architectures.
>> 
>> The intrinsic includes a change to avoid zeroing the newly allocated array because its contents are copied over within the same intrinsic with arraycopy. This means that the performance of primitive array clone exceeds that of primitive array copy. As an example, here are the microbenchmark results on darwin/aarch64:
>> 
>> 
>> $ make test TEST="micro:java.lang.ArrayClone" MICRO="JAVA_OPTIONS=-XX:TieredStopAtLevel=1"
>> Benchmark                 (size)  Mode  Cnt    Score    Error  Units
>> ArrayClone.byteArraycopy       0  avgt   15    3.476 ?  0.018  ns/op
>> ArrayClone.byteArraycopy      10  avgt   15    3.740 ?  0.017  ns/op
>> ArrayClone.byteArraycopy     100  avgt   15    7.124 ?  0.010  ns/op
>> ArrayClone.byteArraycopy    1000  avgt   15   39.301 ?  0.106  ns/op
>> ArrayClone.byteClone           0  avgt   15    3.478 ?  0.008  ns/op
>> ArrayClone.byteClone          10  avgt   15    3.562 ?  0.007  ns/op
>> ArrayClone.byteClone         100  avgt   15    5.888 ?  0.206  ns/op
>> ArrayClone.byteClone        1000  avgt   15   25.762 ?  0.203  ns/op
>> ArrayClone.intArraycopy        0  avgt   15    3.199 ?  0.016  ns/op
>> ArrayClone.intArraycopy       10  avgt   15    4.521 ?  0.008  ns/op
>> ArrayClone.intArraycopy      100  avgt   15   17.429 ?  0.039  ns/op
>> ArrayClone.intArraycopy     1000  avgt   15  178.432 ?  0.777  ns/op
>> ArrayClone.intClone            0  avgt   15    3.406 ?  0.016  ns/op
>> ArrayClone.intClone           10  avgt   15    4.272 ?  0.006  ns/op
>> ArrayClone.intClone          100  avgt   15   13.110 ?  0.122  ns/op
>> ArrayClone.intClone         1000  avgt   15  113.196 ? 13.400  ns/op
>> 
>> 
>> It also includes an optimization to avoid instantiating the array copy stub in scenarios like this.
>> 
>> I run hotspot compiler tests successfully limiting them to C1 compilation darwin/aarch64, linux/x86_64 and linux/686. E.g.
>> 
>> 
>> $ make test TEST="hotspot_compiler" JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=1"
>> ...
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg:hotspot_compiler          1234  1234     0     0
>> 
>> 
>> One question I had is what to do about non-primitive object arrays, see my [question](https://bugs.openjdk.org/browse/JDK-8302850?focusedId=14634879&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14634879) on the issue. @cl4es any thoughts?
>> 
>>...
>
> Galder Zamarreño has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use vmIntrinsics instead of vmIntrinsicID
>  - Fix formatting

src/hotspot/share/c1/c1_GraphBuilder.cpp line 4441:

> 4439: 
> 4440: void GraphBuilder::append_alloc_array_copy(ciMethod* callee) {
> 4441:   {

There are stylistic questions to this block
- why separate block?
- not necessary comment "Peek at receiver"
- misprint in "not primtive array" comment
- extra line for {
- excessive comment "// not primitive array"
- bailout message do not mention phi
- please use INLINE_BAILOUT macro

Comment about phi does not make things clear: not evident why receiver type can be nullptr and why it is phi. After all, why can't we check src->exact_type()->as_array_klass()->element_type() here?

test/hotspot/jtreg/compiler/c1/TestNullArrayClone.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8302850

please add @summary
is the purpose of the test to check that array clone throws NPE for null input and does not throw otherwise?
Don't we want to check the contents of the copied data?
Don't we want to check different sizes and array types?
Is 1K iterations enough to compile the method?

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

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