Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand ARM Architecture Compatibility #5954

Open
halibobo1205 opened this issue Aug 15, 2024 · 26 comments
Open

Expand ARM Architecture Compatibility #5954

halibobo1205 opened this issue Aug 15, 2024 · 26 comments

Comments

@halibobo1205
Copy link
Contributor

halibobo1205 commented Aug 15, 2024

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

  • Build and deployment processes
  • Core application code
  • Third-party dependencies
  • Development and testing environments
@endiaoekoe
Copy link

endiaoekoe commented Aug 15, 2024

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.
In my opinion, we can start with the following:

  1. Prioritize ARM support for key dependencies: For example, RocksDB/LevelDB is an important database component in Java-Tron and it is critical to ensure its compatibility on ARM.
  2. Establish an ARM test environment: We need to establish a dedicated ARM test environment to ensure the stability and performance of Java-Tron on ARM.
  3. Collaborate with the community: We can work with the community to solve ARM compatibility issues and share experiences and best practices.

@tomatoishealthy
Copy link
Contributor

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.

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Aug 15, 2024

Here are some common considerations:

Important

  1. JDK version compatibility
    Ensure the JDK version supports ARM Architecture. Consider using ARM-optimized JDK distributions.
  • Linux got support in JDK 9(non-LTS) by JEP 237
  • Windows got support in JDK 16(non-LTS) by JEP 388
  • Macs got support in JDK 17(LTS) by JEP 391

Important

2. Native code
JNI (Java Native Interface) or other native code.
These native code components need to be recompiled or upgraded for ARM architecture.

  • LevelDBJni
  • RocksDBJni
  • zksnark-java-sdk

Tip

3. Endianness
x86 is little-endian, while some ARM processors may be big-endian.
Check if any operations in the code(such as TVM) depend on a specific endianness, especially when handling binary data.

Tip

4. Memory alignment:
ARM architecture may have different memory alignment requirements than x86.
Check for code(such as TVM) that assumes specific memory alignments.

Tip

5. Atomic operations and concurrency
Some atomic operations(TVM) may be implemented differently on different architectures.
Review concurrent code to ensure it works correctly on ARM as well.

Caution

6. Floating-point arithmetic
ARM and x86 may have subtle differences in floating-point precision and behavior.
For applications that rely on precise floating-point calculations, comprehensive testing is necessary.

Tip

7. Performance optimization
x86-specific performance optimizations(TVM) may no longer be applicable on ARM.
Consider using ARM-specific optimization techniques.

Important

8. Third-party dependencies
Ensure all third-party libraries and dependencies support ARM architecture.
Some incompatible dependencies may need to be updated or replaced.

  • protoc-gen-grpc-java

Important

9. Build and deployment process:

  • Update build scripts to support ARM architecture.
  • Ensure CI/CD pipelines can be built and tested in ARM environments.
  • Docker support

Tip

10. Hardware feature dependencies:
Check if the code(TVM) relies on x86-specific hardware features.
Alternatives may need to be found for ARM.

Tip

11. System calls and OS interactions
If the code makes direct system calls, adjustments may be needed for ARM.

Important

12. Cross-platform testing

  • Establish comprehensive test suites to ensure the functionality works correctly on ARM.
  • Conduct performance benchmarking to compare x86 and ARM performance differences.

@317787106
Copy link
Contributor

317787106 commented Aug 15, 2024

@halibobo1205 Do you want to support ARM Architecture and latest JVM version at the same time ? Or just support ARM Architecture using JDK8 ?

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Aug 15, 2024

@317787106 JVM officially supports ARM:

  • Linux got support in JDK 9 by JEP 237
  • Windows got support in JDK 16 by JEP 388
  • Macs got support in JDK 17 by JEP 391

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.

@endiaoekoe
Copy link

Here are some common considerations:


Regarding JDK version compatibility.
You recommend using an ARM-optimized JDK distribution. What specific ARM-optimized JDK distributions do you recommend? What are their performance and stability advantages?

@abn2357
Copy link

abn2357 commented Aug 15, 2024

When is the expected completion time for this work? It sounds like a big project.

@halibobo1205
Copy link
Contributor Author

@endiaoekoe I propose that ARM support JDK17 as a minimum.

@halibobo1205
Copy link
Contributor Author

@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.

@zeusoo001
Copy link
Contributor

@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.

@Murphytron
Copy link

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.

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Aug 20, 2024

1. JDK version compatibility
After some brief research, I found ARM 64-bit versions of JDK 8 available. cc @endiaoekoe @317787106 @abn2357

Provider Linux Mac Windows Notes
Oracle • Official support
• Requires payment for commercial use
Eclipse Temurin Free OpenJDK
• Regularly updated and supported by the Adoptium community
Azul Zulu • Free OpenJDK
• Full enterprise version requires payment
BellSoft Liberica • Free OpenJDK for all users
• Relatively less well-known
Amazon Corretto • Free OpenJDK
• long-term support by Amazon
• Amazon runs Corretto internally on thousands of production services

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Aug 20, 2024

6. Floating-point arithmetic known issues:

Unfortunately, Tron does use Math.pow() for floating-point calculations for the Bancor trading pair in ExchangeProcessor:

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

