Fwd: 64-bit problem with VM statistics
Fwd: 64-bit problem with VM statistics
- Subject: Fwd: 64-bit problem with VM statistics
- From: Tony Scaminaci <email@hidden>
- Date: Wed, 1 Jun 2005 08:23:29 -0500
From: Tony Scaminaci <email@hidden>
Date: June 1, 2005 8:18:31 AM CDT
To: William Kucharski <email@hidden>
Cc: Tony Scaminaci <email@hidden>
Subject: Re: 64-bit problem with VM statistics
Unfortunately, this is the exact line that's NOT working on 64-bit platforms. FreeMem is returning with the following:
Available memory: 268267683840MB (281299054850211840 bytes)
The number of bytes (which is what FreeMem is holding) is way too large. It should be around
4613734400 bytes on this particular machine which has about 4400 MB free as shown by top.
I received a bug post from John Caldwell who flagged this line of code as having a sign
extension issue. He indicated that the correct way to implement this is to cast vm_stat.free_count to
an unsigned 32-bit first, then cast the result to an unsigned long long. I'm still not sure of the correct
coding and order of typecasting though since he didn't give an example.
Tony
On Jun 1, 2005, at 1:32 AM, William Kucharski wrote:
On May 31, 2005, at 1:28 PM, Tony Scaminaci wrote:
The following calculation of free memory (in bytes) works correctly on 32-bit platforms. On 64-bit systems (Tiger + G5),
the result is a horrendously huge number rather than what is expected. I'm sure this is one of the conversion issues covered
in the 64-bit transition guide (which I've read over multiple times already) but I can't seem to nail down the right
way to do this calculation for both 32 and 64-bit systems.
vm_size_t mac_pagesize;
unsigned long long FreeMem; // Free real (physical) memory in bytes
What's the "horrendously huge" number?
The correct way to do this is to cast the number of pages to an unsigned long long and multiply it by mac_pagesize, so the initial code sample you had:
FreeMem = ((unsigned long long) vm_stat.free_count) * mac_pagesize;
should work just fine on all architectures.
William Kucharski
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden