Live data from Hacker News

Inside the JVM: Arrays and how they differ from other objects

blogs.oracle.com

131–133 of 133 posts

Re: Inside the JVM: Arrays and how they differ from other objects

#131
post #65

Earlier quoted context omitted.

It just means you don't have to special case any particular scenario such as array-of-array, it's no different than array-of-whatever. Also jagged arrays form a complication. But even for the simple case of large non-jagged arrays: In the situation where you needed this perf gain as a developer you would still need to be able to specify the order e.g. row-major or column-major, since the VM won't know your access pat…

This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.

Yes, but you'd have a whole set of additional data (number of dimensions e.g. 2 and then the order of access for those dimensions). And that would affect the size of every array instance, which is something you really don't want. Or the compiler would need to keep track of it on the type level so that a row-major array can't be passed where a column major is expected etc. In any case it would really make the APIs overly complicated.

Re: Inside the JVM: Arrays and how they differ from other objects

#132
post #65

Earlier quoted context omitted.

This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.

Yes, but you'd have a whole set of additional data (number of dimensions e.g. 2 and then the order of access for those dimensions). And that would affect the size of every array instance, which is something you really don't want. Or the compiler would need to keep track of it on the type level so that a row-major array can't be passed where a column major is expected etc. In any case it would really make the APIs ove…

It would be 4 byte more per array for metadata, plus the sizes. It would actually require less memory than ragged arrays, which have to record the size in each subarray.

API complexity could be handled by a polymorphism mechanism to make it possible to write code that is generic regarding row/column access order.

Re: Inside the JVM: Arrays and how they differ from other objects

#133
post #40
post #29

Earlier quoted context omitted.

I cannot for my life remember the argument order, so I write the manual code and let IntelliJ convert it.

Doesn't autocomplete show the arguments? I usually use Netbeans when I write Java, so no idea if InelliJ is just that bad.

It shows the argument names and even highlights the current one where the cursor is. But sometimes my thought process is just different.
Post reply on HN