Here's the proposed fix for
6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int)
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isBMPCodePoint/
I changed the name to isBMPCodePoint in preparation for moving
it to Character.java.
(Sherman, perhaps you would like to take on that
On Tue, Mar 9, 2010 at 15:11, Ulf Zibis wrote:
> Can you explain the mystery about "+ 2" ?
It's exactly the same as the old resizing behavior.
Martin
Am 09.03.2010 23:08, schrieb Martin Buchholz:
On Tue, Mar 9, 2010 at 13:08, Ulf Zibis wrote:
[1] current PriorityQueue snippet:
...
int newCapacity = ((oldCapacity< 64)?
((oldCapacity + 1) * 2):
((oldCapacity / 2) * 3));
...
On Tue, Mar 9, 2010 at 13:08, Ulf Zibis wrote:
>
> [1] current PriorityQueue snippet:
> ...
> int newCapacity = ((oldCapacity < 64)?
> ((oldCapacity + 1) * 2):
> ((oldCapacity / 2) * 3));
> ...
> [2] new PriorityQueue snippet:
> ...
>
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 im
Am 09.03.2010 20:18, schrieb Martin Buchholz:
On Tue, Mar 9, 2010 at 03:59, Ulf Zibis wrote:
In PriorityQueue:
let's result newCapacity in 0x.FFFC =-4
then "if (newCapacity - MAX_ARRAY_SIZE> 0)" ---> false
then Arrays.copyOf(queue, newCapacity) ---> ArrayIndexOutOfBoundsException
It surely is not a good idea to use a single backing array
for huge arrays. As you point out, it's up to 32GB
for just one object. But the core JDK
doesn't offer a suitable alternative for users who need very
large collections.
It would have been more in the spirit of Java to have a
collection c
On Tue, Mar 9, 2010 at 03:02, Kevin L. Stern wrote:
> I did a quick search and it appears that Java is indeed two's complement
> based. Nonetheless, please allow me to point out that, in general, this
> type of code worries me since I fully expect that at some point someone will
> come along and
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^
On Tue, Mar 9, 2010 at 03:59, Ulf Zibis wrote:
> In PriorityQueue:
>
> let's result newCapacity in 0x.FFFC =-4
> then "if (newCapacity - MAX_ARRAY_SIZE > 0)" ---> false
> then Arrays.copyOf(queue, newCapacity) ---> ArrayIndexOutOfBoundsException
How could newCapacity ever become -4?
Since gr
Am 09.03.2010 12:02, schrieb Kevin L. Stern:
I did a quick search and it appears that Java is indeed two's
complement based. Nonetheless, please allow me to point out that, in
general, this type of code worries me since I fully expect that at
some point someone will come along and do exactly w
Please excuse me - Martin is saving an 'if' statement in the vast majority
of scenarios since, presumably, the overflow scenario occurs very
infrequently (given that the bug has been in place for quite awhile).
On Tue, Mar 9, 2010 at 5:02 AM, Kevin L. Stern wrote:
> I did a quick search and it ap
Sorry Martin, I appear to have missed your original request to file this
bug. I since filed the following:
6933217: Huge arrays handled poorly in core libraries
The changes you are proposing seem reasonable to me.
-Chris.
Martin Buchholz wrote:
[Chris or Alan, please review and file a bug]
I did a quick search and it appears that Java is indeed two's complement
based. Nonetheless, please allow me to point out that, in general, this
type of code worries me since I fully expect that at some point someone will
come along and do exactly what Dmytro suggested; that is, someone will
chang
In PriorityQueue:
let's result newCapacity in 0x.FFFC =-4
then "if (newCapacity - MAX_ARRAY_SIZE > 0)" ---> false
then Arrays.copyOf(queue, newCapacity) ---> ArrayIndexOutOfBoundsException
Am I wrong ?
2.) Why don't you prefer a system-wide constant for MAX_ARRAY_SIZE ???
-Ulf
Am 09.03
These comparisons are essential to the working of Martin's algorithm. I
found them interesting as well, but notice that when the capacity overflows
these comparisons will always be false. That is to say:
oldCapacity < minCapacity (given, otherwise we would not be resizing)
therefore oldCapacity
Is there any reason to use comparison like this
if (newCapacity - minCapacity < 0)
if (newCapacity - MAX_ARRAY_SIZE > 0) {
instead of
if (newCapacity < minCapacity)
if (newCapacity > MAX_ARRAY_SIZE) {
Thanks,
Dmytro
> Date: Mon, 8 Mar 2010 18:10:37 -0800
> Subject: Re: Bugs in java.util.Arr
17 matches
Mail list logo
