Ramki reported this issue on the OpenJDK list:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-June/004625.html

Here is the report from Ramki:

I recently saw the JVM complain that the default value of GCTaskTimestampEntries was too low, when it was run with +PrintGCTaskTimeStamps :-

GCTaskTimeStamp* GCTaskThread::time_stamp_at(uint index) {
  guarantee(index < GCTaskTimeStampEntries, "increase GCTaskTimeStampEntries"); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  return &(_time_stamps[index]);
}

Firstly, a guarantee here and an exit seems too draconian, rather the logging should drop the value presented and carry on. The culrpit is this piece of
code in the GCTaskThread work loop:-

        if (PrintGCTaskTimeStamps) {
          assert(_time_stamps != NULL,
            "Sanity (PrintGCTaskTimeStamps set late?)");

          timer.update();

          GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_index++);

          time_stamp->set_name(name);
          time_stamp->set_entry_time(entry_time);
          time_stamp->set_exit_time(timer.ticks());
        }


Secondly, does the max # timestamp entries depend on factors that could be set ergonomically upon start-up so one doesn't need to navigate here by trial-and-error?

Also, it would be great if one could have a suboption whereby such verbose logging could be limited to specific phases of GC, which could turn the verbosity
level up and down as specified. For example, I might want the logging only for major gc cycles of ParallelOldGC and not otherwise, so I should be able to
say, for example: PrintParallelOldGCTaskTimeStamps (or equivalently say PrintGCTaskTimeStamps=ParllelOld) and have the verbose logging be limited to
that phase of GC. May be the logging framework can address issues like this in a consistent and uniform fashion.

Thanks!
-- ramki