RFR(S): 8025942: Implement os::Bsd:available_memory

[Gerard Ziemski]

hi Harold,

I don't think that's necessary - the call will fail in 2 cases:

1. null host
2. wrong attribute size

Re 1. we use mach_host_self() to get the host - if that were to fail, 
we'd have failed long before here.
Re 2. the XNU implementation of the call checks that attribute size is 
set to HOST_VM_INFO64_COUNT, which is what we use

so in my opinion no assert is needed, and adding it might in fact muddle 
the waters as any future reader of the code might very well think that 
it's likely to fail.


cheers

On 10/11/2013 10:33 AM, harold seigel wrote:
> Hi Gerard,
>
> Since host_statistics64 is unlikely to fail, can you add an assert to 
> ensure that we catch the rare case when it fails?
>
> Thanks, Harold
>
> On 10/11/2013 11:26 AM, Gerard Ziemski wrote:
>> hi David,
>>
>> On 10/10/2013 11:32 PM, David Holmes wrote:
>>> Hi Gerard,
>>>
>>> On 11/10/2013 5:14 AM, Gerard Ziemski wrote:
>>>> Please review this fix that implements os::Bsd:available_memory()
>>>>
>>>> Description:
>>>>
>>>> This is a simple change - we use a similar implementation that Apple
>>>> itself uses (see
>>>> http://opensource.apple.com/source/system_cmds/system_cmds-498.2/vm_stat.tproj/vm_stat.c) 
>>>>
>>>> to implement BSD (Apple platform only) implementation for finding out
>>>> available (free) memory.
>>>
>>> Is host_statistics64 likely to fail? If not then I think we should 
>>> trap any failures, at least with an assert, so that they are 
>>> noticed. Otherwise this might fail all the time and we would be none 
>>> the wiser.
>>
>> I looked at the implementation of host_statistics64 in XNU src and 
>> the only reason it will fail is if we pass wrong parameters (such as 
>> NULL host). Otherwise, it is guaranteed to return a valid value, so 
>> there does not seem to be a need for an assert here.
>>
>>
>> cheers
>
>
>