RFR(XS): 8134583: sun.management.HotspotCompilation should handle absence of per-thread perf counters

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Thu Aug 27 13:21:19 UTC 2015


On 27.8.2015 15:14, Claes Redestad wrote:
>
>
> On 2015-08-27 15:04, Jaroslav Bachorik wrote:
>> Hi,
>>
>> On 27.8.2015 14:41, Claes Redestad wrote:
>>> Hi,
>>>
>>> please review this patch to clean up and make
>>> sun.management.HotspotCompilation
>>> behave nice if the VM would decide to no longer expose per-compiler
>>> thread perf counters:
>>>
>>> webrev: http://cr.openjdk.java.net/~redestad/jdk9/8134583/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8134583
>>
>> When already changing this wouldn't it be easier to convert the
>> 'threads' variable to List<CompilerThreadStat> and only add the info
>> for existing compilers threads (eg. not leaving NULL slots in the array).
>>
>> In 'getCompilerThreadStats' method the 'threads' array is converted to
>> a list anyway.
>
> The CompilerThreadStat object needs to be created on demand (since it
> polls the underlying counters), thus we still need to maintain either an
> array or list of CompilerThreadInfo. Converting CompilerThreadInfo[] to
> a compact (or empty) List<CompilerThreadInfo> may or may not save a few
> bytes, but we'd still have to create a new list every time
> getCompilerThreadStats() is called.

Right. Still could save some null value juggling by storing 
CompilerThreadInfo instances into a list instead of an array.

-JB-

>
> /Claes
>
>>
>> -JB-
>>
>>>
>>> /Claes
>>
>



More information about the serviceability-dev mailing list