Bugs in java.util.ArrayList, java.util.Hashtable and java.io.ByteArrayOutputStream

[Ulf Zibis]

Am 09.03.2010 21:02, schrieb Osvaldo Doederlein:
> Should we really consider this a VM bug? I'm not sure that it's a good 
> idea to allocate a single object which size exceeds 4Gb (for a byte[] 
> - due to the object header and array size field) - even on a 64-bit 
> VM. An array with 2^32 elements is impossible, the maximum allowed by 
> the size field is 2^32-1 which will be just as bad as 2^32-N for any 
> other tiny positive N, for algorithms that love arrays of [base-2-] 
> "round" sizes.
>
> And then if this bug is fixed, it may have slightly different 
> variations. For a long[] or double[] array, the allocation for the 
> maximum size would exceed 32Gb, so it exceeds the maximum heap size 
> for 64-bit HotSpot with CompressedOops. (Ok this is an artificial 
> issue because we won't like have a 100% free heap, so the only 
> impediment for "new long[2^32-1]" would be the array header.)
>
> My suggestion: impose some fixed N (maybe 64, or 0x100, ...), limiting 
> arrays to 2^32-N (for ANY element type). The artificial restriction 
> should be large enough to fit the object header of any vendor's JVM, 
> plus the per-object overhead of any reasonable heap structure. This 
> limit could be added to the spec, so the implementation is not a bug 
> anymore :) and it would be a portable limit. Otherwise, some app may 
> work reliably on HotSpot if it relies on the fact that 2^32-5 
> positions are possible, but may break on some other vendor's JVM where 
> perhaps the implementation limit is 2^32-13 or something else.
>

Please allow to correct:
it's 231-N !

...but +1 for your arguments.

In [base-2-] "round" sense, why there is the "+1" in [1] ?

I think [2] would look best. I'm sure, HotSpot anyway would optimize to 
(oldCapacity + (oldCapacity >> 1))
Look at the HotSpot disassembly for String#hashCode(), h*31 becomes h<<5-h.

-Ulf


[1] current PriorityQueue snippet:
...
         int newCapacity = ((oldCapacity < 64)?
                            ((oldCapacity + 1) * 2):
                            ((oldCapacity / 2) * 3));
...
[2] new PriorityQueue snippet:
...
         int newCapacity += (oldCapacity < 64) ?
                            oldCapacity : oldCapacity / 2;
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100309/acc9548e/attachment.html>