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

[Vladimir Kozlov]

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
>>
>>
>