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

81–90 of 133 posts

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

#81

Post by nayuki »

gdprrrr wrote: post #29
pjmlp wrote: post #19

Earlier quoted context omitted.

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.

In Java, it's src array, src offset, dest array, dest offset, length. It's a natural order of from, to.

It's C memcpy() that's the odd one out by putting the destination before the source.

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

#82

Post by enterprise_cog »

thfuran wrote: post #78
enterprise_cog wrote: post #76

Earlier quoted context omitted.

Yet, somehow I doubt you write perfect code in all those languages. Do you cringe at yourself and conclude you just don’t care also?

There are more options than "write perfect code" and "not even attempt to learn how to write idiomatic code".

Yeah, of course. But maybe you should just be happy to share knowledge with those lacking it, rather than cringing and making some kind of personal judgement of them.

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

#83

Post by thwarted »

nayuki wrote: post #81
gdprrrr wrote: 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.

In Java, it's src array, src offset, dest array, dest offset, length. It's a natural order of from, to. It's C memcpy() that's the odd one out by putting the destination before the source.

memcpy argument order matches the left-to-right arrangement of assignment. lhs=rhs is rhs is copied to lhs. memcpy(lhs,rhs) is the contents at rhs is copied to lhs.

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

#84

Post by agilob »

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.

Read a book on preparing for Java SE Certification, the exam is full of questions about things like this

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

#85

Post by suresk »

marginalia_nu wrote: post #28
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).

It's one of those things where you usually have to let profiling and other observations guide your approach. 99.9% of the time it doesn't really matter and the default behavior is fine. But I can think of a few times where this has been a big deal.

One in particular - I was profiling an application with low-latency needs and GC was taking up a ton of time. Mission control showed tons of allocations of arrays - at one point it was creating a bunch of lists in a loop and adding stuff to them, which triggered creating a new underlying array. We found that a) Many of the arrays were just over the first resizing size, and b) There was a good heuristic that we could use to give them an initial size that would never have to be expanded and wouldn't result in huge amounts of waste.

This had a pretty dramatic effect on our GC times and the overall latency. I think this is where the JVM really shines - tons of tooling to help you profile and observe these kinds of details to help you figure out when you actually need to care about stuff like the initial array capacity.

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

#86

Post by hajile »

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.

It is a bit more flexible would be my guess.

On the flip side, separate arrays and pointers should be slower on modern CPUs because the multiplication will be faster than the cache misses from jumping around in memory.

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

#87

Post by marginalia_nu »

suresk wrote: post #85
marginalia_nu wrote: post #28

Earlier quoted context omitted.

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

It's one of those things where you usually have to let profiling and other observations guide your approach. 99.9% of the time it doesn't really matter and the default behavior is fine. But I can think of a few times where this has been a big deal. One in particular - I was profiling an application with low-latency needs and GC was taking up a ton of time. Mission control showed tons of allocations of arrays - at one…

Depends a lot on what you're doing too. I do a fair bit of heavy data processing work with my search engine (tokenizing something like a billion documents into arrays of words etc), and allocator contention has a pretty huge performance impact for that type of work.

My intuition is that the best thing is to aim for the expected median size, rather than the maximum as one might assume would be the most performant. The maximum strategy minimizes re-allocations, but at the expense of always making costlier allocations.

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

#88

Post by suresk »

marginalia_nu wrote: post #87
suresk wrote: post #85

Earlier quoted context omitted.

It's one of those things where you usually have to let profiling and other observations guide your approach. 99.9% of the time it doesn't really matter and the default behavior is fine. But I can think of a few times where this has been a big deal. One in particular - I was profiling an application with low-latency needs and GC was taking up a ton of time. Mission control showed tons of allocations of arrays - at one…

Depends a lot on what you're doing too. I do a fair bit of heavy data processing work with my search engine (tokenizing something like a billion documents into arrays of words etc), and allocator contention has a pretty huge performance impact for that type of work. My intuition is that the best thing is to aim for the expected median size, rather than the maximum as one might assume would be the most performant. The…

I think it depends a lot on the other details, especially how expensive the extra GC will be vs the wasted space. Hard to give a rule that will work in all contexts.

In our case, it wasn't a single hard-coded number - the input data gave us the upper bound, and the difference between the upper bound and the median case was so small that going with the upper bound worked out best.

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

#89

Post by tom_ »

nayuki wrote: post #81
gdprrrr wrote: 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.

In Java, it's src array, src offset, dest array, dest offset, length. It's a natural order of from, to. It's C memcpy() that's the odd one out by putting the destination before the source.

British people generally don't, but Americans very often use "to...from".

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

#90

Post by brabel »

pjmlp wrote: post #43
brabel wrote: post #35

Earlier quoted context omitted.

As far as I know, all those distributions use OpenJDK for that kind of stuff and don't really do much more than apply a few patches here and there, not change stuff like how the JVM packs bytes in memory. Would be happy to be proven wrong.

IBM OpenJ9 uses a mix of OpenJDK and their J9 toolchain. Azul uses parts of OpenJDK, alongside their JIT Falcon infrastructure. Microsoft OpenJDK based distribution has better escape analysis than regular one, although OpenJDK 22 should have those improvements merged. And no, not all of them use OpenJDk, it is an urban myth, as usual.

That would be much more convincing if you linked to a proper JDK distribution that's not based on the OpenJDK.
Post reply on HN