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