Pop quiz [memory usage]

[Fawzi Mohamed]

On 2009-06-07 04:07:45 +0200, Sean Kelly <sean at invisibleduck.org> said:

> Fawzi Mohamed wrote:
>> On 2009-06-06 21:07:40 +0200, Sean Kelly <sean at invisibleduck.org> said:
>> 
>>> Vladimir Panteleev wrote:
>>>> On Sat, 06 Jun 2009 20:19:45 +0300, Sean Kelly <sean at invisibleduck.org>
>>>> wrote:
>> [...]
>>>> 
>>>>> I've been debating for a while whether newCapacity shoulds exist at 
>>>>> all.   The GC already tends to leave free space at the end of blocks, 
>>>>> so why should the runtime second-guess it?
>>>> 
>>>> Do you mean at the end of pages, or pools?
>>> 
>>> Blocks.  Blocks less than 4k in the current allocator are sized in 
>>> powers of two, so array appends already get the "double in size" 
>>> behavior in Java even without newCapacity.  newCapacity just has the 
>>> potential to throw an array into the next larger block early, thus 
>>> potentially wasting more space if the array will never be appended to. 
>>> I think newCapacity isn't supposed to reserve extra space for blocks 
>>> larger than 4k, but it's been a while since I've looked at it.
>> 
>> at the moment the behavior is exactly the opposite (leaving the small 
>> array to the GC handling you just sketched)), only array larger than a 
>> page have the special treatment, I think that the idea is that 
>> appending to large arrays can be potentially very expensive, so those 
>> get the special treatment.
> 
> Hm.  I still think we'd be better off letting the user handle this.  If 
> they're going to be appending and performance is important then they'll 
> use an ArrayAppender anyway.  I'd rather not have extra space tacked 
> onto the end of every array I create "just in case" I decide to append 
> to it.

well it isn't so bad, newCapacity is used only when the use *is* adding 
in place, and the array is not large enough.

Fawzi