Live data from Hacker News

Java’s new garbage collector promises low pause times on multi-terabyte heaps

opsian.com

151–160 of 245 posts

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#151
post #80

Earlier quoted context omitted.

I think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.

With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.

Every object requires a header and a 8 byte pointer. This means even an empty object will cost you 16 or even more bytes. If you have perfect data locality and zero cache misses then you will still suffer from exhausting your bandwidth on useless data.

Then there is the fact that you still cannot actually control the allocation. The allocation pattern ABBAABABBA has worse performance on read accesses of all As or all Bs than AAAAABBBBB but with two arena allocators you can write your code to allocate memory according to the irregular pattern but still have continguous data as the end result.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#152
post #122

Earlier quoted context omitted.

The point is that they should have used Java more cleverly. One can make a game in C++ and make it just as bad.

The lack of value types makes the code quite unwieldy to control memory layout vs C++, or C#, or Go, or Rust or anything

Again, not every game needs to be the next Crysis.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#153

Earlier quoted context omitted.

Java is at least somewhat responsible for the need to get to 4TB in the first place.

Sounds interesting. Could you explain how so?

He's just trying to bash Java. HN readers hate Java for some reason.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#154
post #119

Earlier quoted context omitted.

Yes. But I believe that Microsoft made an improved version written in C++ after the acquisition.

"improved" is a matter of opinion. The Java version has mod support and the editions are kept at feature parity.

I remember when they promised a modding api... Not even the C++ has resulted in one... The fact that Notch went with Java might have been a blessing in disguise because it made the reverse engineering process semi automated.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#155
post #101
post #80

Earlier quoted context omitted.

With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.

It doesn't matter nearly as much as people believe. Value objects at this point are a kind of red herring. The JVM does aggressive escape analysis and is also very good at capturing short-lived objects. In the big picture, pointer chasing and memory latency is kind of the last frontier of performance grumps. It really becomes an issue is with very large object arrays that must be iterated over quickly. In that case i…

I'm not sure why you argue against giving the compiler the information it needs to do its job, and instead recommend these crazy codegen hacks, that even describe themselves as "poor-mans" solutions.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#156
post #80

Earlier quoted context omitted.

With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.

When you embed a composite object into another composite object, in Java there always needs to be a pointer indirection between them. Even if GC and allocation is free, this is a massive performance loss. (For example, if you have something that would fit into 4 bytes, now you have to fit a 8-byte pointer, and the minimum created object is probably 16 bytes.) Alternatively you can just flatten everything into a singl…

Can't the compiler flatten objects into one another?

For example, if one class includes a reference to another, merge the fields and methods of both classes into one big mega-class, then see if there is any redundant code which can be removed for this new megaclass.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#157
post #141

Earlier quoted context omitted.

Openjdk8 or get out! Seriously though I am concerned about the future of Java. I am keeping everything openjdk8 personally.

Why?

I would tell you, but I am honestly worried about possible action form Oracle if I did.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#158
post #135
post #99

Earlier quoted context omitted.

Moreover, they can be used in composite objects without pointer chasing. Suppose class A is a 32-byte value type. Then class B { A a1; A a2; } is one continuous 64-byte block of memory. Without value types, each A will be allocated separately on the heap, and B will be a pair of pointers. Lack of value types makes it hard to get cache efficient memory layouts in Java.

Of course if/when a1 gets also referenced from outside while you may not need B any more that is then the things become more interesting.

Depends how they implement value types. They might simply say 'you can't have a reference to a value type'. You either embed it in your class, or you copy it's value.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#159
post #129

Earlier quoted context omitted.

Okay but they can do that even if you don't use Java.

And even if you don't do any bussiness with them. Oracle can sue anyone, they sue a lot. Like most companies they only do so if they think they can make a profit. They could sue you, with a higher chance of winning, for using a python, a js or a ruby than for using OpenJDK derived code.

Oracle holds JavaScript trademark. Nobody's safe :)

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#160
post #101

Earlier quoted context omitted.

It doesn't matter nearly as much as people believe. Value objects at this point are a kind of red herring. The JVM does aggressive escape analysis and is also very good at capturing short-lived objects. In the big picture, pointer chasing and memory latency is kind of the last frontier of performance grumps. It really becomes an issue is with very large object arrays that must be iterated over quickly. In that case i…

I'm not sure why you argue against giving the compiler the information it needs to do its job, and instead recommend these crazy codegen hacks, that even describe themselves as "poor-mans" solutions.

> I'm not sure why you argue against giving the compiler the information it needs to do its job

There's several different factors to consider. Value objects will be a valuable addition to the core JVM if only to standardize the many different approaches in place today. But even the standard value types will have strict limitations -- they will likely be immutable and it's not clear that you'll be able to easily obtain their memory address. That means many projects will still need things like code-gen. Code gen, and buffer-backed objects in general, isn't a hack at all it's a proven, battle-tested solution for many domains (finance, scientific sims, big data) that are manipulating several several gigabytes of objects in a performant manner.

Post reply on HN