Expand ARM Architecture Compatibility #5954
Comments
|
I am totally in favor of extending ARM architecture compatibility. This will allow Java-Tron to run on more platforms and take advantage of the benefits of the ARM architecture, such as higher energy efficiency and lower cost.
|
|
It sounds great, but I am a novice in ARM architecture. I am curious about the challenges of supporting ARM architecture. Can you list something like a task list in the future? It is convenient to clearly understand the current status and future challenges. |
|
Here are some common considerations: Important
Important 2. Native code
Tip 3. Endianness Tip 4. Memory alignment: Tip 5. Atomic operations and concurrency Caution 6. Floating-point arithmetic Tip 7. Performance optimization Important 8. Third-party dependencies
Important 9. Build and deployment process:
Tip 10. Hardware feature dependencies: Tip 11. System calls and OS interactions Important 12. Cross-platform testing
|
|
@halibobo1205 Do you want to support ARM Architecture and latest JVM version at the same time ? Or just support ARM Architecture using JDK8 ? |
|
@317787106 JVM officially supports ARM:
According to Oracle Java SE Support Roadmap, JDK9 and JDK16 are non-LTS, and JDK 17 is LTS. Based on the above information, I propose that ARM support JDK17 as a minimum. Warning This is the last planned update of JDK 17 under the NFTC. Updates after September 2024 will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee. |
Regarding JDK version compatibility. |
|
When is the expected completion time for this work? It sounds like a big project. |
|
@endiaoekoe I propose that ARM support JDK17 as a minimum. |
|
@abn2357 Tron currently only supports JDK 8, based on the above information, JDK17 supports ARM fully, perhaps Tron needs to upgrade JDK17 first, which is another big project. |
|
@halibobo1205 It sounds great, and I look forward to your implementation. I see that there may be subtle differences in floating point precision and behavior between ARM and x86. When supporting it, be sure to ensure data consistency. Also investigate whether there are other places that may cause data inconsistency. |
|
This issue has been added to the core devs community call #22, welcome to share the latest progress @halibobo1205, and discuss together with @endiaoekoe @tomatoishealthy @317787106 @zeusoo001 @abn2357. |
|
1. JDK version compatibility
|
|
6. Floating-point arithmetic known issues:
Unfortunately, Tron does use private long exchangeToSupply(long balance, long quant) {
logger.debug("balance: " + balance);
long newBalance = balance + quant;
logger.debug("balance + quant: " + newBalance);
double issuedSupply = -supply * (1.0 - Math.pow(1.0 + (double) quant / newBalance, 0.0005));
logger.debug("issuedSupply: " + issuedSupply);
long out = (long) issuedSupply;
supply += out;
return out;
}
private long exchangeFromSupply(long balance, long supplyQuant) {
supply -= supplyQuant;
double exchangeBalance =
balance * (Math.pow(1.0 + (double) supplyQuant / supply, 2000.0) - 1.0);
logger.debug("exchangeBalance: " + exchangeBalance);
return (long) exchangeBalance;
}Test case @Test
public void testPow() {
double x = 29218;
double q = 4761432;
double ret = Math.pow(1.0 + x / q, 0.0005);
double ret2 = StrictMath.pow(1.0 + x / q, 0.0005);
System.out.printf("%s%n", doubleToHex(ret)); // 3ff000033518c576
System.out.printf("%s%n", doubleToHex(ret2)); // 3ff000033518c575
Assert.assertEquals(0, Double.compare(ret, ret2)); // fail in jdk8_X86, success in jdk8_ARM64
}
public static String doubleToHex(double input) {
// Convert the starting value to the equivalent value in a long
long doubleAsLong = Double.doubleToRawLongBits(input);
// and then convert the long to a hex string
return Long.toHexString(doubleAsLong);
}Tron Should Use StrictMath to Avoid Cross-Platform Consistency Issues. To help ensure the portability on ARM for Java-Tron, I suggest a new proposal to convert Math to StrictMath. cc @zeusoo001 |
|
@halibobo1205 First support JDK8 on mac ARM and then extend to support JDK17 on linux and mac ARM may be smooth. |
Does this mean that there is no longer a dependency between ARM architecture upgrade and JDK upgrade? In addition, TRON only focuses on Oracle JDK, right? |
|
2. Native code JNI (Java Native Interface) or other native code.
|
|
8. Third-party dependencies Ensure all third-party libraries and dependencies support ARM architecture.
|
|
Warning This is the last planned update of JDK 17 under the NFTC. Updates after September 2024 will be licensed under the Java SE OTN License (OTN) and production use beyond the limited free grants of the OTN license will require a fee. To avoid subsequent charges for commercial use, I recommend switching to OpenJDK. |
|
Caution Strong data consistency and finality |
|
1. JDK version compatibility |
|
A hard fork solution will be introduced in 4.8.0, switching floating-point calculations from Math to StrictMath. |
|
Currently, java-tron supports both LevelDB and RocksDB. On the ARM architecture, we intend to support only RocksDB, mainly due to the following considerations:
This will ensure the best database usage experience on ARM architecture. |
Background
Java-Tron currently only supports the x86 architecture. Nevertheless, ARM architecture has gained significant traction recently, especially in cloud computing and mobile devices. ARM processors are known for their energy efficiency and cost-effectiveness, making them increasingly popular in data centers, cloud computing, and edge computing scenarios. It will be great to have an option to run Java-Tron using ARM architecture.
Key developments in ARM architecture:
ARM advantages:
Related Issues and PRs
Scope of Impact
The text was updated successfully, but these errors were encountered: