ergo default for GCTaskTimestampEntries etc.

[Bengt Rutisson]

Hi Ramki,

On 2012-06-29 09:45, Srinivas Ramakrishna wrote:
> Hi Bengt --
>
> Thanks a lot for filing the bug. I did exchange some emails with Jon 
> on this issue and have a template for a fix.

Good! I'm glad Jon picked this up.

> I was in the middle of something that
> 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.

Sounds good. Just a heads up, I'll be on vacation the coming two weeks. 
But I'm sure someone else in the GC team will help you with your patch 
if you finish it before I'm back :-)

Bengt

>
> thanks!
> -- ramki
>
> On Thu, Jun 28, 2012 at 1:54 PM, Bengt Rutisson 
> <bengt.rutisson at oracle.com <mailto:bengt.rutisson at oracle.com>> wrote:
>
>
>     Hi Ramki,
>
>     I don't think you got any response on this email yet. Sorry about
>     that!
>
>     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:
>
>     7180571 Make the code regarding GCTaskTimestampEntries more robust
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7180571
>
>     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. ;-)
>
>     Thanks for the report!
>     Bengt
>
>
>     On 2012-06-18 21:48, Srinivas Ramakrishna wrote:
>
>
>         Hi John, all --
>
>         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
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120629/05875875/attachment.htm>