Discuss the RISC-V OpenJDK11u port
yangfei at iscas.ac.cn
yangfei at iscas.ac.cn
Mon Feb 20 09:24:13 UTC 2023
Hi,
-----Original Messages-----
From:"Xiaolin Zheng" <yunyao.zxl at alibaba-inc.com>
Sent Time:2023-02-17 15:53:59 (Friday)
To: riscv-port-dev <riscv-port-dev at openjdk.org>
Cc: "蒯微(麦庶)" <kuaiwei.kw at alibaba-inc.com>, "李三红(三红)" <sanhong.lsh at alibaba-inc.com>
Subject: Discuss the RISC-V OpenJDK11u port
> Hi team,
> We would like to discuss the RISC-V OpenJDK11u port.
> Currently seems no one claims this port yet, and it would be a pleasure for us if we (from Alibaba) could take the backporting work.
Welcome joining the backporting work :-)
Note that we should start from 17u, then 11u and finally 8u.
So I think backporting process for the 11u staging repo should only start after we finished 17u backporting.
But that should not stop you from doing/preparing the work in your private repo.
> We have a backport [1] [2] on Alibaba Dragonwell11 (downstream of our OpenJDK11) that works fine currently, though backported from the initial load of the riscv-port repo [3] at the beginning of the last year. We are currently thinking of contributing that to the upstream, despite that various polishing, patch splitting, and further backporting to meet the requirements of backports are needed. So obviously it is not a "ready-to-go" one like the 17u port [4] by Yadong.
That's great to hear.
Yes, I suppose the backporting patches for 11u should be derived from 17u repo unless there is a special reason.
That also means that normally a fix should be first backported to 17u before it could be considered for older versions like 11u.
> Some challenging parts might be the differences between the gaps in 11u and 19 and above. For example, on 11u we do not have a VecA implementation, yet, the RVV vector extension in the RISC-V backend [5] in the mainline needs it. The VecA implementation may look currently unlikely to get permission to backport since the changes [6] in shared code. Without VecA, C2 vector intrinsics and the VectorAPI-related code may not work, but intrinsics using vector registers directly could work as expected, like `StubGenerator::copy_memory_v`.
I guess it should be reasonable if it could be demonstrated that is necessary for some basic functionality?
But that will depend on the upstream jdk update project maintainers.
Thanks,
Fei Yang
</sanhong.lsh at alibaba-inc.com></kuaiwei.kw at alibaba-inc.com></riscv-port-dev at openjdk.org></yunyao.zxl at alibaba-inc.com>
More information about the riscv-port-dev
mailing list