Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.oracle.com

Post reply on HN
Print view View original

61–70 of 133 posts

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

#61

Post by [deleted] »

layer8 wrote: post #54
xdavidliu wrote: post #48

> (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.) I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?

The article is very confused in general about multidimensional arrays (which are really just arrays of array references in Java). It’s badly written and IMO doesn’t deserve to be on the HN front page. The author seems to have expectations that Java multidimensional arrays violate, and seems to assume the reader would also have those expectations, but they just seem confused to me. Except for TFA’s mention of the byte…

[deleted]

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

#62

Post by ghusbands »

vbezhenar wrote: post #13
awelxtr wrote: post #2

> (Note that the comma after the last value is accepted in Java and won’t cause an error.) Why have I been 15 years programming in Java and I discovered this today? On a more serious note, I prefer this kinds of posts to the traditional "Look at this shiny new thing" because without fundamental stuff the next big thing can't be built and normally this information makes you a slightly better programmer.

I believe that comma thing was added recently.

You may be thinking of javascript, which has added various kinds of trailing comma over the years, though arrays had them from the start. See https://stackoverflow.com/a/67793166

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

#63

Post by kevincox »

xdavidliu wrote: post #48

> (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.) I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?

I think that it means the definition `int[2][3][4]` is effectively `((int[4])[3])[2]`, *not* `((int[2])[3])[4]`. So it declares an array of 2 (array of 3 (array of 4 ints))`.

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

#64

Post by cxr »

vbezhenar wrote: post #13
awelxtr wrote: post #2

> (Note that the comma after the last value is accepted in Java and won’t cause an error.) Why have I been 15 years programming in Java and I discovered this today? On a more serious note, I prefer this kinds of posts to the traditional "Look at this shiny new thing" because without fundamental stuff the next big thing can't be built and normally this information makes you a slightly better programmer.

I believe that comma thing was added recently.

[flagged]

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

#65

Post by samus »

alkonaut wrote: post #25
Pannoniae wrote: post #12

Earlier quoted context omitted.

No, I mean for the JVM.... the interface could remain the same but the pointer indirections could be avoided. I don't see the downsides, that's why I'm asking.

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.

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

#66

Post by ahoka »

aardvark179 wrote: post #20
Pannoniae wrote: post #3

What are the advantages of representing multidimensional arrays with pointers to arrays instead of a "flat" version where everything is stored contiguously and access is simply pointer arithmetic? EDIT: For the JVM, not manually. I'm asking about the internal representation, not a manual flattening by the user.

The JVM doesn’t really have multidirectional arrays, it just has arrays with a type, and that type may itself be an array. Sometimes that can be useful, and sometimes not.

https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.h...

This says otherwise.

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

#67

Post by bowsamic »

wffurr wrote: post #60
bowsamic wrote: post #58

Earlier quoted context omitted.

> The JVM doesn’t really have multidirectional arrays, it just has arrays with a type, and that type may itself be an array. That contradicts the article: > When the compiler encounters this code, it emits a unique bytecode, MULTIANEWARRAY, which creates an array with dimensions that are each set to the specified size.

Does that bytecode do anything more efficient than allocating arrays inside of arrays inside of arrays etc? Does it ensure they’re contiguous? Does a multidimensional array allocated in this way still require pointer chasing to get to the values? It’s not really a helpful statement. Initializing a single flat array with stride metadata alongside gives you memory locality and arithmetic access. Intuitively, I wouldn’t…

Well, /u/aardvark179 claimed that the JVM did not treat multidimensional arrays in any special way at all, i.e. that it is completely just a composition of features already available in the JVM, but that was wrong, since multidimensional arrays have their own special bytecode. Anything beyond that is irrelevant, I'm just correcting his mistake there.

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

#68

Post by samus »

tralarpa wrote: post #23
Pannoniae wrote: post #12

Earlier quoted context omitted.

No, I mean for the JVM.... the interface could remain the same but the pointer indirections could be avoided. I don't see the downsides, that's why I'm asking.

I guess it was just to simplify the original specification of the JVM (if two dimensional arrays are just arrays of arrays, you don't need special instructions for them). I can also imagine that the original JVM designers did not expect JIT compilers to one day become so good that the performance difference becomes relevant.

But there is actually a special bytecode instruction to create multidimensional arrays: MULTIANEWARRAY. My suspicion is that it allows a sufficiently sophisticated JVM to allocate all the memory required at once such that all of it is contiguous.

Also, the performance impact has nothing to do with the JIT. It follows from how indexes in contiguous vs. ragged arrays are computed. The JIT can't do much in this case apart from providing speedup by a constant factor. (Actually, it could do more if Java had true multidimensional arrays)

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

#69

Post by Izkata »

xdavidliu wrote: post #49
adrianmsmith wrote: post #14

Earlier quoted context omitted.

> Java arrays can have 0 dimensions The way you've phrased it is a bit ambiguous. Having 0 dimension sounds like x = new int[7][5]; // 2 dimensions y = new int[9]; // 1 dimension z = new int; // no dimensions, not an array, not allowed The phrasing you mean is "dimensions can have zero size".

Unfortunately the article author uses the exact same terminology: > (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.)

No, this is a quirk of the English language that I'm not sure how to describe generally. Best I can do:

"Dimensions" plural agrees with "zero" as a count, so that reads as "the count of dimensions is zero".

But they used singular "dimension" with "the" which treats "zero" as an adjective. It means "the dimension that is zero".

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

#70

Post by kaba0 »

nkh wrote: post #50
alex3305 wrote: post #4

In my experience, just a little bit of insider knowledge goes a long ways to making better code. Arrays are fun things, especially when you do a deep dive into the System.arraycopy() function. But the same goes for all Collections in Java. For instance, most of them have a default size (mostly 10), and growing them is a costly operation. So knowing beforehand how large your collection can or may be, can benefit code.…

Does anyone have any good book recommendations or links for insider knowledge of the JVM/Java? If Clojure focused all the better :)

There is JVM Anatomy Quarks.

I can also recommend reading the JVM specification itself, it is surprisingly not as dry as one might think, and not a novel, it’s a good read. Oh and of course anything written by Brian Goetz, usually about some new feature.

Post reply on HN