Re: 64 bits
Kevin McMurtrie wrote:
It's a very dumb decision. Sun is building their own coffin if they
think that power users don't need true 64 bit memory yet. If you need
fast random access in very large data sets, doing it in RAM is far
I don't have any need for this myself. However I do agree that it seems
short sighted.
(I am curious what sorts of things you need more than 2^31 of, that
wouldn't be better suited to a database which was then configured to
hold it's tables in-memory. This does seem more flexible.)
Anywhoo, I also would like to see some ideas besides just "an array."
Contiguous data could be very hard to work with in some cases (for a
particular OS, for example), I think. An external package (not part of
the basic API) that could be used when needed would be better than an
addition to the basic API that then must be supported on all platforms.
I wonder if there's already one out there. But of course actually
supporting such a thing until there's a JVM that supports more than 2G
of RAM might be moot.
A little thought to concurrency might be good here too. The default
mechanism of locking an entire Collection (via synchronized Collection
interface) might not really be a good idea for such large data structures.