ergo default for GCTaskTimestampEntries etc.

[Bengt Rutisson]

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