Inside the JVM: Arrays and how they differ from other objects
blogs.oracle.com
blogs.oracle.com
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.
"A trailing comma may appear after the last expression in an array initializer and is ignored"
https://titanium.cs.berkeley.edu/doc/java-langspec-1.0/10.do...
Why? Because whenever there's a new value added, git diff shows single line change :)
function foo(x,) {}
def foo(x,): pass
function foo(
a,
b,
c,
) {}Also, last I remember in JS a trailing comma meant the creation of an extra array element that’s null so I became conditioned to only use trailing commas for separators in languages where it’s consistent and specified very explicitly like in HCL
w = 0, # w == (0,)
(x) = (0,) # x == (0,)
y, = 0, # y == 0
(z,) = (0,) # z == 0
I recommend everyone that uses a managed language (Java, C# or others) to at least get a basic understanding of these fundamentals. And also know which collection type to use when.
For better or worse, it shows me that the author isn't that into Java.
It's C memcpy() that's the odd one out by putting the destination before the source.
Even though I find memcpy and friends to be perfectly logical using the assignment analogy suggested by thwarted, I often need to re-read english sentences written that way.
The worst thing is, that System.arraycopy() is an optimized JNI call which is much faster than copying it by hand [1].
> For better or worse, it shows me that the author isn't that into Java.
The thing is though, most of the time arrays in Java are used because of performance. Or maybe ignorance. Because why would anyone voluntarily give up all the comforts of a List<T>? It's not that Collections are very hard to find in the documentation. And most of the IntelliJ suggest switching to a Collection anyway.
1. https://www.javaspecialists.eu/archive/Issue124-Copying-Arra...
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).
TLB?
In short and a bit simplified, normally when you allocate memory, the allocator needs to synchronize between threads because RAM is a shared resource. This means that a thread that allocates a lot can disrupt the performance of other threads, among other weird effects. But there's a small buffer called the TLAB owned by each thread where this isn't true: Allocation in the TLAB doesn't require synchronization. The TLAB makes allocating small ephemeral objects much faster.
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.
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.
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.
It is sometimes really tricky. When I worked with streaming XML documents that were gigabytes in size, there is a really fine margin you have to work with.
However some general knowledge can be pretty useful. I saw colleagues just do "= new ArrayList<?>(1000);" without considering the collection type or possible size. And besides being a bit ignorant, it can also be really confusing for other developers that take first look at such code.
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.
In addition I really enjoyed exploring the JDK documentation. Especially Java <1.7 is extremely manageable. Java 8 introduced NIO and lambda's which make Java way more fun, but also a tad harder to learn.
It's not exactly JVM, but just wanted to share anyway :).
* Java arrays can have 0 dimensions
* When declaring arrays, trailing comma is allowed after the last element
* In multi-dimensional arrays, only the last dimension contains actual values. Other dimensions are just pointers to arrays.
Good read.
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
> (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.)
"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".
Out of curiosity, how do you rate each of:
"Arrays can have a zero dimension."
"Arrays can have two zero dimensions."
"Arrays can have some zero dimensions."
"Arrays can have zero dimensions."
in this regard?
So yeah, my description above is a bit off, I guess it's the articles that do it? Is "some" considered an article?
A two-dimensional (int[x][y] not int[]...[2]...[]) "array of" int isn't really a array of ints either - it's a array of arrays of int. So a zero-dimensional "array of" int is a int.
I'd call the last one ambiguous: it's either a group of (dimensions that are zero), or a (group of dimensions) that is [of group size] zero, and the text doesn't provide enough information to know which without context, just like "I read books." when you don't whether someone's talking about their hobbies or what they did over the summer.
I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?
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 bytecode instructions and trailing comma, the classic tutorial article is much better: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/ar...
“For example,
strangePoints = new int[3][4][0][2]
In this declaration, all dimensions after the zero-size dimension are ignored. So, the result of this declaration is equivalent to a two-dimensional array of ints.”
This is just plain wrong. It’s a four-dimensional array of ints, just one that cannot contain more than zero ints, because one of the dimensions is zero.
To illustrate,
int[][] a = strangePoints[0][0];
int b = strangePoints[0][0];
The talk about Object having no size() method and arrays having therefore a length field is also confused. Arrays have distinct types (and classes, in the sense of getClass()), and therefore could very well have a size() method. It’s merely a stylistic choice of Java that they opted for the simpler .length syntax.
The article is so misguided as to be harmful.
> Object having no size() method and arrays having therefore a length field is also confused. Arrays have distinct types (and classes, in the sense of getClass()), and therefore could very well have a size() method. It’s merely a stylistic choice of Java that they opted for the simpler .length syntax.
What's the "confused" part? Again, my description is accurate and you're simply saying that Java could have chosen a different way to do the same thing, but decided not to.
[0] https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-6.h...
What is stated is: “If any count value is zero, no subsequent dimensions are allocated.” This is mostly just for clarification, because what could the alternative possibly be? It is equivalent to saying that count subarrays are allocated, which when count is zero, of course means that none are allocated. Again, what would the alternative possibly be?
Furthermore, strangePoints.getClass() results in `[[[[I` (so it’s not just syntactical, it’s the actual runtime type), i.e. a four-dimensional array of ints, and not a two-dimensional array of ints as the article claims.
What is true is that what is allocated is a two-dimensional array, but it is an array of empty arrays, not of ints. For example, the expression strangePoints[0][0].length is valid (and yields 0), whereas it wouldn’t be valid for a two-dimensional array of ints. And again that’s on the JVM level, because otherwise the ARRAYLENGTH operation wouldn’t work here. Furthermore, strangePoints[0][0].getClass() of course is valid as well and yields `[[I`, showing that the element type of the two-dimensional array is another two-dimensional array (of ints), and not int.
> What's the "confused" part?
The confused part is this: “Many Java collections have a method called size(), which returns an integer stating the number of elements in the collection. Arrays have no such method. There are several reasons for this, but the principal one is that arrays are simple Object instances—they are not collections. The Object class has no size() method, so arrays don’t either.”
There is no reason why array objects couldn’t have a size() method even though Object doesn’t. Invoking getClass() on an array doesn’t return Object.class, but a subclass of that, and those subclasses could have the additional size() method.
This is also wrong: “Eagle-eyed readers of my earlier statement about length being a field rather than a method call might wonder how a direct subclass of Object would have a field called length to begin with, as Object has no such field.” Arrays don’t have a length field, as calling .getClass().getFields() (or getDeclaredFields()) on an array shows. The .length property is mere syntax, much like .class on an object type. But, again, Java/the JVM could have chosen to imbue array classes with a fully-fledged size() method.
The key part comes a bit later:
> The components of the last !!allocated!! dimension of the array are initialized to the default initial value (§2.3, §2.4) for the element type of the array type.
Since the last allocated dimension is the one that has zero count... well, that means each component (of which there are none) is initialized to a value of type `int`, so technically speaking, the type of each component (of which there are none) is `int`. Due to the rest of the spec, that means the type of the dimension before that is `int[]`; and that's how you arrive at the conclusion of TFA.
It's quirky, and a semantic argument at best, and certainly not worth fighting over here on HN.
"Arrays, however, have a property called length, which can be queried to get the number of elements in the specified array."
This is not correct and causes bugs. Length is the length of the array, not the number of elements within it. Maybe the author understands this, but precision of language is important here and as-written this is either ambiguous at best or incorrect at worst.
Also the entire section for "Array size and the concept of arrays of arrays" is terribly confused. Again I'm not sure if this is imprecise use of language or if the author is truly this confused about the topic, but:
"As you can see, what you have is truly three arrays, working together to create the equivalent of a three-dimensional array."
No, in the naive case of "new int[M][N][10]" you have 1 + M + MN arrays. And if you are working with only the type int[][][], just checking arr.length, arr[0].length, and arr[0][0].length will not give the the dimensions of the 3d array - any of the arrays can be of any length (the length of the array is not part of the type system).
And I feel like I'm not nitpicking here - note some algorithms, like DP ones for instance, only use a "diagonal" half of a 2d array and allocating the other half would be wasted space. So it's very possible you'll encounter such non-trivially-shaped 2 and 3D arrays in practice.
"Here’s an interesting question: What would happen in a multidimensional array if one of the dimensions were declared with a size of 0? For example,
strangePoints = new int[3][4][0][2]"
This was a TIL to me though, I'm kind of surprised this doesn't throw at runtime? But also, I suppose, not surprised. It's weird because, is int[3][4][0][2] really* an int[][][][]? I guess it's not not an int[][][][] but it's also kind of weird that it is. I guarantee this has caused a bug at some point. This would be a cursed interview question.
EDIT: For the JVM, not manually. I'm asking about the internal representation, not a manual flattening by the user.
Puting data in a structure that mirrors the real thing normally helps when trying to understand it
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)
Oh, I didn't know that. Weird. IIRC there are no corresponding special instructions for accesses to multidimensional arrays.
> Also, the performance impact has nothing to do with the JIT
What I meant: The authors didn't expect that the JIT compiler would become so good in compiling the bytecode, that the performance difference between contiguous vs. ragged arrays actually becomes relevant.
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.
API complexity could be handled by a polymorphism mechanism to make it possible to write code that is generic regarding row/column access order.
int[][] x = new int[2][];
x[0] = new int[] { 1, 2, 3 };
x[1] = new int[] { 1, 2, 3, 4 };Sometimes that can be useful, and sometimes not.
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.
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 expect the special multidimensional array bytecode to provide any of that.
“A new multidimensional array of the array type is allocated from the garbage-collected heap. If any count value is zero, no subsequent dimensions are allocated. The components of the array in the first dimension are initialized to subarrays of the type of the second dimension, and so on. The components of the last allocated dimension of the array are initialized to the default initial value (§2.3, §2.4) for the element type of the array type. A reference arrayref to the new array is pushed onto the operand stack.”
It’s really a little utility method that happens to be pushed all the way to the byte code for historical reasons. The arrays it produces aren’t multidimensional in the ways you might hope, they are just arrays of arrays, which remain mutable and so can become ragged, or be reassigned in sneaky or horrible ways (e.g. with a subtyped array).
There has been lots of talk over the years about how we could do better, often motivated by projects like Panama which are concerned with interfacing with other languages which do have firmer concepts of multidimensional arrays, but these are generally at a slightly higher level and try to avoid messing with lower level things the VM has to know about.
This says otherwise.
long[][] foo = new long[2][];
foo[0] = new long[5];
foo[1] = new long[3];
// ...
foo[0] = new long[7];
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.
And nobody can give a good reason why String#length(), Array#length, and Collection#size() are all spelled differently, but if pressed, they'll use 'special bytecodes!' as an excuse.
A string has a length, because it counts the number of characters, which can have different sizes.
Both arrays and strings represent a 1-dimensional string or away of things.
Collections have sizes, because collections are more generic. Would a binary tree have a length? Maybe.. but it’s ambiguous and in most cases not correct
Like when Rasmus couldn't stick to a naming convention for PHP functions, and it turned out to be because he couldn't be bothered to write a decent hash function. So everyone who uses the language from now to forever has to memorize this inconsistent naming scheme because the language designers couldn't get their shit together. Yeah, I get it; sometimes it's hard to foresee these things from the beginning. But it annoys me when people make up excuses for these inconsistencies that don't hold water instead of just admitting that someone messed up.
> 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 stuff" and it needs to be an array, not an ArrayList say (maybe it's an array of bytes). If there's no stuff, you get a zero-length array of course. The myriad foo.toArray(...) functions in Java's library do this for example.
> create an array and then discover there are no values to place in it.
I mean you can't change the size of an array after you've created it, so if you create an array with a certain size intending to put values in it, then discover there aren't any values, you've still got a non-zero size array...
CL-USER 9 > (make-array 0 :adjustable t :fill-pointer 0)
#()
CL-USER 10 > (vector-push-extend 'foobar *)
0
CL-USER 11 > **
#(FOOBAR)> comfortable making zero-length simple-vectors
Btw., CL allows also zero-dimensional arrays:
CL-USER 3 > (make-array '())
#0ANILNot in Java, no.
An ArrayList is an object which represents a variable length random-access list and does not support basic types (int, double etc.) An array is fixed-length and supports basic types. It is not an object per se.
The closest analog to an ArrayList in Lisp is an extensible vector, and the closest analog to an array is a simple-vector.
> Btw., CL allows also zero-dimensional arrays:
As any decent language would!
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.
Would be happy to be proven wrong.
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.
You implied before that there are major JDK distributions which are not based on OpenJDK, but these two examples do not show that: these are niche JDKs.
A JVM is a JVM, regardless of deployment scenarios and who gets to use them.
I am not moving goal posts, I am just saying that a JVM specializing on embedded devices is not a JDK most people would use, only a small number of niche applications... so you haven't shown anything other than there are alternative JDKs available for niche applications, which I agree with! But I was saying that all JDKs people working on most applications rely on are based on OpenJDK. If you want to include a niche JDK for embedded devices, fine, but that's not what I or most people would care about, I would think.
It would be more pleasant to discuss with you if you expressed yourself a bit more like an adult (even if you're still a teenager which I am guessing is the case), by the way...