imbajin opened a new issue, #3098:
URL: https://github.com/apache/hugegraph/issues/3098
## Summary
Add and document Linux/riscv64 support for HugeGraph.
HugeGraph is mostly Java, and OpenJDK already has a Linux/RISC-V port in
mainline. The remaining work is to verify and adapt the native-binary parts of
our build/runtime chain: JDK distribution, RocksDB JNI, protobuf/gRPC code
generation, Docker images, and optional native runtime libraries.
```mermaid
flowchart TD
A[HugeGraph on linux/riscv64] --> B[JDK 11+ runtime]
A --> C[Maven build]
A --> D[Storage backend]
A --> E[Docker image]
A --> F[CI / test path]
B --> B1[OpenJDK Linux/RISC-V RV64G/RV64GC]
C --> C1[protoc + protoc-gen-grpc-java binaries]
D --> D1[RocksDBJNI native library]
E --> E1[riscv64-capable base images]
F --> F1[QEMU smoke tests]
F --> F2[optional native riscv64 runner]
```
## Why this is useful
RISC-V hardware and Linux distributions are becoming more practical for
server-side testing. Supporting riscv64 would let HugeGraph users run and test
HugeGraph on RISC-V boards, VMs, and future RISC-V servers.
This is a good newcomer-friendly task because it can be split into small,
verifiable steps. Contributors do not need physical RISC-V hardware for the
first round of work.
## Current context
From a quick repository check:
- HugeGraph currently compiles with Java 11 target/source in the root
`pom.xml`.
- Current CI mainly runs on GitHub-hosted x86 Linux runners.
- Dockerfiles use Temurin 11 based images today.
- PD/Store gRPC modules download platform-specific `protoc` and
`protoc-gen-grpc-java` executables via `${os.detected.classifier}`.
- RocksDB is a key default/native dependency for the server and distributed
modules.
- `start-hugegraph-store.sh` currently handles `aarch64/arm64` and `x86_64`
for jemalloc, but not `riscv64`.
## Upstream / platform facts to verify against
- OpenJDK RISC-V Port Project targets Linux/RISC-V and the OpenJDK wiki says
the port supports RV64G, template interpreter, C1, C2, and current mainline
GCs. It also says RISC-V is in JDK mainline and can be tried with QEMU
user/system mode or hardware.
- https://openjdk.org/projects/riscv-port/
- https://wiki.openjdk.org/display/RISCVPort/Main
- Eclipse Temurin currently publishes Linux/riscv64 JDK builds for newer LTS
lines such as JDK 17 and JDK 21 via the Adoptium API, while JDK 11 riscv64
availability should be checked before relying on it.
-
https://api.adoptium.net/v3/assets/latest/17/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
-
https://api.adoptium.net/v3/assets/latest/21/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
-
https://api.adoptium.net/v3/assets/latest/11/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
- Debian 13 officially supports `riscv64`; Debian also documents RV64GC +
lp64d as the baseline for its port.
- https://www.debian.org/releases/stable/release-notes/whats-new.html
- https://wiki.debian.org/RISC-V
- Ubuntu provides RISC-V images and QEMU instructions. Note that Ubuntu
25.10+ raises the required ISA profile to RVA23S64; Ubuntu 24.04 LTS is usually
a safer first target for broad VM testing.
- https://ubuntu.com/download/risc-v/canonical-built
-
https://ubuntu.com/hardware/docs/boards/how-to/ubuntu_supported/qemu-riscv/
- Docker Buildx supports multi-platform builds using QEMU emulation, but
emulation can be much slower than native builds.
- https://docs.docker.com/build/building/multi-platform/
## Suggested task breakdown
### 1. Define the support target
Suggested first target:
- OS: Linux `riscv64`
- CPU/ABI: 64-bit little-endian RISC-V, RV64GC/RV64G-compatible, `lp64d`
- JDK: Java 17 or 21 for the first practical smoke tests; keep Java 11
bytecode compatibility unless the project decides otherwise
- Backend smoke target: `memory` first, then `rocksdb`
### 2. Make the build work on riscv64
Check and fix:
- `os-maven-plugin` classifier output on Linux/riscv64.
- `com.google.protobuf:protoc:*:exe:${os.detected.classifier}` availability.
- `io.grpc:protoc-gen-grpc-java:*:exe:${os.detected.classifier}`
availability.
- Fallback options when upstream does not publish riscv64 executables:
- use system-installed `protoc`, or
- build `protoc-gen-grpc-java` from source, or
- document a temporary riscv64 build profile.
### 3. Make the runtime work
Check and fix:
- `memory` backend startup on riscv64.
- `rocksdb` backend startup on riscv64.
- Whether the current `rocksdbjni` artifact contains a riscv64 native
library. If not, document/build a riscv64 RocksDB JNI artifact or find an
upstream-supported version.
- Optional jemalloc handling for Store: either add `riscv64` support or make
the current “unsupported architecture” path clearly non-fatal.
### 4. Add a no-hardware developer test path
Document a path like this:
```text
x86_64 / arm64 laptop
|
| QEMU system VM or Docker Buildx + QEMU
v
Linux riscv64 guest/container
|
| install JDK + Maven + native build deps
v
mvn compile / selected tests / HugeGraph smoke startup
```
Recommended first checks:
```bash
uname -m
java -version
mvn -version
mvn clean compile -Dmaven.javadoc.skip=true -ntp
mvn test -pl hugegraph-server/hugegraph-test -am -P unit-test -ntp
mvn test -pl hugegraph-server/hugegraph-test -am -P core-test,memory -ntp
```
Then test RocksDB when the native dependency story is clear:
```bash
mvn test -pl hugegraph-server/hugegraph-test -am -P core-test,rocksdb -ntp
```
### 5. Optional CI follow-up
Once the manual smoke path works:
- add a lightweight riscv64 workflow using QEMU for compile/smoke tests, or
- document how maintainers can attach a riscv64 self-hosted runner for
fuller tests.
## Acceptance criteria
This task can be considered done when:
- [ ] The project documents the intended Linux/riscv64 support target: OS,
CPU/ABI, JDK version, and tested backends.
- [ ] `mvn clean compile -Dmaven.javadoc.skip=true -ntp` works in a
documented riscv64 environment, or any remaining upstream blocker is clearly
documented.
- [ ] At least `memory` backend tests or smoke startup are verified on
riscv64.
- [ ] RocksDB support is either verified on riscv64 or documented as blocked
by a specific upstream/native-library gap.
- [ ] Developers without RISC-V hardware can reproduce the smoke test with
QEMU or Docker Buildx/QEMU.
- [ ] The docs explain the known limitations and the expected follow-up work
for CI/native runners.
## Notes for first-time contributors
You can start without a RISC-V board. The best first PR would be a
documentation PR that records a working QEMU setup and the first failing
command, if any. After that, smaller code/build fixes can be done one by one.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
