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

[Coleen Phillimore]

On 10/11/2013 11:47 AM, Gerard Ziemski wrote:
> 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.

If you add an assert with the message that should provide executable 
documentation that these conditions are true.

Coleen

>
>
> 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
>>
>>
>>
>