On Sat, 06 Jun 2009 22:07:40 +0300, Sean Kelly <[email protected]>
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:[email protected]
