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

111–120 of 133 posts

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

#111

Post by vbezhenar »

cxr wrote: post #75
vbezhenar wrote: post #71

Earlier quoted context omitted.

Did you ask yourself this question before you wrote this comment?

To answer your question: no, I didn't. It doesn't make sense to—I'm not here saying anything like, "I believe it's because X" without knowing whether X is true or not. If you think otherwise, explain how. (I have now answered your question. If you respond, how about doing so in the form of an answer to mine—and not evading it with another question?)

I bothered to comment because I write Java for 15 years and I thought that my knowledge was relevant to this topic. I’m not going to check every my comment with reference documentation. In this particular case my memory failed me and I was quickly corrected and downvoted, so no harm was done, I guess, other than few people spending few minutes, for which I feel sorry, but not very much.

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

#112

Post by nisse72 »

tom_ wrote: post #89
nayuki wrote: post #81

Earlier quoted context omitted.

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

They do, and it's jarring!

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.

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

#113

Post by wging »

marginalia_nu wrote: post #56
NavinF wrote: post #46

Earlier quoted context omitted.

> TLAB TLB?

The TLAB is the Thread Local Allocation Buffer. 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 t…

This is a good explanation. See also Shipilev's JVM Anatomy {Park|Quark} episode: https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/

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

#114

Post by enterprise_cog »

pjmlp wrote: post #105
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?

No I don't, and when someone cringes looking at my code, I shut up, apply the fix and get to improve my skills on the language, instead of excusing myself.

So you agree you should be judged as someone who doesn’t care in those cases also, right? You didn’t mention anything about people excusing themselves initially, just that you judged them. I just hope you hold yourself to the same standard.

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

#115

Post by brabel »

pjmlp wrote: post #106
brabel wrote: post #90

Earlier quoted context omitted.

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

Like on street markets, we are having bonus today, and you get two for the price of one. https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/

Both of these are meant for embedded development only.

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.

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

#116

Post by SeanLuke »

andrewbinstock wrote: post #97
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…

Author here. Zero-length arrays are used in the narrow domain you mention. but they are rare in bread-and-butter Java programming. Given some of the other comments on this page, you can see that this aspect is new to multiple readers. And in my experience speaking to Java devs, the reaction of surprise is far more common than "of course, I use them."

Thing is, practically every modern programming language has zero-length arrays or lists. This is derived from Lisp, which had zero-length arrays (and of course zero-length lists). It's not at all surprising. What ought to be surprising is that among languages developed in the last 40 years, C++ almost uniquely does not have them. I use zero-length arrays all the time in my coding, as does everyone I know. I think they're probably much more common than you imagine.

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

#117

Post by alex3305 »

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 really a tricky balance. Over-allocating collections "just in case" can quite often be very expensive as well

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.

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

#118

Post by alex3305 »

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 cringe every single time I see a for loop for what System.arraycopy () has been providing since early days.

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

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

#119

Post by alex3305 »

nkh wrote: post #50
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.…

Does anyone have any good book recommendations or links for insider knowledge of the JVM/Java? If Clojure focused all the better :)

Maybe it's not really up your alley. But I learned Java with the Java in Action with BlueJ [1]. Although it's pretty basic, the text book really explains all the Java (and OOM) basics in a pretty clear way. The book is called Objects First [2].

In addition I really enjoyed exploring the JDK documentation. Especially Java It's not exactly JVM, but just wanted to share anyway :).

1. https://www.java.com/en/java_in_action/bluej.jsp

2. https://www.bluej.org/objects-first/

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

#120

Post by alex3305 »

cypressious wrote: post #95
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.…

The default size of an ArrayList has been 0 for a while. On the first insertion, it is initialized to 10.

That's a bit semantic, isn't it? Because in practice it's still 10, but lazily initialized [1]. And an empty ArrayList is useless anyway.

1. https://stackoverflow.com/a/34250231

Post reply on HN