RFR: 8293770: RISC-V: Reuse runtime call trampolines

[Fei Yang]

On Wed, 14 Sep 2022 02:58:42 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv.
> 
> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average.
> 
> ## Testing:
> 
> - hotspot and jdk tier1 on unmatched board without new failures
> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu
> 
> 
> ## Results
> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1)
> 
> - riscv64
> 
> +--------------------------------------------------------------------------------------------------------+
> |                |                     Before                |                    After                  |
> |    Benchmark   |---------------------------------------------------------------------------------------| 
> |                | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods |
> +----------------+-----------------------+-------------------+-----------------------+-------------------| 
> | als            |                 15628 |             39421 |                 12341 |             26681 |
> | chi-square     |                  6349 |             20268 |                  6033 |             20252 |
> | dec-tree       |                 11058 |             42443 |                 10774 |             43880 |
> | log-regression |                 10939 |             38237 |                 12071 |             44199 |
> | naive-bayes    |                  9023 |             29563 |                  9294 |             30948 |
> | page-rank      |                  6054 |             17041 |                  5812 |             17353 |
> | fj-kmeans      |                   692 |              2893 |                   651 |              3354 |
> | reactors       |                  2126 |              4073 |                  1876 |              4106 |
> | future-genetic |                  1306 |              4118 |                  1226 |              4142 |
> | mnemonics      |                   726 |              2659 |                   706 |              2684 |
> | dotty          |                 26059 |             24417 |                 24585 |             25379 |
> | scala-kmeans   |                   564 |              3122 |                   543 |              3132 |
> | finagle-http   |                  6188 |             12455 |                  6102 |             12295 |
> | sum            |                 96712 |            240710 |                 92014 |            238405 |
> +--------------------------------------------------------------------------------------------------------+

I have two comments here.

src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 34:

> 32:     constexpr unsigned init_size = 8;
> 33:     constexpr unsigned max_size  = 256;
> 34:     _shared_trampoline_requests = new SharedTrampolineRequests(init_size, max_size);

I have the same concern here as [1]. Did you looked into it?

[1] https://github.com/openjdk/jdk/pull/9405#pullrequestreview-1076140575

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2819:

> 2817:          entry.rspec().type() == relocInfo::virtual_call_type, "wrong reloc type");
> 2818: 
> 2819:   address target = entry.target();

We call far_branches() and entry.target() more than once here in this function, which could be simplified.
I think we can set target according to result of far_branches() and plant a single jal(target) instead.

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

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10260