Re: 2 GIG the new 640 MB

In comp.lang.java.advocacy, Roedy Green
<my_email_is_posted_on_my_website@xxxxxxxxxxxxxx>
wrote
on Mon, 16 Jan 2006 11:49:11 GMT
<lo1ns15nn77e48oc9s9focf1a263fnbrnj@xxxxxxx>:
> On Mon, 16 Jan 2006 00:06:19 -0800, Peter Ammon
> <gershwin@xxxxxxxxxxxxxxx> wrote, quoted or indirectly quoted someone
> who said :
>
>>But that doesn't mean that Java is automatically "64 bit ready" or ideal
>>for 64 bit computers. For example, the length property of an array in
>>Java is a 32 bit int even on a 64 bit machine - that means that no Java
>>program will ever be able to create an array with more than 4 billion
>>elements. Java will need to undergo a transition to 64 bit like any
>>other framework out there.
>
> I think that could go very smoothly. From the language level all you
> have to do is relax the restriction on using longs in new [ ... ]. You
> can continue to use ints even in a 64 bit system.
>
> In the JVM, the new 64 bit array might be implemented with 32-bit or
> 64-bit code depending on how you allocated it.
>
> the biggest problem is with array.length. Perhaps logically
> autocasting it back to int when required. Perhaps there would be two
> length commands, one int pseudofield length and a method length() that
> gets a long.
>
> It not nearly so frightening as adjusting your pointer arithmetic to
> account for different sizes of items.

Eh? C has had autoadjusting pointer arithmetic for decades.
Briefly put, if one declares

char * p[32];

char **q;

q = p + 3;

then C automatically does the right thing. The main problem
with C is stuff like

struct {
char * p;
char * q;
} r;

fwrite(&r, 1, sizeof(r), fp);

which has multiple problems, or the old and no longer useful

fprintf("0x%08x\n", (int) q);

which has been replaced by

fprintf("%p\n", q);

and gcc will elicit a warning in the former case, letting the
user know of the inconsistency.

C++ has inherited many of C's problems although it can hide
them with smart pointers and such; one can also overload
the 'operator<<(ostream &) const' method for classes to write
themselves properly. ('operator>>(istream &)' does the read.)

Java doesn't even see pointers -- unless one looks carefully.
Nor does persistence in Java expose pointers that much, though
I'd have to look at the RMI format to be entirely sure.

I don't see Java usage models changing, though there might be
issues internally in the JVM.

You could, of course, be referring to the problems with
gigantic arrays, sparse or otherwise, which are greater
than 2 billion slots in length. It wouldn't take much --
a 65536 x 65536 cell array would yield a 4-billion-pixel
raster, overloading many consumer machines RAMwise.

--
#191, ewill3@xxxxxxxxxxxxx
It's still legal to go .sigless.
.

Relevant Pages