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

21–30 of 133 posts

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

#21

Post by SeanLuke »

pjmlp wrote: post #18
SeanLuke wrote: post #9

I was pretty disappointed that, for a blog called "Inside the JVM", very little in the blog entry discussed goings on inside the JVM. For example, when does the JVM typically optimize away bounds or null checks? How are arrays of booleans packed and what is their efficiency compared to arrays of bytes or words?

For that you need an Inside Hotspot, Inside OpenJ9, Inside GraalVM, Inside Azul, Inside ART, Inside microEJ, Inside PTC, Inside JamaicaVM, Inside.... Otherwise is like trying to discuss what does a C compiler do, when only looking through the lens of the C abstract machine in ISO C.

This is an Oracle blog, and it's called "Inside the JVM". What VMs do Oracle build besides Hotspot and its ilk?

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

#22

Post by stefs »

SeanLuke wrote: post #21
pjmlp wrote: post #18

Earlier quoted context omitted.

For that you need an Inside Hotspot, Inside OpenJ9, Inside GraalVM, Inside Azul, Inside ART, Inside microEJ, Inside PTC, Inside JamaicaVM, Inside.... Otherwise is like trying to discuss what does a C compiler do, when only looking through the lens of the C abstract machine in ISO C.

This is an Oracle blog, and it's called "Inside the JVM". What VMs do Oracle build besides Hotspot and its ilk?

as far as i know, graalvm is also an oracle project

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

#23

Post by tralarpa »

Pannoniae wrote: post #12
awelxtr wrote: post #7

Earlier quoted context omitted.

Maintenance, probably. Puting data in a structure that mirrors the real thing normally helps when trying to understand it

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.

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

#24

Post by keyle »

SeanLuke wrote: post #5

> Another curiosity of Java arrays is that they can have a size of zero. > This code will not result in an error message. This surprising feature is used primarily by code generators, which might create an array and then discover there are no values to place in it. What? How can someone at Oracle have written this? Zero-length arrays are used all the time when you call a function asking for an array of "the latest st…

This choice probably pre-dates Oracle?

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

#25

Post by alkonaut »

Pannoniae wrote: post #12
awelxtr wrote: post #7

Earlier quoted context omitted.

Maintenance, probably. Puting data in a structure that mirrors the real thing normally helps when trying to understand it

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 pattern.

So if you make your own matrix class you would be better off storing a flat array yourself and doing the access arithmetic yourself like index = y*cols + x. It would be a pretty cumbersome API in Java if they had this in the declaration api and you declared double[100][100] how would you declare whether that 10k flat array is row major or column major? If the VM gets it wrong for your access pattern then a lot of the perf gain from fewer pointer indirections will be eaten by cache misses from looking in the wrong order.

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

#26

Post by wolf550e »

SeanLuke wrote: post #9

I was pretty disappointed that, for a blog called "Inside the JVM", very little in the blog entry discussed goings on inside the JVM. For example, when does the JVM typically optimize away bounds or null checks? How are arrays of booleans packed and what is their efficiency compared to arrays of bytes or words?

You want something like https://shipilev.net/jvm/anatomy-quarks/ (the author is a jvm maintainer, formerly at redhat now at aws).

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

#27

Post by twic »

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.

The comma thing is inherited from C and has always been there. Newer bits of array-like syntax, like varargs and array literals in annotations, do not allow trailing commas.

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

#28

Post by marginalia_nu »

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.…

> 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.

It's really a tricky balance. Over-allocating collections "just in case" can quite often be very expensive as well, since large array allocations tend to be fairly slow (since e.g. they typically won't fit in the TLAB).

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

#29

Post by gdprrrr »

pjmlp wrote: post #19
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.…

I cringe every single time I see a for loop for what System.arraycopy () has been providing since early days. For better or worse, it shows me that the author isn't that into Java.

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

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

#30

Post by dzaima »

pjmlp wrote: post #19
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.…

I cringe every single time I see a for loop for what System.arraycopy () has been providing since early days. For better or worse, it shows me that the author isn't that into Java.

Or it might be that the person has used multiple programming languages, across which the order/meaning of copy arguments varies a lot, and thus prefer to not remember the decision of each language (if not for writing (at which point the IDE could help), then for reading). Whereas a loop is always easy to read and write equally in all languages, and it's really not unreasonable to expect it to perform well enough (if not as good as System.arraycopy, then at least good enough to be insignificant compared to the actual important logic in the code).
Post reply on HN