Pop quiz [memory usage]

Vladimir Panteleev thecybershadow at gmail.com
Sat Jun 6 12:55:02 PDT 2009


On Sat, 06 Jun 2009 22:07:40 +0300, Sean Kelly <sean at invisibleduck.org>  
wrote:

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

Yes, but you do agree that the penalty of reallocating every time the  
array size goes over a 4kB boundary (in the worst case of heap  
fragmentation similar like the one I demonstrated) is not acceptable?

> This is a quirk of the current GC.  A new GC may not behave the same way  
> (in fact I can guarantee that the one I'm working on is implemented  
> differently).

Could you tell us more about that? I was toying with a new GC idea myself  
(since last year) but haven't gotten around to finishing it yet.

> I'm not sure I understand.  The only "idea" I proposed was to get rid of  
> newCapacity.

I understood as you wanting to change the code so it would behave as if  
newCapacity always returned newlength * size.

> The user already knows best which arrays are going to grow though.  Is  
> this really something the runtime should try to figure out?

No, but then you'll need to change the language specification to allow the  
user to specify growable arrays. I guess the proper solution here is to  
force the user to use specialized classes with their own "newCapacity"  
implementations.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow at gmail.com



More information about the Digitalmars-d mailing list