Wow! Multi-terabyte heaps? That sounds like way to much stuff in memory. When would you need multiple terabytes in RAM? I mean come on... What kind of application even needs that. Though I do admit that javascript needs this kind of GC implementation because the hangs JS causes are a real pain.
Run Apache Spark on the box with 256+ GB of RAM. The GC stalls by 60 or more seconds are quite typical for heavy queries.
I hope new GC will bring improvements.
Multi terabyte heaps would move the bar for Big Data way to the right and let most of us just ignore the whole thing.
Basic space versus time trade off. In eight years we’ll laugh about how stupid people were for doing it, and in another 8 laughing at the people who didn’t.
One of the reasons things like memcache became a thing is because we hit a point where same-switch tcp/ip round trips were smaller than average seek time for your hard drives. I gotta say, it’s a little crazy that it was faster to ask another machine a question than to look it up yourself, but there it is.
> A core design principle/choice in ZGC is the use of load barriers in combination with colored object pointers (i.e. colored oops). [...] In addition to an object address, a colored object pointer contains information used by the load barrier to determine if some action needs to be taken before allowing a Java thread to use the pointer.
This looks furiously like an incremental improvement of Shenandoah's model [1]; Hurray for more teams exploiting this new way of doing things. Cache lines are getting bigger, we can definitely afford memory management metadata.
The difference here seems to be that they intend to explore different uses of this metadata:
> this could be used to track heap access patterns to guide GC relocation decisions to move rarely used objects to "cold storage".
I always wondered if a relocating GC could have a subtle way of building cache-friendly layouts. I'm speculating here, but if I'm not mistaken current copying GCs traverse the heap breadth-first; and reuse this in the copying. This new approach could lead to options for going depth first at select points; For example in a JPA graph of objects, in some patterns lots of fields are never used. There is something to do here.
10 comments
[ 2.9 ms ] story [ 29.1 ms ] threadThe problem is memory price / GB not only hasn't gone down but goes up.
Basic space versus time trade off. In eight years we’ll laugh about how stupid people were for doing it, and in another 8 laughing at the people who didn’t.
One of the reasons things like memcache became a thing is because we hit a point where same-switch tcp/ip round trips were smaller than average seek time for your hard drives. I gotta say, it’s a little crazy that it was faster to ask another machine a question than to look it up yourself, but there it is.
If GC pause times do not increase with the heap- or live-set size, it could handle such large heaps.
This allows for concurrent heap compaction, at the cost of throughput.
Azul used to sell commercial “java machines”, with hardware support for the barriers.
This looks furiously like an incremental improvement of Shenandoah's model [1]; Hurray for more teams exploiting this new way of doing things. Cache lines are getting bigger, we can definitely afford memory management metadata.
The difference here seems to be that they intend to explore different uses of this metadata:
> this could be used to track heap access patterns to guide GC relocation decisions to move rarely used objects to "cold storage".
I always wondered if a relocating GC could have a subtle way of building cache-friendly layouts. I'm speculating here, but if I'm not mistaken current copying GCs traverse the heap breadth-first; and reuse this in the copying. This new approach could lead to options for going depth first at select points; For example in a JPA graph of objects, in some patterns lots of fields are never used. There is something to do here.
[1] https://wiki.openjdk.java.net/display/shenandoah/Main