darwin: Fix memory metrics support for Apple Silicon (ARM64)

[SuCicada]

Fix memory metrics of Apple Silicon (ARM64) Detailed description: https://github.com/htop-dev/htop/issues/631

The calculation of memory refers to exelban/stats Modules/RAM/readers.swift

let used = active + inactive + speculative + wired + compressed - purgeable - external

[BenBE]

Two general notes:

1. Squash the two commits, as commits should show a direct way from A to B without all the steps inside the maze … Mostly split commits, when there are independent changes that work without each other or there's something preparing for a later change

2. There should be no blank after casts, like this (foo)expression …

Also note the remarks earlier re implementation for both 32 and 64 bit VM structures using conditional compilation.

[SuCicada]

Thank you for your guidance, I have resubmitted.

1. I fix the blank format
2. I use __LP64__ for conditional compilation instead.
3. I restored 32-bit support and removed duplicate functions that I had written before.

[BenBE]

LGTM.

Any particular reason for checking an architecture setting (64 bit support of the architecture) over explicit testing for availability of a concrete type/structure in configure.ac?

[SuCicada]

LGTM.

Any particular reason for checking an architecture setting (64 bit support of the architecture) over explicit testing for availability of a concrete type/structure in configure.ac?

Oh, You are right. It is more explicit to test the availability of a concrete type/structure in configure.ac. I will try

[SuCicada]

Thank you for your guidance, I have resubmitted.

1. I added checking of vm_statistics64 at configure.ac.
2. I use HAVE_VM_STATISTICS64 for conditional compilation instead.

What do you think

[SuCicada]

Makes sense, but this will produce 2 macros. If use If someone's computer cannot meet host_statistics64 and vm_statistics64_data_t at the same time, (very unlikely) Then it will happen:

host_statistics64 support	vm_statistics64_data_t support	result
yes	no	can compile and run normally, but the memory value is incorrect
no	yes	can compile normally, but fails to run: [1] 16517 segmentation fault ./htop

I am not sure if there is a better solution, or if we can ignore this very unlikely situation.

[BenBE]

AutoConf has the ability to nest those macros, i.e. only check the second if the first succeeded. Likewise for the second macro: Only define the feature flag once the second macro succeeded too.

Untested:

   AC_CHECK_FUNCS([host_statistics64], [
      AC_CHECK_TYPES([struct vm_statistics64], [
         AC_DEFINE([HAVE_VM_STATISTICS64], 1, [The vm_statistics64 features is supported.])
      ], [], [[#include <mach/vm_statistics.h>]])
   ], [], [[#include <mach/vm_statistics.h>]])

Check for HAVE_VM_STATISTICS64 in the code …

[Explorer09]

@BenBE Both AC_CHECK_FUNCS and AC_CHECK_TYPES would define the "HAVE_" C macro names for you. There's no need to use AC_DEFINE manually.

There would be HAVE_STRUCT_VM_STATISTICS64 and HAVE_HOST_STATISTICS64 defined automatically. Just pick a name that sounds better in the C code. And put that macro check as an inner call in configure.ac.

AC_CHECK_TYPES([struct vm_statistics64], [
   AC_CHECK_FUNCS([host_statistics64])
   ], [], [[#include <mach/vm_statistics.h>]])
dnl Then use HAVE_HOST_STATISTICS64 in the C code

[BenBE]

I know. The AC_DEFINE was there to use the other code AS-IS and have the implicit AND …

[SuCicada]

Thank you for your patient guidance, I have resubmitted.

(In fact, I had previously attempted this method but mistakenly believed it didn't work🫣. After your confirmation, I have re-verified and got the correct compile result.👍)

[Explorer09]

Okay. Since I have got an M2 MacBook Pro, I just have a test on this PR, and here is a screenshot without and with the patch:

(The OS version is macOS Sequoia 15.2)

[ghost]

I would suggest doing what Apple officially does in their top(1) program, as I suggested in my recent issue: https://github.com/htop-dev/htop/issues/1573

[Explorer09]

Well, I didn't expect this PR (pull request) to be merged so soon, since there are discussions going in #1573, and there are people who disagrees with the formula of calculating the used memory.

Note that I take a neutral position here and won't suggest which way of calculating used memory is "correct", but I think @time-killer-games can now make a PR based on the current main and suggest a better formula, and let the discussions continue.

[BenBE]

I'm also mostly neutral on the specifics. Also as far as I checked before merging there was nothing actually critical open, that was a blocker. Mostly cosmetic stuff.

[ghost]

I'm also mostly neutral on the specifics. Also as far as I checked before merging there was nothing actually critical open, that was a blocker. Mostly cosmetic stuff.

It's not very pressing, if you need time to talk it over or if you like this solution better than what top does, no worries. I found out in my discussion with the fastfetch lead dev this solution matches neofetch.

[ghost]

My pull request has been submitted: https://github.com/htop-dev/htop/pull/1578

However please note I'm away from home and won't be able to test on my mac mini until tomorrow at the earliest. I'm hoping the code change I made does actually match what top(1) shows now.

[BenBE]

The time around and after X-mas is always kinda busy for everyone. Have been busy the past few days myself and will likely be for some time. No need to hurry things along. I'll take a look at it when I've got a moment.