41–50 of 133 posts
Earlier quoted context omitted.
This choice probably pre-dates Oracle?
I think he's saying "how could he write that 0 length array is a surprising feature".
Earlier quoted context omitted.
I cannot for my life remember the argument order, so I write the manual code and let IntelliJ convert it.
Doesn't autocomplete show the arguments? I usually use Netbeans when I write Java, so no idea if InelliJ is just that bad.
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.
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.
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.
I was honestly hoping for a little more considering the title is "Inside the JVM" and not "Basic data structures in Java". Oh well...
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.
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…
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).
TLB?
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).
I must've read this sentence at least 7 times, but don't understand what this means. Can anyone illuminate?
Things I learned by reading this post * 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.
> 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".
> (It’s somewhat counterintuitive that the zero dimension is not the first one in the array.)
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.…