Re: 64-bit problem with VM statistics
Re: 64-bit problem with VM statistics
- Subject: Re: 64-bit problem with VM statistics
- From: Tony Scaminaci <email@hidden>
- Date: Wed, 1 Jun 2005 13:03:33 -0700 (PDT)
Kevin,
I've gotten feedback from a number of users that the
large number being reported also causes their systems
to lock up completely. It's not just a printf problem.
Here's the source code for the function in question:
unsigned long long GetFreeMem()
{
vm_statistics_data_t vm_stat;
mach_port_t host_priv_port, host_port;
mach_msg_type_number_t host_count;
kern_return_t kern_error;
unsigned long long FreeMem; // Free real
(physical) memory
// Get host machine information
mach_port_t get_host_priv()
{
return(mach_host_self());
}
mach_port_t get_host_port()
{
return(mach_host_self());
}
// Get total system-wide memory usage structure
host_priv_port = get_host_priv();
host_port = get_host_port();
host_count = sizeof(vm_stat)/sizeof(integer_t);
kern_error = host_statistics(host_priv_port,
HOST_VM_INFO, (host_info_t)&vm_stat, &host_count);
if (kern_error != KERN_SUCCESS)
{
mach_error("host_info", kern_error);
exit(EXIT_FAILURE);
}
host_page_size(host_port, &mac_pagesize); // Get
page size for this machine
FreeMem = ((unsigned long long) vm_stat.free_count)
* mac_pagesize; // Calculate total free memory in
bytes
FreeMem &= 0xFFFFFFFFFFFFFFC0ull; // Align byte
count to 64-byte boundary
return(FreeMem);
}
I need to have the correct number of bytes returned to
the calling function in both 32-bit and 64-bit modes.
This code works correctly in 32-bit environments but
is breaking on 64-bit platforms.
Thanks,
Tony
--- Kevin Van Vechten <email@hidden> wrote:
> Perhaps the problem is with the format string used
> to print the
> number instead of with the number itself?
>
> Would someone mind pointing me to the specific
> source file in question?
>
> Thanks,
>
> - Kevin
>
> On Jun 1, 2005, at 6:23 AM, Tony Scaminaci wrote:
>
>
> >> 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