RFR(XS): 8134583: sun.management.HotspotCompilation should handle absence of per-thread perf counters
Claes Redestad
claes.redestad at oracle.com
Thu Aug 27 14:42:30 UTC 2015
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
/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
>>>
>>
>
More information about the hotspot-compiler-dev
mailing list