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

[Jaroslav Bachorik]

Hi Claes,

On 27.8.2015 16:42, Claes Redestad wrote:
> Updated webrev after comments and discussion with Jaroslav:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8134583/webrev.03
>
> Changes:
> - convert 'threads' from array to list
> - simplified further by removing old code dealing with adapterThread

Thanks, I like this simplification.

Good to go!

-JB-

>
> /Claes
>
> On 2015-08-27 15:21, Jaroslav Bachorik wrote:
>> 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
>>>>
>>>
>>
>