RFR(M): 8008287: Code cache statistic variables for event tracing needs atomicity

[Vladimir Kozlov]

Yes, I think it is acceptable now. I will ask Christian to look on this.

Thanks,
Vladimir

On 6/18/13 7:15 AM, Nils Eliasson wrote:
> I have minimized the critical zones, moving max out. Also guarding all calls to os::elapsed_counter() with
> Tracing::enabled() and INCLUDE_TRACE. Had to reintroduce a duplication of timers in sweeper for some PrintMethodFlushing
> statistics behind ifdef ASSERT. Not super pretty or compact, but at least straightforward and easy to read.
>
> http://cr.openjdk.java.net/~neliasso/8008287/webrev.06/ <http://cr.openjdk.java.net/%7Eneliasso/8008287/webrev.06/>
>
> //Nils Eliasson
>
> On 2013-06-17 01:06, Vladimir Kozlov wrote:
>> Nils,
>>
>> NMethodSweeper::speculative_disconnect_nmethods() is called during safepoint (VM operation) so lock in it will affect
>> safepoint time. But I don't know how to avoid the lock here except use it only when atomic long store is not
>> available. One thing you can do to shorten time in lock is to move the addition and MAX2 operations outside the lock
>> (leave only stores inside) since it is the only place where these values are modified.
>>
>> +  {
>> +    MutexLockerEx ml(CodeSweeperStatistics_lock);
>>    _total_disconnect_time += disconnect_time;
>>    _peak_disconnect_time = MAX2(disconnect_time, _peak_disconnect_time);
>> +  }
>>
>> thanks,
>> Vladimir
>>
>> On 6/16/13 3:00 PM, Nils Eliasson wrote:
>>> Updated,
>>>
>>> Unnecessary lock removed from scan_stacks.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8008287/webrev.05
>>>
>>> //Nils Eliasson
>>>
>>> On 2013-04-30 17:27, Nils Eliasson wrote:
>>>> Hi,
>>>>
>>>> I have fixed some atomicity issues for the sweeper tracing and did some refactoring at the same time, removing
>>>> duplicate counters.
>>>>
>>>> I guess people might have opinions on this, but I have chosen to only use the perf_counters when available instead of
>>>> always having a normal counter and an additional perf_counter in specific scenarios.
>>>>
>>>> Also changed the type of the traversal counter (and the stack_traversal marker in nmethod). It should be good for 126
>>>> years of sweeping once a second anyway (and we don't complete full sweeps that often.)
>>>>
>>>> http://bugs.sun.com/view_bug.do?bug_id=8008287
>>>> https://jbs.oracle.com/bugs/browse/JDK-8008287
>>>> http://cr.openjdk.java.net/~neliasso/8008287/webrev.04 <http://cr.openjdk.java.net/%7Eneliasso/8008287/webrev.04>
>>>>
>>>> Thanks,
>>>> Nils Eliasson
>>>>
>>>>
>>>
>