Ports to aarch64 and ppc64le systems with OS pages 65536 bytes big#165
Ports to aarch64 and ppc64le systems with OS pages 65536 bytes big#165Karm wants to merge 2 commits intolmdbjava:masterfrom
Conversation
* Added more distinguished names for x86_64, aarch64, ppc64le and unified arch64 for all three linuxes * Renamed unifying x86_64 varable to make spotbugs happy
- Page size is configurable via env and sys prop PAGE_SIZE - Allocation happens page by page, not by an arbitrary chunk
Codecov Report
@@ Coverage Diff @@
## master #165 +/- ##
============================================
- Coverage 90.93% 90.40% -0.53%
- Complexity 383 385 +2
============================================
Files 30 30
Lines 1346 1366 +20
Branches 118 124 +6
============================================
+ Hits 1224 1235 +11
- Misses 58 63 +5
- Partials 64 68 +4
Continue to review full report at Codecov.
|
|
This pull request introduces 1 alert when merging dacfdc8 into 26d76be - view on LGTM.com new alerts:
|
|
? |
It is correct, but not deserved. |
There's more information in the LGTM "Result of multiplication cast to wider type" article. Try making |
Yup. I understand that, and long is direct fix. But considering how the page_size is used in java, jni and lmdb... I'm quite unable to judge to consequences of the retypeing. On contrary, we can safely assume, that PAGE_SIZE * 1_024 will remain in the int range |
|
As The
Hope this clears things up. I see no issue with performing the cast. |
|
Hello ! Any activity ongoing on this one ? Just waiting on the cast ? |
|
I'm afraid nothing si happening here:( |
|
And afaik should be merged :) |
0a78414 to
a1162e1
Compare
|
Can this be rebased and then merged please? |
|
As per #217 a Zig-based cross-compilation process has now been added to LmdbJava and deprecates the old LmdbJava Native project. I would welcome an update to this PR or a new PR that provides or improves any cross-platform support. |
|
The lmdb library states that the map size should be a multiple of the page size. The failing tests are examples which succeed when tested on systems with conventional page sizes but fail with larger page sizes. The two options are a) massage the requested map size to a "proper" size in lmdbjava or b) adopt the same view as lmdb and document that it is the responsibility of client to choose a map size and simply alter tests to request a larger map size. See https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/lmdb.h#L813:L845 referenced in above PR. |
|
I've taken the view that if LMDB feels setting the right map size is the job of the client, then lmdbjava should do the same. As such, I've created a minimal change PR #218 to make the tests run on architectures with a different page size. |
|
Closing this ticket as #218 has added the required functionality and has been merged. |
Hello,
This PR surpasses #161.
This PR depends on lmdbjava/native#9
Notable changes:
Notable documentation these changes are based on:
How it was tested
RHEL 8 aarch64, 4 CPUs, 6G RAM
RHEL 8 ppc64le, 50 CPUs, 252G RAM
Fedora, amd64, 8 CPUs, 32G RAM
Note about ppc64le
As you can see, Dbi test takes a very long time on the, ironically, most powerful ppc64le box, see:
I do not know why it takes so much time, but it happened more or less in the same way all three times I tried.