According to the JEP 377 page (the 2020/05/25 update):
Since its introduction in JDK 11 we’ve received positive feedback,
we’ve ironed out many bugs, and we’ve added a number of features and
enhancements. To highlight some of the more important ones:
- Concurrent class unloading
- Uncommitting unused memory (JEP 351)
- Maximum heap size increased from 4TB to 16TB
- Minimum heap size decreased to 8MB
- -XX:SoftMaxHeapSize
- Support for the JFR leak profiler
- Support for class-data sharing
- Limited and discontiguous address spaces
- Support for placing the heap on NVRAM
- Improved NUMA awareness
- Multi-threaded heap pre-touching
Furthermore, all commonly used platforms are now supported:
- Linux/x86_64 (JEP 333)
- Linux/aarch64 (8214527)
- Windows (JEP 365)
- macOS (JEP 364)
Testing of ZGC suggests that it is stable and, as of this writing, we have received no new ZGC-specific bugs for a few months. With the stability, feature set, and platform support that ZGC has today, it is
time to remove its experimental status and make it a product feature.
A couple of caveats:
- This comes from the team working on the ZGC project. There is a possibility that they are not being entirely objective. (That is just human nature ...).
- It depends on how many people (the team and users) are testing / trying out the new GC.
- It depends on what they are testing / trying out, and whether that is a good match for what you are proposing to do.
- With something as complex as a new Java GC it could take years for some bugs to surface in a reproducible form.
So, while promising, this does NOT count as a quantifiable measure of stability, and does not give a quantifiable measure of risk.