Hi Bengt --<br><br>Thanks a lot for filing the bug. I did exchange some emails with Jon on this issue and have a template for a fix. I was in the middle of something that<br>placed this temporarily on the backburner, but I'll have a few spare cycles over the next couple of days so will get together a patch for your consideration.<br>
<br>thanks!<br>-- ramki<br><br><div class="gmail_quote">On Thu, Jun 28, 2012 at 1:54 PM, Bengt Rutisson <span dir="ltr"><<a href="mailto:bengt.rutisson@oracle.com" target="_blank">bengt.rutisson@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Ramki,<br>
<br>
I don't think you got any response on this email yet. Sorry about that!<br>
<br>
I had a quick look at the code that you refer to. This is not a part of the code that I have been touching much but as far as I can tell your analysis is correct. I filed a bug to track this issue. It hasn't shown up on the public bug page yet, but hopefully it will be available there soon:<br>

<br>
7180571 Make the code regarding GCTaskTimestampEntries more robust<br>
<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180571" target="_blank">http://bugs.sun.com/<u></u>bugdatabase/view_bug.do?bug_<u></u>id=7180571</a><br>
<br>
I'm not sure when we get around to investigating this further. If you happen to create a patch for this I'm happy to shepherd the fix into the repository. ;-)<br>
<br>
Thanks for the report!<span class="HOEnZb"><font color="#888888"><br>
Bengt</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 2012-06-18 21:48, Srinivas Ramakrishna wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi John, all --<br>
<br>
I recently saw the JVM complain that the default value of GCTaskTimestampEntries was too low, when it was run with +PrintGCTaskTimeStamps :-<br>
<br>
GCTaskTimeStamp* GCTaskThread::time_stamp_at(<u></u>uint index) {<br>
  guarantee(index < GCTaskTimeStampEntries, "increase GCTaskTimeStampEntries"); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<br>
<br>
  return &(_time_stamps[index]);<br>
}<br>
<br>
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<br>
code in the GCTaskThread work loop:-<br>
<br>
        if (PrintGCTaskTimeStamps) {<br>
          assert(_time_stamps != NULL,<br>
            "Sanity (PrintGCTaskTimeStamps set late?)");<br>
<br>
          timer.update();<br>
<br>
          GCTaskTimeStamp* time_stamp = time_stamp_at(_time_stamp_<u></u>index++);<br>
<br>
          time_stamp->set_name(name);<br>
          time_stamp->set_entry_time(<u></u>entry_time);<br>
          time_stamp->set_exit_time(<u></u>timer.ticks());<br>
        }<br>
<br>
<br>
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?<br>
<br>
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<br>
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<br>
say, for example: PrintParallelOldGCTaskTimeStam<u></u>ps (or equivalently say PrintGCTaskTimeStamps=<u></u>ParllelOld) and have the verbose logging be limited to<br>
that phase of GC. May be the logging framework can address issues like this in a consistent and uniform fashion.<br>
<br>
Thanks!<br>
-- ramki<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>