- 2.1 Diagnostic Tools Overview
- 2.6 The jcmd Utility
- 2.7 Native Memory Tracking
- 2.11 The jdb Utility
- 2.13 The jinfo Utility
- 2.14 The jmap Utility
- 2.15 The jps Utility
- 2.16 The jstack Utility
- 2.17 The jstat Utility
- 2.19 Control+Break Handler
- 2.20 Native Operating System Tools
- 2.21 Custom Diagnostic Tools
- NMT Memory Categories
- Postmortem Diagnostics Tools
- Hung Processes Tools
- Monitoring Tools
- Other Tools, Options, Variables and Properties
- The java.lang.management Package
- The java.lang.instrument Package
- The java.lang.Thread Class
- JVM Tool Interface
- The jrunscript Utility
- The jsadebugd Daemon
- The jstatd Daemon
- Thread States for a Thread Dump
- Troubleshooting Tools Based on Operating System
- 3.1 Debug a Memory Leak Using Java Flight Recorder
- 3.2 Understand the OutOfMemoryError Exception
- 3.3 Troubleshoot a Crash Instead of OutOfMemoryError
- 3.4 Diagnose Leaks in Java Language Code
- 3.5 Diagnose Leaks in Native Code
- 5.1 Determine Where the Crash Occurred
- 5.2 Find a Workaround
- 5.3 Microsoft Visual C++ Version Considerations
- 6.1 Diagnose a Loop Process
- 6.2 Diagnose a Hung Process
- 6.3 Oracle Solaris 8 Thread Library
- 7.1 Handle Signals on Oracle Solaris and Linux
- 7.2 Handle Exceptions on Windows
- 7.3 Signal Chaining
- 7.4 Handle Exceptions using Java HotSpot VM
- Console Handlers
- Signals Used in Oracle Solaris and Linux
- 17.1 Check for Fixes in Update Releases
- 17.2 Prepare to Submit a Bug Report
- 17.3 Collect Data for a Bug Report
- 17.4 Collect Core Dumps
- Location of Fatal Error Log
- Description of Fatal Error Log
- Header Format
- Thread Section Format
- Process Section Format
- System Section Format
many people curious about g1. Most apps still use cms. How does g1 perform in real production？
@Martijn Verburg @Monica Beckwith hope you can give us some infomation
Monica Beckwith 21:01
Sure. If you have any specific use cases I can help. All companies that I worked with, that are able to get to latest JDK 8 release are happy moving to G1… with minimal tuning.
Martijn Verburg 21:34
Kirk and I are presenting our tuning G1 talk at JavaOne. I will post some of our current findings here over the weekend. We have found some usage patterns and edge cases where G1 has some challenges. It also is a good idea to track the open issues on the OpenJDK JIRA labelled with G1. You will see that there are many small fixes and improvements to go.
We would only recommend it for Java 8u91 as there are still JVM crash bugs prior to that
Humongous objects still cause big problems and there are hard limits to reference processing and object copy times depending on the shape of your object graph
Will g1gc has the ability to do parallel fullgc? Google has a patch for cms to enable parallel fullgc which brings quite a lot enhancement.
e.g. HBase, using BlockCache & MemStore, consumes a lot of heap space, and eventually has a fullgc after not a long time, which affects service availability when heap is large than 100GB. So concurrent fullgc is valuable in this case.
Martijn Verburg 22:18
IIRC the G1 full GC is currently single threaded but they are working on making it parallel. It is not concurrent by design (it has to stop all threads at a safe point). Monica will correct me if I’m wrong 🙂
I’m not yet convinced that G1 works all that well for heaps > 75GB. In *theory* a fully production read Shenandoah will perform better and of course the C4 collector still wins hands down.
That said there are still ~50 G1 bugs and features that they are working on, so I expect it it improve
Monica Beckwith 22:20
I have worked with Hbase and blockcache and memstore with G1 with about 64Gs no full GCs
Martijn Verburg 22:20
Yeah we typically see 64GB heaps for that sort of work
But unless you’re on the latest 8 update we’ve seen instabilities over several weeks of hot running
And of course with G1 the big question is what pause time goals you want 🙂. It’s a great low pause collector but not a low latency low pause collector (if you’re in the high frequency trading business)
Monica’s work on G1 is putting many of us out of a job 😉
One last note before I jump on my next plane. You can still get better extreme low latency out of a well tuned CMS than you can G1. However it takes a lot of work and tuning of many parameters.
This is why RedHat, Google, Twitter, ourselves and a few others will try to maintain CMS for Java 10 – but I think G1 will take over for a majority of applications who want good low pause behaviour with minimal tuning
Monica Beckwith 22:35
Agreed on low latency CMS surpasses G1 because you don’t have any old gen “collection” and you can easily avoid/push off full GCs…
BTW, yes all full GCs in HotSpot are stop the world and so far only Parallel GC employs multiple threads for full collections
Param tuning is not a big problem in many company, but the best gc effect after tuning is.
Monica Beckwith 23:00
Ok. I understand. What is the live data set size for your 100g heap?
Yes we do not encounter fullgc on 64GB heap with forked but not community hbase 0.94 even on openjdk 6. But since larger heap brings out more problems, our hbase team is splitting hbase server to small unit using docker to decrease heap size.
@Monica Beckwith Also large than 64G. We have some 196G mem machines.
Reducing heap size and increasing unit count is not a ideal solution. It brings more work on operation and more mem overhead. So if jdk can improve its full gc performance, it will bring a lot wonderful things.
Monica Beckwith 23:04
Ok. We can work on this via email if you prefer… but if you could send more information on LDS and marking threshold and occupancy… it will give me a better idea of the workload pressure on G1
@Monica Beckwith Fine, i will forward this to our hbase team
Martijn Verburg 23:29
And please do grab a free trial copy of censum from Jclarity.com – it will help you compare and contrast your GC behaviour before and after changes.