@317787106
Copy link
Contributor

@halibobo1205 First support JDK8 on mac ARM and then extend to support JDK17 on linux and mac ARM may be smooth.

@tomatoishealthy
Copy link
Contributor

JDK version compatibility After some brief research, I found ARM 64-bit versions of JDK 8 available. cc @endiaoekoe @317787106 @abn2357

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?

@halibobo1205
Copy link
Contributor Author

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Aug 21, 2024

2. Native code

JNI (Java Native Interface) or other native code.
These native code components(JNI) must be recompiled or upgraded for ARM64 architecture and may include, but not limited to, the following.

  • LevelDBJni fusesource has stopped maintaining this project, no updates since Oct 17, 2013, forked by @halibobor, thanks to @folowing

  • RocksDBJni 6.29.4.1+ RocksJava support for ARM64 architecture

    • current version is 5.15.10, It is recommended to upgrade to 7.7.3+, which has been verified by synced from 0.

    • 6.29.4.1+ is incompatible with leveldb: org.rocksdb.RocksDBException: bad block contents in file output-directory/database/asset-issue-v2/MANIFEST-000428, 5.15.10 is compatible with leveldb.

      • levelDB -> open it without doing anything or convert levelDB to rocksDB by Toolkit.jar db convert without safe mode -> ✅ rocksDB-5.15.10 -> ❌ rocksDB-6.29.4.1+ won't work
      • levelDB -> ✅ convert levelDB to rocksDB by DBConvert.jar or Toolkit.jar db convert --safe with safe mode -> ✅ rocksDB-5.15.10 -> ✅ rocksDB-6.29.4.1+ is ok
      • rocksDB(rocksDB-5.15.10) -> ✅ rocksDB-6.29.4.1+ is ok
    • TODO:

      • 1. Disable RocksDB to open LevelDB directly
      • 2. Toolkit.jar db convert should force safe mode.
      • 3. Provide rocksDB rewrite tool to fix rocksDB directly open LevelDB without doing anything or convert levelDB to rocksDB byToolkit.jar db convert without safe mode scenario.
  • zksnark-java-sdk is upgraded for ARM64 architecture since GreatVoyage-v4.7.0.1

@halibobo1205
Copy link
Contributor Author

8. Third-party dependencies

Ensure all third-party libraries and dependencies support ARM architecture.
Some incompatible dependencies may need to be updated or replaced, including, but not limited to, the following.

@halibobo1205
Copy link
Contributor Author

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.

@halibobo1205
Copy link
Contributor Author

Caution

Strong data consistency and finality
Final data consistency is required for blockchain, and it's usually guaranteed by the world state. Unfortunately, Java-Tron doesn't have a world state.
We need to think about how to ensure final data consistency.

@halibobo1205
Copy link
Contributor Author

1. JDK version compatibility
Maybe try to support OpenJDK on ARM?

@halibobo1205
Copy link
Contributor Author

A hard fork solution will be introduced in 4.8.0, switching floating-point calculations from Math to StrictMath.

@halibobo1205
Copy link
Contributor Author

Currently, java-tron supports both LevelDB and RocksDB. On the ARM architecture, we intend to support only RocksDB, mainly due to the following considerations:

  1. Performance Advantages
    RocksDB, built on top of LevelDB, offers enhanced performance, reliability, and advanced features such as multi-threaded execution, compaction optimizations, and support for larger datasets, making it more suitable for high-throughput and low-latency use cases.

  2. Community Support

  • RocksDB has continuous investment and maintenance from Meta (Facebook)
  • Official support for RocksDB Java API
  • RocksDB community is more active in supporting ARM architecture
  • In comparison, LevelDB's community maintenance is relatively less active
  1. Feature Completeness
  • RocksDB offers richer features (e.g., column families, transaction support, TtlDB)
  • Built-in monitoring and performance diagnostic tools are more comprehensive
  • Provides more flexible configuration options for optimization on ARM architecture
  1. Future Development Trends
  • RocksDB is more widely used in blockchain domain
  • Continuously receives performance optimizations and feature updates
  • More timely support for new hardware features
  1. Ecosystem Integration
  • Better support for RocksDB in cloud-native environments
  • Better integration with modern monitoring tools
  • More mature support for containerized deployment
  1. Hardware Adaptation
  • Better optimization for new storage devices (e.g., NVMe SSD) in RocksDB
  • Better utilization of ARM architecture's specific instruction sets
  • Better support for large memory systems

This will ensure the best database usage experience on ARM architecture.

@halibobo1205
Copy link
Contributor Author

@halibobo1205
Copy link
Contributor Author

halibobo1205 commented Nov 21, 2024

Important

On the ARM architecture, we intend to support only RocksDB

When using RocksDB on the CI test, we found that some tests failed due to differences in behavior between LevelDB and RocksDB.

  • JVM core dump
image
  • RocksDB does not throw an error when it is closed
    • putData
    • deleteData
    • getData

@Murphytron
Copy link

This issue has been added to the tronprotocol/pm#105, welcome to share the latest progress @halibobo1205 , and discuss together with @endiaoekoe @317787106 @tomatoishealthy @zeusoo001 @abn2357 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants