Hacker News Reader

Comment by greenbit | Hacker News Reader

Ah, but java seems to go out of its way to make you make so very many objects. It's almost as though it tries to rub your face in the fact that you don't have to remember to delete objects, by needlessly making you make them. Iterators for example. Why (why!) should it be necessary to incur memory thrash, just to traverse a collection? Why not allow a class that has a collection also have a reusable iterator? Just a simple .reset() method would work wonders for many of these "disposable" objects. And if .reset() offended anyone, they could always ignore it and continue to blithely throw candy wrappers out the car window, as it were.

View on HN

A bigger issue I think is Java's need to box values, primitive or otherwise. For example, even an ArrayList of integers creates an object for each one. IMHO, the Java runtime has many of the design hallmarks of a dynamic language, with strong (generic) types somewhat bolted on.

It’s not always obvious what’s actually boxed and what isn’t however. The JVM tries to do clever optimisation. For example, I’m fairly certain that when you manipulate an array of primitive numerical values, they are not actually unboxed before each operation before being boxed again.

Hmmm. As much as I hate having to fix boxing problems, I usually find it pretty obvious when boxing can occur. Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring. Those ... and assigning those to Object or Number.

I think that's exhaustive. You can pretty much grep through and remove them from 90 % of coffee with a little refactoring and replacing HashMaps with specialized ones. Only if there's null returns or ConcurrentHashMaps involved does it get tricky.

An array of primitives like byte[] or long[] isn't Byte[] or Long[]. The former don't cause boxing. Maybe you're thinking of ArrayList<Byte>?

> Pretty much any time a variable/parameter type or a function return type uses capitalized Integer, Long, Boolean, etc. instead of lowercase int, long, boolean, etc. boxing is probably occurring.

That probably occurring hides a lot of complexity. That’s my original point. Optimisations are happening especially when Integer and Long are involved. There are sometimes actually less boxing than you would expect reading the code.

True, but I'd argue you should treat those probable boxing situations and definitely boxing and remove them.

> the Java runtime has many of the design hallmarks of a dynamic language, with strong (generic) types somewhat bolted on.

I'd say it's the opposite. Dynamic languages largely use boxing as the indirection mechanism for their highly dynamic type systems, since it works well there. But boxing isnt synonymous with type flexibility, and Java uses it for other reasons (mostly).

The Java runtime provides runtime type information for all types, and extensive reflection is available, including for example invoking arbitrary code. Very dynamic and a significant problem for static analysis, optimisation and security.

A friend of mine is working at Oracle on collections that support primitives e.g. List<int>, Set<long> https://openjdk.org/jeps/8261529

No, thanks, that's a pretty bad idea.

1. There's no point in optimizing memory usage by hunting iterators. If the collection overhead is becoming visible, then you need an array, not a reset method.

2. You cannot easily add "reset()" to all iterators now, since it will be a breaking change.

3. Having reset() on all iterators 25 years ago would reduce the number of use cases for it, if this method had to be reliably supported.

3. Throwing UnsupportedOperationException in default method to maintain compatibility of libraries with existing user code would require the new client code using that method to catch the exception and handle it, which ruins the whole idea of optimization (you will get more overhead on that).

I you are concerned about performance, you have to design your code with respect to it. Building your application the same way as if performance wasn't a big problem, using the same libraries and APIs is just a bad idea that won't be salvaged by such "optimizations".

Sometimes arrays are not an option, because objects may not be in memory at all times. A fun trick we use is to have the iterator be attached to the object lifecycle, so that repeated (parallel) iteration does not require multiple iterators. I can't remember the exact percentage, but this change alone increased our throughput by 20-25%.

That sounds both familiar and weird, like some strange lazy collection that performs an I/O operation to hydrate every time it creates iterator.

Whatever it is, it's certainly not something that would justify a modification of standard API to cover this use case.

What was the use case for the app? Was it also HFT?

Most Iterators should be placed on the stack anyway. If they are not and you have a random access collection like ArrayList you can use an index, but this is rarely needed. If you are going to change code, perhaps Stream(s) are a better choice, these are also placed on the stack most of the time.

Iterators tend to be placed on the stack in hot code. In the benchmark I had to make sure these object weren't optimised away.

Reply on news.ycombinator.com