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