RFR: 8204476: Add additional statistics to CodeCache::print_summary
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 8 23:56:05 UTC 2018
On 6/7/18 12:11 PM, Thomas Stüfe wrote:
> On Thu, Jun 7, 2018 at 9:37 AM, René Schünemann
> <rene.schuenemann at gmail.com> wrote:
>> Hi,
>>
>> can I please get a review for the following change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204476
>> Webrev: http://cr.openjdk.java.net/~goetz/wr18/rene/webrev_8204476/01/
>>
>> This change adds the following:
>>
>> (1) In CodeCache::print_summary prints the code cache full count for
>> each code heap.
>>
>> (2) Adds additional counters to class CompileBroker:
>> _total_compiler_stopped_count: The number of times the compilation
>> has been stopped.
>> _total_compiler_restarted_count: The number of times the
>> compilation has been restarted.
>> This counters are also added to CodeCache::print_summary.
>>
>>
>> Thank you,
>> Rene
>
> Hi Rene,
>
> Apart from what Vladimir wrote:
>
> - small nit: _total_compiler_restarted_count += 1; ->
> _total_compiler_restarted_count ++;
>
> - Please either use %d for printing int or change the type to
> uint32_t. But seeing that the other counters are int, I would use %d.
Agree. I think Rene used existing code as example but we should use %d for signed integers.
>
> - More of a question to others: I am not familiar with compiler
> coding, but signed int as counters seem a bit small? Is there no
> danger of ever overflowing on long running VMs? Or does it not matter
> if they do?
I never observed compilations count over 1M (10^6). And there is no issue if they overflow - it is
just number printed in statistic and logs. We have also use it as compilation task id and I think it
is also safe.
Note, in stable application case you should not have a lot of compilations. It should not be more
than application's + system's hot methods.
New counters in this change are much smaller - they count how many times CodeCache become full which
should not happen in normal case.
Regards,
Vladimir
>
> Thanks, Thomas
>
More information about the hotspot-dev
mailing list