-
Notifications
You must be signed in to change notification settings - Fork 73
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
[WIP] Add Apple Silicon support to Mesh #104
base: master
Are you sure you want to change the base?
Conversation
This is a work-in-progress since the tests are still segfaulting. They segfault while gmock is printing a message to stdout; specifically while stdout is about to be flushed. |
@camelid sorry for letting this linger for so long - for me tests are failing too, but they're hitting assertions. I've done a few things, so it make sense to see if our setups are the same. First, I'm running on macOS Sonoma 14.3.1 (the latest), and I've just run diff --git a/wrappers/mmapwrapper.h b/wrappers/mmapwrapper.h
index 0226c9f..2fc24ee 100644
--- a/wrappers/mmapwrapper.h
+++ b/wrappers/mmapwrapper.h
@@ -185,7 +185,7 @@ namespace HL {
#ifdef HL_APPLE_SILICON
#include <mach/vm_page_size.h>
assert(sz % vm_page_size == 0);
- assert((ptr % vm_page_size) == 0);
+ assert((reinterpret_cast<uintptr_t>(ptr) % vm_page_size) == 0);
#endif
if (ptr == MAP_FAILED) { to work past a compilation failure. Next, I had to update Ok, so at this point I could run: $ make clean; make which fails with the following test failure:
This is due to us increasing the number of bits needed for diff --git a/src/mini_heap.h b/src/mini_heap.h
index 14e38c8..9512aea 100644
--- a/src/mini_heap.h
+++ b/src/mini_heap.h
@@ -62,7 +62,7 @@ public:
d_assert(svOffset < (kPageSize / kMinObjectSize - 1));
d_assert_msg(sizeClass < 255, "sizeClass: %u", sizeClass);
d_assert(maxCount <= (kPageSize / kMinObjectSize));
- d_assert(this->maxCount() == maxCount);
+ d_assert_msg(this->maxCount() == maxCount, "maxCount() (%u) != maxCount (%u)", this->maxCount(), maxCount);
}
inline uint32_t freelistId() const {
@@ -79,7 +79,7 @@ public:
inline uint32_t maxCount() const {
// XXX: does this assume little endian?
- return (_flags.load(std::memory_order_seq_cst) >> MaxCountShift) & 0x1ff;
+ return (_flags.load(std::memory_order_seq_cst) >> MaxCountShift) & 0x7ff;
}
inline uint32_t sizeClass() const { With this fix applied, I then get:
Which is fixed with: #108 (which I merged to master). Boy this was a hard/frustrating one to find! I made a lot of use of everything looks good, but immediately after that At this point I see 2 failures, depending on whether I run the unit test binary under LLDB or not. First, not under LLDB I see:
Which is baffling, as all that does is call Finally, there is also:
I think this test case just needs to be updated - I don't think those strictly have to be equal (but I could have forgotten some context). Hope this helps! The meat and potatoes tests are currently skipped because you added
If I remove that flag, and change: +++ b/src/testing/unit/concurrent_mesh_test.cc
@@ -20,7 +20,7 @@ using namespace std;
using namespace mesh;
static constexpr uint32_t StrLen = 128;
-static constexpr uint32_t ObjCount = 32;
+static constexpr uint32_t ObjCount = 128;
and also slightly change the segfault handler: diff --git a/src/runtime.cc b/src/runtime.cc
index 528604c..adfdc61 100644
--- a/src/runtime.cc
+++ b/src/runtime.cc
@@ -358,7 +358,7 @@ void Runtime::segfaultHandler(int sig, siginfo_t *siginfo, void *context) {
// okToProceed is a barrier that ensures any in-progress meshing has
// completed, and the reason for the fault was 'just' a meshing
- if (siginfo->si_code == SEGV_ACCERR && runtime().heap().okToProceed(siginfo->si_addr)) {
+ if ((siginfo->si_code == SEGV_ACCERR || siginfo->si_code == SEGV_MAPERR) && runtime().heap().okToProceed(siginfo->si_addr)) {
// debug("TODO: trapped access violation from meshing, log stat\n");
return;
} The concurrent mesh tests pass!
So I think we're close! |
I also temporarily pointed heaplayers to a local copy since it needs changes for Apple Silicon too.
maxCount bit width changed but load wasn't updated.
Thanks for the detailed reply! And apologies for my delayed response. I've applied the fixes you mentioned (including rebasing on master), but my tests are still failing, and indeed with no test output at all: ❯ make test
INFO: Analyzed target //src:unit-tests (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
FAIL: //src:unit-tests (see /private/var/tmp/_bazel_noahlev/059a892b8842c15c2c7b084bc67a8744/execroot/org_libmesh/bazel-out/darwin_arm64-fastbuild/testlogs/src/unit-tests/test.log)
INFO: From Testing //src:unit-tests:
==================== Test output for //src:unit-tests:
================================================================================
Target //src:unit-tests up-to-date:
bazel-bin/src/unit-tests
INFO: Elapsed time: 0.149s, Critical Path: 0.05s
INFO: 2 processes: 2 local.
INFO: Build completed, 1 test FAILED, 2 total actions
//src:unit-tests FAILED in 0.0s
/private/var/tmp/_bazel_noahlev/059a892b8842c15c2c7b084bc67a8744/execroot/org_libmesh/bazel-out/darwin_arm64-fastbuild/testlogs/src/unit-tests/test.log
INFO: Build completed, 1 test FAILED, 2 total actions
make: *** [test] Error 3 Any idea what's causing this lack of output and the discrepancy between our test results? |
Oh, I forgot to mention that I'm on Sonoma 14.1 (slightly older), and I've also updated all my homebrew packages. |
Weirder still, if I cd into
|
Apple Silicon uses 16K pages, while most OSes use 4K. Mesh makes several assumptions of a 4K page size for performance reasons, so it is nontrivial to add support for 16K pages.