Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

opsian.com

Post reply on HN
Print view View original

91–100 of 245 posts

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

#91

Post by pjmlp »

gok wrote: post #85
pjmlp wrote: post #68

Earlier quoted context omitted.

Plenty of GC languages have value types and support for manual memory management. Mesa/Cedar, Active Oberon, Modula-3, D, System C#, Go, C#

Sure, even Java lets you manually allocate memory via JNI, but negligible amounts of code written in those languages actually uses manual management. Reference counting is uncompetitive in those languages because idiomatic Java/C#/Go make lots of allocations and pass around lots of pointers with no lifetime semantics.

I can also code in C with malloc()/free() everywhere.

The features are available, it is up to the programmers to use them

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

#92

Post by dnomad »

eikenberry wrote: post #83
phakding wrote: post #58

Earlier quoted context omitted.

I worked for a company where we had a 100-150 microseconds order latency. We had to tune jvm to extremes. But it is very doable to optimize Java gc for low gc pause times.

With those latency requirements why did you use Java?

Plenty of people are writing low-latency trading applications in Java where the latency budget is under 100 microseconds. This has been the case for several years now.

It's by no means new or even especially difficult these days. The resulting code is far more maintainable and robust than C++ solutions.

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

#93

Post by pjmlp »

Jweb_Guru wrote: post #88
pjmlp wrote: post #68

Earlier quoted context omitted.

Plenty of GC languages have value types and support for manual memory management. Mesa/Cedar, Active Oberon, Modula-3, D, System C#, Go, C#

It's worth noting that Go's value types are not actually memory safe, however, since it allows nontrivial concurrent mutations to shared multiword objects (as described in https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... ). Unless that got fixed recently somehow? I believe in most of the other languages you mention, value types are restricted in various ways to avoid that problem (for instance, mutatio…

With the exception of Go and C#, there are no limitation on value types.

All those languages are GC enabled systems programming languages.

Regarding Go the memory safety in multithreaded code is orthogonal to having support for value types or not.

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

#94

Post by gok »

pjmlp wrote: post #91
gok wrote: post #85

Earlier quoted context omitted.

Sure, even Java lets you manually allocate memory via JNI, but negligible amounts of code written in those languages actually uses manual management. Reference counting is uncompetitive in those languages because idiomatic Java/C#/Go make lots of allocations and pass around lots of pointers with no lifetime semantics.

I can also code in C with malloc()/free() everywhere. The features are available, it is up to the programmers to use them

But (a) that's not idiomatic (b) malloc/free aren't refcounted.

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

#95

Post by pjmlp »

jmull wrote: post #65
pjmlp wrote: post #23

Earlier quoted context omitted.

Many think that refcount isn't a GC algorithm and that it is faster than GC. Well, refcounting is the basic way of implementing GC and is listed as GC algorithm in any serious CS book about GC algorithms like "The Garbage Collection Handbook". What many refer as GC is actually the GC algorithms that fall under the umbrella of tracing GC. Then refcounting is only faster than GC in very constrained scenarios: - no shar…

> - no sharing across threads, otherwise locking is required for refcount updates If you are sharing across threads you will need a synchronization mechanism, whether you have reference counting or not. So it's not exactly fair to assign this cost to reference counting. General reference counting does make adding or removing a reference a read/write operation, though of course non-naive implementations don't do this…

Tracing GCs don't need to synchronize at each access point.

One can optimize refcounting with deferred reference counting algorithms, but then that is already the skeleton implementation of a tracing GC.

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

#96

Post by dnomad »

snaky wrote: post #67
phakding wrote: post #58

Earlier quoted context omitted.

I worked for a company where we had a 100-150 microseconds order latency. We had to tune jvm to extremes. But it is very doable to optimize Java gc for low gc pause times.

If you used to tune JVM only, that might be interesting. Most often the Java code is what being tuned - to the point where there is no point to use Java - with (almost) no gc, off-the-heap memory allocations and all that jazz.

This doesn't make much sense. Using object pools and and off-heap data structures doesn't warp the code that much, if at all. You still end up with pretty much all clean, simple Java code.

I've seen (10+ years old) low-latency Java apps where people avoid using any OO (ie everything is static methods)... and even then the code was still often easier to maintain and understand than equivalent C++ applications. Nobody does this any more anyways.

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

#97

Post by pjmlp »

Sir_Cmpwn wrote: post #89
geezerjay wrote: post #73

Earlier quoted context omitted.

> Our legal system is such that Oracle can still burn you down, even if you are right. Do you happen to know of any real-world case that's similar to the scenario you've described?

Google v Oracle comes to mind.

Google should not have tried to screw Sun, they still had the option to buy Sun and choose not to.

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

#98

Post by electrum »

pkulak wrote: post #79
shanxS wrote: post #76

Earlier quoted context omitted.

Can you please elaborate?

It's just an object that lives on the stack, not the heap. In lots of languages when you create an object, it's pretty explicit where you're putting it. When Java was created, they wanted to get rid of that complexity, so primitives always go on the stack and objects always* go on the heap. * I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, i…

It's more about the memory layout than where the objects live. For example, consider a Point class with (x, y) members.

If you have an array of these, each element in the array will be a reference/pointer to a separately allocated Point instance which can be anywhere in the heap. Accessing the array is expensive due to lack of locality (arbitrary memory access). Additionally, each instance has substantial object overhead (typically 8 or 16 bytes).

There are various ways to deal with this. One way is to have separate arrays for x and y. Another way is to use a byte array and use Unsafe to read/write the integers. This is terrible from a developer standpoint and is only acceptable if it is a small part of your application.

Value types solve this by giving you an efficient memory layout while still allowing you to code against them as normal. The slogan is "codes like a class, works like an int".

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

#99

Post by blt »

pkulak wrote: post #79
shanxS wrote: post #76

Earlier quoted context omitted.

Can you please elaborate?

It's just an object that lives on the stack, not the heap. In lots of languages when you create an object, it's pretty explicit where you're putting it. When Java was created, they wanted to get rid of that complexity, so primitives always go on the stack and objects always* go on the heap. * I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, i…

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.

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

#100

Post by Tarean »

pjmlp wrote: post #93
Jweb_Guru wrote: post #88

Earlier quoted context omitted.

It's worth noting that Go's value types are not actually memory safe, however, since it allows nontrivial concurrent mutations to shared multiword objects (as described in https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... ). Unless that got fixed recently somehow? I believe in most of the other languages you mention, value types are restricted in various ways to avoid that problem (for instance, mutatio…

With the exception of Go and C#, there are no limitation on value types. All those languages are GC enabled systems programming languages. Regarding Go the memory safety in multithreaded code is orthogonal to having support for value types or not.

If the manually allocated memory may contain references to managed objects then it still needs to be traced by the gc.

That or you start pinning managed objects or pull everything related into manual world. Both kinda suck.

Post reply on HN