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 into
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.
|
Sorry, something went wrong.
|
This pull request introduces 1 alert when merging dacfdc8 into 26d76be - view on LGTM.com new alerts:
|
Sorry, something went wrong.
|
? |
Sorry, something went wrong.
It is correct, but not deserved. |
Sorry, something went wrong.
There's more information in the LGTM "Result of multiplication cast to wider type" article. Try making |
Sorry, something went wrong.
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 |
Sorry, something went wrong.
|
As The
Hope this clears things up. I see no issue with performing the cast. |
Sorry, something went wrong.
|
Hello ! Any activity ongoing on this one ? Just waiting on the cast ? |
Sorry, something went wrong.
|
I'm afraid nothing si happening here:( |
Sorry, something went wrong.
|
And afaik should be merged :) |
Sorry, something went wrong.
0a78414 to
a1162e1
Compare
December 10, 2022 01:29
|
Can this be rebased and then merged please? |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Closing this ticket as #218 has added the required functionality and has been merged. |
Sorry, something went wrong.
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.