Proposal: Large arrays

james lowden jl0235 at
Tue Mar 24 11:03:02 PDT 2009

> I don't think the source compatibility impact is that
> large actually.  Let's say *all* arrays can potentially
> be 64-bit now.  The existing code that uses an int
> expression to index into the array will still index into the
> same element and negative indexes will still cause an
> exception.  Now, how should the length field be set? 
> I'd guess it should saturate to Integer.MAX_VALUE for
> oversize arrays and a new "long size()" method
> could be added to return the full length.

This I'd actually prefer over what I proposed (and, based on the response so far and the previous bug, what others would probably like as well); my main concern was not breaking the int "length" field; I'd slightly prefer the long size to be a field rather than a method, but that may just be due to that being how I'm used to obtaining the array size; if there's a compelling reason to use a method rather than a field for this, I'd be curious to hear it.

> The JVM would need to be modified to handle the long
> indexes of course; perhaps the wide bytecode prefix could be
> put to use here.

Looking at wide, it looks like applying it to the existing array instructions would be an option; I would favor that approach over my original idea, which chews up a whole slew of opcodes.

I'll probably stew on the various suggestions for a while, and send out a revised version of the proposal.



More information about the coin-dev mailing list