You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Juozas Baliuka <ba...@mail.lt> on 2002/08/16 09:04:29 UTC
[Collections] Map.size problem on 64 bit JVM
Hi,
Some map implementations in [Collections] use int field to store map size
(SUN's implementations has the same problems too)
I am not 64 bit JVM user, but I believe it is always sizeof(int) == 32/8 in
JAVA.
It is not a problem on 32bit JVM, because it will throw OutOfMemoryError
first,
but it is possible to have negatyve map size on 64 bit JVM.
Map documentation says size must be in range : 0 <= size <= Integer.MAX_INT
The most trivial solution is to use "long" field to store map size and to
return
MIN(size, Integer.MAX_INT); It will be problem for 128 bit JVM in the
future :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Map.size problem on 64 bit JVM
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
sorry if I cofused you, it is not platform specific, it is a bug, but it is
impossible
to reproduce it on 32 bit JVM. 64 bit JVM can use "more" memory and
map size can become negative integer value. Very possible it is not a big
problem, yust a bug.
----- Original Message -----
From: "Michael A. Smith" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, August 16, 2002 3:35 PM
Subject: Re: [Collections] Map.size problem on 64 bit JVM
> Juozas Baliuka wrote:
> > Hi,
> > Some map implementations in [Collections] use int field to store map
size
> > (SUN's implementations has the same problems too)
>
> don't see that as a "problem".
>
> > I am not 64 bit JVM user, but I believe it is always sizeof(int) == 32/8
in
> > JAVA.
>
> I don't know what the 32/8 is supposed to mean, but the JVM
> specification specifices that an int is always 32 bits (4 bytes) and a
> long is always 64 bites (8 bytes). Doesn't matter what platform you are
on.
>
> > It is not a problem on 32bit JVM, because it will throw OutOfMemoryErro
> > first,
>
> huh?
>
> > but it is possible to have negatyve map size on 64 bit JVM.
>
> it would be possible to have a negative map size an a 32-bit VM too if
> the size field overflows... doesn't matter what platform you are on.
>
> > Map documentation says size must be in range : 0 <= size <=
Integer.MAX_INT
>
> ok, I believe Collection.size() says the same thing, but I'm too lazy to
> check.
>
> > The most trivial solution is to use "long" field to store map size and
to
> > return
> > MIN(size, Integer.MAX_INT); It will be problem for 128 bit JVM in the
> > future :)
>
> I still don't see why the platform makes many difference. how does that
> matter? And honestly, I don't see this size overflow "problem" as much
> of a problem.
>
> michael
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Collections] Map.size problem on 64 bit JVM
Posted by "Michael A. Smith" <ma...@apache.org>.
Juozas Baliuka wrote:
> Hi,
> Some map implementations in [Collections] use int field to store map size
> (SUN's implementations has the same problems too)
don't see that as a "problem".
> I am not 64 bit JVM user, but I believe it is always sizeof(int) == 32/8 in
> JAVA.
I don't know what the 32/8 is supposed to mean, but the JVM
specification specifices that an int is always 32 bits (4 bytes) and a
long is always 64 bites (8 bytes). Doesn't matter what platform you are on.
> It is not a problem on 32bit JVM, because it will throw OutOfMemoryErro
> first,
huh?
> but it is possible to have negatyve map size on 64 bit JVM.
it would be possible to have a negative map size an a 32-bit VM too if
the size field overflows... doesn't matter what platform you are on.
> Map documentation says size must be in range : 0 <= size <= Integer.MAX_INT
ok, I believe Collection.size() says the same thing, but I'm too lazy to
check.
> The most trivial solution is to use "long" field to store map size and to
> return
> MIN(size, Integer.MAX_INT); It will be problem for 128 bit JVM in the
> future :)
I still don't see why the platform makes many difference. how does that
matter? And honestly, I don't see this size overflow "problem" as much
of a problem.
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>