I was honestly hoping for a little more considering the title is "Inside the JVM" and not "Basic data structures in Java". Oh well...
Inside the JVM: Arrays and how they differ from other objects
51–60 of 133 posts
Re: Inside the JVM: Arrays and how they differ from other objects
#52I was honestly hoping for a little more considering the title is "Inside the JVM" and not "Basic data structures in Java". Oh well...
Re: Inside the JVM: Arrays and how they differ from other objects
#53Earlier 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).
> TLAB TLB?
Re: Inside the JVM: Arrays and how they differ from other objects
#54> (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 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...
Re: Inside the JVM: Arrays and how they differ from other objects
#55> (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?
Re: Inside the JVM: Arrays and how they differ from other objects
#56Earlier 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).
> 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.
Re: Inside the JVM: Arrays and how they differ from other objects
#57> (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…
“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];
will typecheck while int b = strangePoints[0][0];
will not (which however it should if the author’s claim that strangePoints is a two-dimensional array of ints was true).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.
Re: Inside the JVM: Arrays and how they differ from other objects
#58What 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.
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.
Re: Inside the JVM: Arrays and how they differ from other objects
#59> (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.
Re: Inside the JVM: Arrays and how they differ from other objects
#60Earlier 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. Sometimes that can be useful, and sometimes not.
> 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.
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.