ergo default for GCTaskTimestampEntries etc.
Srinivas Ramakrishna
ysr1729 at gmail.com
Fri Jun 29 07:45:37 UTC 2012
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. 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.
thanks!
-- ramki
On Thu, Jun 28, 2012 at 1:54 PM, Bengt Rutisson
<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<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: PrintParallelOldGCTaskTimeStam**ps (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/f19e2aa8/attachment.htm>
More information about the hotspot-gc-dev
mailing list