ParallelGC GCTaskTimeStampEntries-sized-buffer

Solution Verified - Updated

Environment

  • OpenJDK 8, OpenJDK 11, OpenJDK 17
  • ParallelGC

Issue

  • Gc logs and/or application log have:

    GC(6) GC-thread 3: Too many timestamps, ignoring future ones. Increase GCTaskTimeStampEntries to get more info.

  • How to set PrintGCTaskTimeStamps and why?

Resolution

Issue happened after setting Xlog:g*=debug:

GC(6) GC-thread 3: Too many timestamps, ignoring future ones. Increase GCTaskTimeStampEntries to get more info.

Setting for debug log should increase the verbosity, and therefore the buffer can be overloaded.
For the issue above, there is a 200 buffer to 300 see below - interesting this flag was removed on JDK 14 and the default the 300.

-XX:GCTaskTimeStampEntries=300

Root Cause

ParallelGC has a per thread limit, like a buffer which is set via GCTaskTimeStampEntries - it defaults for 200 entries on JDK 11 and JDK 8.
That's a buffer for writing gc logs events, so depending on the quantity of threads the threads writing can overload the
That sets the number of entries that are written per thread on the gc logs.
Increasing the buffer to 300 can help on those situations.
Even though the flag was supposed to set 300 by default on Content from bugs.openjdk.org is not included.Increase default value of GCTaskTimeStampEntries, it wasn't given the process of thread logging was improved in Content from bugs.openjdk.org is not included.Make the code regarding GCTaskTimestampEntries more robust
Finally, this flag was deprecated on JDK 14: Content from bugs.openjdk.org is not included.Obsolete flag GCTaskTimeStampEntries.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.