feat(architecture): support arm64 based on JDK17 #6327
Conversation
halibobo1205
changed the title
|
The |
chainbase/src/main/java/org/tron/common/storage/rocksdb/RocksDbDataSourceImpl.java
Show resolved
Hide resolved
chainbase/src/main/java/org/tron/common/utils/StorageUtils.java
Outdated
Show resolved
Hide resolved
| @@ -16,6 +19,17 @@ | |||
|
|
|||
| public class ApiUtilTest { | |||
|
|
|||
|
|
|||
| @BeforeClass | |||
There was a problem hiding this comment.
Is there any benefit that add init and clear methods ? It seems no component used in this case.
There was a problem hiding this comment.
Using the correct configuration instead of reusing the configuration from the previous unit test resulted in an error.
platform/src/main/java/arm/org/tron/common/math/MathWrapper.java
Outdated
Show resolved
Hide resolved
| addPowData("3ff00033d5ab51c8", POW, "3ff0000006a279c8"); // 6240974 | ||
| addPowData("3ff0000046d74585", POW, "3ff0000000091150"); // 6279093 | ||
| addPowData("3ff0010403f34767", POW, "3ff0000021472146"); // 6428736 | ||
| addPowData("3ff00496fe59bc98", POW, "3ff000009650a4ca"); // 6432355,6493373 |
There was a problem hiding this comment.
What's the meaning of 6432355,6493373? Two blocks ?
| /** | ||
| * copy from org.bouncycastle.util.Arrays.compareUnsigned | ||
| */ | ||
| private static int compareUnsigned(byte[] a, byte[] b) { |
There was a problem hiding this comment.
Why not use org.bouncycastle.util.Arrays.compareUnsigned directly ? StrictMath.min don't affect this.
There was a problem hiding this comment.
The platform is an architecture-related module, whereas BouncyCastle is architecture-independent; therefore, it has not been introduced.
platform/src/main/java/common/org/tron/common/utils/MarketComparator.java
Show resolved
Hide resolved
platform/src/main/java/arm/org/tron/common/math/MathWrapper.java
Outdated
Show resolved
Hide resolved
| } else if (isArm64()) { | ||
| ext { | ||
| leveldbGroup = "com.halibobor" | ||
| leveldbName = "leveldbjni-all" |
There was a problem hiding this comment.
Why does the arm environment need leveldbjni? Is it for running test cases? Can the test cases that depend on leveldbjni be excluded from execution?
There was a problem hiding this comment.
That's a great suggestion. I'll give it a try.
There was a problem hiding this comment.
After trying it out, the changes were significant, and the results could not be verified in a short period, so no action was taken for the time being.
| if (!isAlive()) { | ||
| logger.warn("DB {} is not alive.", dataBaseName); | ||
| throw new org.iq80.leveldb.DBException("DB " + this.getDBName() + " is closed."); |
There was a problem hiding this comment.
is there any problem here? throw leveldb DBException in RocksDb?
There was a problem hiding this comment.
No, there are no issues. To unify database exceptions.
- update condition to check for NullPointerException instances
- maintain compatibility with both pre-Java 14 and Java 14+ versions
- address JEP 358 changes to NullPointerException behavior
- ensure correct handling of non-empty NPE messages in Java 14+
Refs: JEP 358, JDK-8220715
- use `java.specification.version` instead of parsing `java.version` - ensure consistent version reporting across different Java releases(jdk10+)
add javax.jws-api:1.1 and javax.annotation-api:1.3.2, refs:JDK-8190378, JEP 320 remove com.carrotsearch:java-sizeof:0.0.5 bump lombok from 1.18.12 to 1.18.34, refs: [Lombok Changelog](https://projectlombok.org/changelog) bump aspectjrt from 1.18.13 to 1.9.8, refs: [AspectJ Java version compatibility](https://eclipse.dev/aspectj/doc/latest/release/JavaVersionCompatibility.html)
for later updating RocksDB
…VisibleForTesting`
…e filesystem operations and stabilize disk usage
Closes #5954